HTTP/0.9 (the one-line protocol)
HTTP의 초기 버전.
요청을 단일 라인으로 구성되며 리소스에 대한 경로로 가능한 메서드는 GET이 유일했다. 응답도 매우 단순했다.
헤더가 없으므로 HTML 문서만 전송할 수 있었다. 상태/오류 코드도 없어서 오류 발생시 문서 내에 오류 내용을 추가해 전송하는 방식이었다.
HTTP/1.0 (building extensibility)
0.9버전보다 서버와 브라우저와 모두에게 융통성을 갖도록 확장된 버전.
각 요청에 HTTP 버전 정보가 붙기 시작했고,
응답 시작 부분에 상태 코드가 붙게 되어 브라우저가 요청에 대한 성공/실패를 인식하고 관련 동작을 할 수 있게 되었다.
헤더 개념이 도입되어, 메타데이터 전송을 허용하고 프로토콜을 극도로 유연하고 확장 가능하도록 만들었다. 또한 헤더의 Content-Type 덕분에 HTML 파일 이외 다른 문서도 전송이 가능해졌다.
HTTP/1.1 (the standardized protocol)
HTTP의 첫번째 표준 버전이다.
HTTP는 기본적으로 connectionless한 방식이지만, HTTP/1.1에 와서는 keepalive 기능을 통해 서버에 설정된 keepalive timeout 내에서는 별도의 연결과정 없이 데이터를 주고 받을 수 있게 되었다.
⇒ 즉, 내부적으로 매번 TCP 3-way handshake 과정을 거칠 필요가 없어졌다.
⇒ HTTP는 연결지향형 프로토콜이 아니다. 단순히 요청/응답으로 이루어진 응용 계층의 프로토콜일 뿐이다.
connection이 재사용될 수 있게 되어, 시간을 절약할 수 있게 되었다. (예를 들어, 하나의 웹페이지더라도 js 파일, css 파일 등 개별적으로 다 HTTP req/res 과정을 거쳐야 하는데, keepalive 기능 덕분에 그때마다 매번 TCP 3-way handshake을 거치지 않아도 된 것이다)
즉, HTTP 어플리케이션이 TCP connection을 요청할 때마다 닫지 않고 재사용할 수 있으므로 persistent connection이 가능해진 것이다. (이전까지는 한번 요청하면 무조건 닫았으므로 비효율적이었다)
⇒ HTTP keep alive는 이러한 persistent connection을 맺는 기법 중 하나로, 하나의 TCP connection을 사용해 여러개의 HTTP rep/res를 맺을 수 있도록 도와준다.
한번 TCP 3-way handshake을 거쳐서 연결이 되면 서버 내부적으로 설정된 일정 시간동안 연결을 유지한다. 그리고 나서 요청이 없으면 그제서야 4-way handshake을 진행해서 연결을 끊는다.
Pipelining이 추가되어, 첫번째 요청에 대한 응답이 완전히 전송되기 이전에 두번째 요청을 전송할 수 있게 되었다. 덕분에 latency of the communication를 낮출 수 있게 되었다.
1994년, HTTP에 가장 큰 변화가 일어난다. HTTP for secure transmissions를 사용하기 시작한 것이다. 기본적인 TCP/IP stack을 통해 HTTP를 전송하는 대신 Netscape Communications 회사는 이 토대 위에서 추가적인 암호화된 전송 계층인 SSL을 만들어냈다. 이후 SSL은 표준 토대가 되었고, TLS가 등장했다. 이 시기, 암호화된 전송 계층에 대한 필요성이 제기되면서 TLS의 필요성이 더욱 높아졌다.
나아가,
HTTP for complex applications를 사용하기 시작했다. 일종의 파일 시스템의 한 종류로서 생각되었던 웹은 특정 어플리케이션에 쓰이기 시작했다. 그리고 2000년, HTTP 사용에 대한 새로운 패턴이 고안되었다. REST(Representational State Transfer). 당시 API는 새로운 HTTP methods에 기반하기 보다는 HTTP/1.1 method와 함께 특정 URI에 대한 접근에 의존했다. 그러다보니 서버나 브라우저의 업데이트없이 데이터를 탐색하고 수정하곤 했다. 각각의 웹사이트들이 자신의 비표준 RESTful API를 정의하고 그에 대한 전권을 가지고 있었다. RESTful API는 2010년에 들어서야 매우 일반적이게 되었다.
HTTP/1.1 request 모습
상단에는 HTTP 메서드, path, HTTP 버전 순으로 작성되어 있다.
HTTP/1.1 response 모습
상단에는 HTTP 버전, status code, status message로 작성되어 있다.
status code 참고
-1xx(정보) : 요청을 받았으며 프로세스를 계속 진행합니다.
2xx(성공) : 요청을 성공적으로 받았으며 인식했고 수용하였습니다.
3xx(리다이렉션) : 요청 완료를 위해 추가 작업 조치가 필요합니다.
4xx(클라이언트 오류) : 요청의 문법이 잘못되었거나 요청을 처리할 수 없습니다.
5xx(서버 오류) : 서버가 명백히 유효한 요청에 대한 충족을 실패했습니다.
HTTP/2 (a protocol for greater performance)
웹 페이지는 몇년에 걸쳐 매우 복잡해지면서 진정한 어플리케이션으로 거듭나곤 한다. 더 많은 데이터와 더 많은 요청, 더 많은 스크립트 등.
2010년 전반기에, SPDY 프로토콜을 구현해 클라이언트와 서버 간 데이터 교환을 대체할 수단을 실증하면서 SPDY는 HTTP/2 프로토콜의 기초로서 기여했다.
HTTP/2는 구글의 비표준 개방형 네트워크 프로토콜(SPDY)에 기반한다. 기존의 HTTP method, status code 등 개념들은 호환된다.
기존 HTTP/1.1이 평문(plain text, 우리가 읽을 수 있는)을 사용한 프로토콜이라면, HTTP/2는 이진 프로토콜이다. 이진 프로토콜이 된 덕분에, 동일한 connection 상에서 병렬 요청이 이루어질 수 있게 되었고 순서를 제거해 HTTP/1.x의 제약사항을 막을 수 있게 되었다.
전송된 데이터의 중복을 제거함으로써 로드 속도를 개선했다.
참고
