HTTP의 역사

리얼월드 HTTP 2주차 스터디이다. 이번 스터디 내용은 Chapter1: HTTP/1.0의 신택스: 기본이 되는 네 가지 요소 이다.

본 포스팅에서는 리얼월드 HTTP책의 내용을 읽은 후 중요했던 내용, 나의 생각을 위주로 정리하였다.

그럼 시작하겠다.

HTTP의 역사

책의 시작 부분에서는 HTTP의 역사에 대해서 간략히 보여주고 있다. HTTP는 1990년 최초로 실제 동작 가능한 버전이 나왔고, 그 이후에 계속 버전 업이 이루어 졌다고 한다.

HTTP의 버전으로는 0.9, 1.0, 1.1, 2 가 있다

최초 버전인 HTTP/0.9는 HTML 도큐먼트를 요청해서 가져오기만 하는 단순한 프로토콜이었는데. 그 후로 폼을 전송하거나 정보를 갱신하기도 하고, 채팅 기능 구현에 사용되는 등 유연성을 보이면서 새로운 기능이 필요할 때마다 확장되었다.

우리가 흔히 사용하는 HTTP의 기능(생성, 수정, 채팅 등)이 최초의 HTTP부터 있었던 건 아니었다. 각 버전별로 필요에 의해 기능이 추가가 되었다는 것을 이 책에서 설명하고 있다.

HTTP/0.9

초기 버전인 HTTP/0.9는 매우 단순한 프로토콜이다.
웹사이트에 페이지를 서버에 요청하고, 그 응답으로 웹사이트의 내용을 받아온다. (이게 끝이다.)

또한 검색 기능은 이때 부터 지원을 하였다. 현재는 사라졌지만 과거의 HTML에는 <isindex> 라는 태그가 있었는데 이 태그를 사용하면 텍스트 입력란이 생겨 검색을 할 수 있었다고 한다. (지금의 form태그와 비슷한 거 같다)

HTTP/0.9 -> HTTP 1.0

HTTP/0.9버전은 매우 단순했지만 '브라우저가 문서를 요청하면, 서버는 데이터를 반환한다'라는 웹의 기본 뼈대는 완성이 되어 있었다. 하지만 이 프로토콜로는 할 수 없는 일이 많았다.

• 하나의 문서 밖에 전송하지 못함
• 통신되는 내용은 HTML로 한정 되어 있어서, 다운로드할 콘텐츠의 형식을 서버가 전달할 수단이 없었음
• 클라이언트 쪽에서 검색 이외의 요청을 보낼 수 없었음
• 새로운 문장을 전송하거나 갱신 또는 삭제할 수 없었음

0.9 버전이 문서화된 것은 1990년인데, 2년 후에는 전자메일이나, 뉴스그룹 같은 프로토콜의 기능을 도입해 대대적인 업데이트가 이루어 졌다. 대표적으로 다음과 같다.

• 요청 시 메서드가 추가됌(GET)
• 요청 시 HTTP 버전이 추가됌(HTTP/1.0)
• 헤더가 추가됌 (Host, User-Agent, Accept)
• 응답 시 선두에 HTTP 버전과 스테이터스 코드가 포함됌
• 응답 시 요청과 같은 형식의 헤더가 포함됌

전자메일과 뉴스그룹

전자메일

HTTP의 헤더는 인터넷이 보급되기 전 부터, 사용자 간 정보 교환으로 사용되던 메일 시스템에서 온 것이다. (1970년대 부터 헤더의 개념이 사용되었다고 한다 ..)

헤더와 전자메일의 차이는 다음과 같다

• HTTP 요청에서는 선두에 "메서드+패스" 행이 추가된다.
• HTTP 응답에서는 선두에 스테이터스 코드가 추가된다.

뉴스그룹

뉴스그룹 소개 시작 부분에 책에서 "처음 접한 컴퓨터가 윈도우 XP였거나 맥 OS X였던 사람은 만진 적도 어쩌면 들은 적도 없을 거다" 라고 한다. (그게 바로 나다.. 난 첫 컴퓨터가 윈도우 XP였다..)

뉴스그룹은 기사를 읽거나 투고하는 플랫폼이고, 뉴스라는 이름을 가지고 있지만, 대규모 전자 게시판으로 보면 된다고 한다.

주제 별로 그룹이 만들어져, 논의가 이루어지거나 소프트웨어 공개에 사용되곤 했다.
루비도 fj.comp.oops, fj.lang.misc 라는 그룹에 투고된 것이 최초의 공개라고 알려졌고,
파이썬도 alt.sources 그룹에 1991년에 투고된 것이 최초의 공개라고 한다.

이러한 뉴스그룹으로 부터 HTTP는 메서드와 스테이터스 코드라는 두 가지 기능을 도입했다

평소에 아무런 생각 없이 사용하던 GET, POST, PATCH 이런 메서드들과, 201, 200, 404, 400, 500 이런 스테이터스 코드들이 이런 역사가 있었다는 걸 알게되니 더 재밌어진다. 이 책을 읽다보면 정말 내가 과거에서 HTTP 개발 과정을 함께 지켜보는 것 같은 기분이 든다..

메서드와 스테이터스 코드

메서드와 스테이터스 코드는 뉴스 그룹 에서 가져온 기능들이다.

메서드

뉴스그룹의 메서드로는 그룹 목록 취득(LIST), 헤더 취득(HEAD), 기사 취득(BODY), 투고(POST) 등이 있었다.

HTTP의 메서드중 자주 쓰이는 것은 다음과 같다.

• GET: 서버에 헤더와 콘텐츠 요청
• HEAD: 서버에 헤더만 요청
• POST: 새로운 문서 투고

아래 두 메서드는 1.0 이후에도 살아남았지만, 1.0 단계에서는 필수가 아니라 구현에 따라 제공되기도 하고, 제공되지 않기도 하는 옵션 기능이다.

• PUT: 이미 존재하는 URL의 문서를 갱신
• DELETE: 지정된 URL의 문서를 삭제함, 삭제에 성공하면 삭제된 URL은 무효가 됨

아래 메서드는 1.0에는 남았지만, 1.1에서 삭제됌

• LINK: 문서 간의 링크를 만듬.
• UNLINK: 문서 간의 링크를 삭제함.

이 외에도 1992년에 제안은 됐지만 1.0의 제안에서는 삭제된 메서드들도 존재한다.
CHECKOUT, CHECKIN, SHOWMETHOD, TEXTSEARCH, SEARCHJUMP, SEARCH ...

스테이터스 코드

스테이터스 코드는 세 자리 숫자이고, 이 숫자를 보고 서버가 어떻게 응답했는지 한눈에 알 수 있다.
크게 다섯 가지 카테고리로 나눌 수 있다.

• 100번대: 처리가 계속 됨을 나타냄. 1xx 계열은 특수한 용도로 사용함
• 200번대: 성공했을 때의 응답. 자주 사용되는 스테이터스 코드는 200 OK로 정상종료를 나타냄
• 300번대: 서버에서 클라이언트로의 명령. 오류가 아니라 정상 처리의 범주. 리다이렉트나 캐시이용을 지시함
• 400번대: 클라이언트가 보낸 요청에 오류가 있음
• 500번대: 서버 내부에서 오류가 발생함

기존 개발을 했을 때는 200, 400, 500번대만 자주 사용을 하다 보니 100, 300에 대해서는 잘 몰랐었다.
11장에서 더 자세히 설명한다고 하니 그때 더 자세히 배울 수 있을 거 같다

리다이렉트(리디렉트)

300번대 스테이터스 코드의 일부는 서버가 브라우저에 대해 리다이렉트 하도록 지시하는 코드이다.

• 301/308: 요청된 페이지가 다른 장소로 이동했을 때 사용한다. 영구적으로 이동한다. 검색 엔진도 이 응답을 받으면 기존 페이지의 평가를 새로운 페이지로 계승한다. 구글은 검색 엔진에 페이지 이동을 전하는 수단으로서 301을 사용할 것을 권장한다.
• 302/307: 일시적인 이동이다. 모바일 전용 사이트로 이동하거나 관리 페이지를 표시한다.
• 303: 요청된 페이지에 반환할 콘텐츠가 없거나 혹은 원래 반환할 페이지가 따로 있을 때, 그쪽으로 이동시키려고 사용한다.예를 들면, 로그인 페이지를 사용해 로그인한 후 원래 페이지로 이동하는 경우에 사용한다.

URL

URL은 HTTP/1.0보다 빠른 시기에 만들어 졌다고 한다.
평소에 URL, URI에 대해서 어떤 차이가 있는지 궁금했었다. 책에서 설명하기를 URI의 일부로 URL이 등장했다고 하고, 웹 시스템을 다루는 한 URL과 URI는 거의 같다고 한다.

그렇다면 정확히 URL과 URI의 차이점은 무엇일까?

간단하게 요약해서 URI는 네트워크 상 자원을 가리키는 일종의 고유 식별자(ID)이고, URL은 URI에 포함되는 개념이며 자원의 위치(Location)를 의미한다고 한다. 또 여기서 URN이라는 개념도 나오는데 URN도 URI의 포함되는 개념이고, 자원의 이름(Name)을 의미한다고 한다.

일반적으로 자주 보는 URL은 다음과 같은 형식이다.
https://section.cafe.naver.com/ca-fe/

여기서 URL의 구존는 아래와 같다

스키마://호스트명/경로

• 스키마: https
• 호스트명: section.cafe.naver.com
• 경로: ca-fe

바디

우리는 평소에 Post 요청을 보낼때 body의 값을 담아서 데이터를 서버에 보낸다. 하지만 과거 HTTP/0.9 사양에서는 요청에 데이터를 포함할 수 없었다.

HTTP/1.0이 되서야 요청에 body로 값을 보낼 수 있게 되었다.
하지만 모든 메서드에서 body를 보내는 것을 기대하는 것은 아니다.
Get 메서드는 함께 바디를 보낼 수 있지만, 그렇게 하는 것은 추천하는 방식이 아니다.

이 내용에 관한 스택 오버플로우 질문이다
https://stackoverflow.com/questions/978061/http-get-with-request-body

질문의 답변에 해당하는 내용을 책에서 번역을 해주고 있다.

그렇습니다. 다시 말해서 어떤 HTTP 요청 메세지라도 메시지 바디 포함이 허용되며 이를 염두에 두고 해석할 필요가 있습니다. 그러나 서버는 GET의 바디가 있어도 요청에 대해 뭔가 의미를 얻지 못하게 제한됩니다. 해석 여부와 메서드의 시맨틱스는 별개입니다.
GET과 함께 바디를 보낼순 있찌만, 그렇게 하는 것이 결코 유용하진 않습니다

라고 나와있다.