페이스북 커뮤니티에 해당 글 공유 후기
생활코딩이라는 페이스북 커뮤니티에서 해당 포스팅을 올리고 많은 분들이 공유를 해주셨습니다. 그리고 응원 메시지를 보내주셨습니다. 감사합니다 행복해요 ㅎㅎ
이 글을 작성하는 이유
이 글은 저와 같이 백엔드 개발자를 준비하시는 분들이 읽는다는 생각으로 적었습니다.
저는 백엔드 개발자를 준비하면서, http와 관련된 코드를 작성할일이 자주 있었습니다. 예를들면 Get, post method, url, Response code와 같은 것들입니다. 저는 스프링을 통해서 http를 사용하고 있습니다. 아래 이미지는 http 프로토콜을 사용한 회원가입 코드입니다.
@PostMapping(path = "/users")
public ResponseEntity<User> userAdd(User user) {
user = userInformationService.makeUserPasswordEncrypt(user);
user = LoginResponseUtils.makeUserAddResponseInformation(user);
return ResponseEntity.status(HttpStatus.CREATED).body(user);
}
만약 프로토콜에 대해서 익숙하지 않으신 분들이 계신다면, 아래 유튜브 영상을 보시면 이해가 되실 것이라고 생각합니다. 최근에 아주 신경 써서 만드신 듯한 프로토콜에 대한 10분 분량의 동영상 입니다.
https://www.youtube.com/embed/nYmixrYkMag
저는 개발자로 전문가가 되려면 자기가 사용하고 있는것에 대해서 잘 알고있어야 된다고 생각 했습니다. 물론 다른 직업도 그렇겠지만 개발자는 알아야될것이 많기 때문에 모든것을 자세히 알기는 어렵습니다.
그러나 자기가 자주 사용하는 기술에 대해서는 깊이 알고있어야 전문가라고 생각했습니다.
개발자를 직업으로 전문가가 되고 싶은 제 생각 때문에 http에 대해서 조금 깊이 알아보기 시작했습니다. 하지만 기존 자료들은 http에 대한 무언가 추상적인 느낌이 있었습니다.
그리고 다른 사람에게 전해 듣거나, 읽은 글이 아닌 http를 만든 사람의 기분 느낌을 알고 싶었습니다. 비행기로 날아가서 통역사를 고용해서 인터뷰를 하면 좋겠지만 그럴만한 돈은 없었습니다. 그래서 원문을 번역 했습니다.
그래서 팀 버너스리가 초창기 http에 대해 작성한 글들을 번역해봤습니다. 번역은 처음이라 오역이 있다고 가정하고 보시면 원문에 대한 더 정확한 정보를 얻으실 수 있으실 것 같습니다.
번역글을 읽으며 이해하기 어려운 부분이 있으실 것이라 생각이 들었습니다. 그래서 번역한글 밑에 해설을 적었습니다. 해설은 제가 관련 자료를 찾아보거나 추측을 한 내용들이 담겨있습니다.
팀 버너스리가 HTTP를 만든 이유 (1991년)
제가 조사한 자료에 따르면 팀 버너스리가 http를 만든 이유가 있는 가장 오래된 웹페이지는 1991년에 작성된 팀 버너스리가 간략하게 적은 Why a new protocol? 이라는 제목으로된 문서 입니다. HTTP의 가장 초창기 버전으로 알려진 0.9보다 이전에 작성된 문서입니다.
Why a new protocol?
Existing protocols cover a number of different tasks.
- Mail protocols allow the transfer of transient messages from a single author to a small number of recipients, at the request of the author.
- File transfer protocols allow the transfer of data at the request of either the sender or receiver, but allow little processing of the data at the responding side.
- News protocols allow the broadcast of transient data to a wide audience.
- Search and Retrieve protocols allow index searches to be made, and allow document access. Few exist: Z39.50 is one and could be extended for our needs.
The protocol we need for information access (HTTP) must provide
- A subset of the file transfer functionality
- The ability to request an index search
- Automatic format negotiation.
- The ability to refer the client to another server
왜 새로운 프로토콜인가?
기존에 있던 프로토콜들은 이미 여러가지 일들을 맡고 있다 .
- 메일 프로토콜은 글쓴이의 요청에 따라 적은 수의 수령인에게 일시적으로 보관되는 메시지를 보낼 수 있도록 한다.
서버 클라이언트가 아닌 수령인과 글쓴이(recipients, author) 이라고 표현한 이유는 당시에 웹서버가 아직 상용화 되지 않았기 때문인듯 합니다. 웹서버가 처음 개발된것은 1990년입니다. 이름은 CERN httpd로 팀 버너스리가 개발했습니다.
- 파일 전송 프로토콜을 사용하면 보내는 사람 또는 받는 사람의 요청에 따라서 데이터를 전송할 수 있다. 그러나 받는 쪽에서는 적은 양의 데이터만 처리할 수 있도록 허용한다.
- 뉴스 프로토콜은 많은 사람들에게 데이터를 퍼뜨릴 수 있도록 허용한다.
- Search 와 Retrieve 프로토콜은 인덱스를 사용해서 검색을 할 수 있게한다. 그리고 자료에 사용자가 접근하는 것을 허용한다. 현재 몇가지가 남아있는데 Z39.50 프로토콜은 우리의 필요에 따라 확장 될 수 있다.
Search는 단어를 찾은 결과가 강조된 단어, Retrieve는 정보를 찾는 과정의 느낌이 강한 단어 입니다.Z39.50은 도서관 데이터베이스에서 사람들이 데이터를 가져오는데 일반적으로 사용된 프로토콜입니다. 버너스리는 HTTP를 만들때 이 프로토콜에서 영감을 얻은듯 합니다.
정보에 접근하기 위해서 우리가 필요한 프로토콜은 다음과 같은것들이 제공 되어야 합니다.
- 부분적인 파일 전송 기능
- 인덱스 검색을 요청하는 기능
- 자동으로 포맷을 맞추는 기능
- 클라이언트가 다른 서버를 지시할 수 있는 기능
이 기능은 URL을 의미합니다.
팀 버너스리가 작성한 HTTP를 만든 이유 (1992년)
HTTP 0.9가 출시되면서 팀 버너스리가 작성한 HTTP를 만든 이유입니다. 아래의 내용들은 HTTP 0.9 스펙이 적힌 부분 중 목적에 해당하는 부분 입니다.
Purpose
When many sources of networked information are available to a reader, and when a discipline of reference between different sources exists, it is possible to rapidly follow references between units of information which are provided at different remote locations. As response times should ideally be of the order of 100ms in, for example, a hypertext jump, this requires a fast, stateless, information retrieval protocol.
목적
네트워크를 통해서 많은 자료들을 사람들이 접할 수 있게 된다면 그리고 다른 자료를 참조할 수 있는 규율이 자료 사이에 있다면, 다른 원격 저장소에서 제공된 참조 자료들을 빠르게 따라갈 수 있을 것이다. http의 응답 속도는 이상적으로 100ms가 되야 할것이다. 예를들어, 하이퍼텍스트에 들어가게 된다면 빠르고 상태가 없고 검색 가능한 프로토콜이 요구된다.
Practical information systems require more functionality than simple retrieval, including search, front-end update and annotation. This protocol allows an open-ended set of methods to be used. It builds on the discipline of reference provided by the Universal Resource Identifier (URI) as a name (URN, RFCxxxx) or address (URL, RFCxxxx) allows the object of the method to be specified.
실용적인 정보 시스템들은 retrieval, search, front-end update, annotation을 사용하고 있는 현 시스템 보다 간단한 검색 시스템이 필요합니다. 이 프로토콜은 제약이 없는 메소드들이 사용될 수 있도록 합니다. 이름 (URN, RFCxxxx) 또는 주소 (URL, RFCxxxx)가 메서드의 객체를 명시할 수 있도록 하는 참조 규칙을 기반으로 하는 Universal Resource Identifier (URI) 로부터 제공됩니다.
정보 시스템 이란 (information system) 개인 또는 집단에게 유용한 정보를 제공하는 시스템으로서, 주로 사람, 장소, 사물에 대한 정보를 가지고 있습니다.front-end update는 사용자의 화면이 갱신되는것을 의미합니다.메서드는 방법을 의미합니다. 그리고 객체는 (문장 내에서 동사의 행위가 미치는 대상) 입니다. 만약 get method를 사용해서 구글에 접속하면 get(동사)의 행위(가져와라)가 미치는 대상(구글 웹페이지)이 됩니다.URN은 (Uniform Resource Name)으로 말그대로 리소스에 id값과 같은 이름을 붙이는것 입니다. 팀 버너스리는HTTP 0.9 스펙 Request 부분을 통해 알 수 있듯이 URL을 사용할지 URN을 사용할지 고민했다고 합니다. URL은 버너스리가 만들었고 URN은 다른 연구원이 만들었습니다.
Reference is made to the Multipurpose Internet Mail Extensions (MIME, RFC1341) which are used to allow objects to be transmitted in an open variety of representations.
참조 자료는 객체가 여러가지 표시 방법으로 표현될 수 있는 Multipurpose Internet Mail Extensions (MIME, RFC1341) 으로 만들어집니다.
팀 버너스리는 MIME을 참고해서 HTTP를 만들었습니다. 이제 왜 HTTP에 이메일과 관련된 기술이 들어가있는지 이해가 되네요객체가 여러가지 표시 방법으로 표현될 수 있다는 말은 데이터마다 인코딩 방식을 다르게 할 수 있다는 말 로 추측 됩니다.
짧은 후기
HTTP에 대해서 다른 사람의 해석이 들어간 자료들을 보다가, 버너스리가 HTTP를 만들기 위해서 고민한것들을 직접 보면서 내가 사용하고 있는 HTTP 기술이 쉽게 만들어진것이 아니구나 라는 생각이 깊게 들었습니다.
또한 30년전에 작성된 글을 번역하면서 제가 탐험가가 된듯한 기분을 느끼기도 했습니다. 여러분들이 이 글을 읽고 조금이나마 도움이 되셨다면 좋을 것 같습니다 읽어주셔서 감사합니다.
번외) 팀 버너스리가 WWW를 만든 이유
https://www.youtube.com/embed/KCs7TPrVOe0
위 영상은 팀버너스리 인터뷰 영상입니다. 자료를 여러 사람과 쉽게 공유하기 위해서 WWW를 만들었다고 합니다. 버너스리의 열정도 느낄 수 있는 영상입니다.
'서버' 카테고리의 다른 글
CPU Burst, IO Burst (0) | 2023.06.29 |
---|---|
linux file descriptor (0) | 2023.06.05 |
간단하고도 빠른 서버 성능 최적화 (node js를 중심으로) (0) | 2023.05.04 |
Scale out에 적합한 로그인 환경에 대해 검토한 글 (2) | 2022.09.11 |
서버의 장애를 대비한 확장 방법 검토하기 (1) | 2022.09.11 |