HTTP/0.9
HTTP의 초기 버전에는 버전 정보가 없었고 차후 버전과 구별하기 위해 0.9로 불리게 되었다고 한다.
-
사용가능한 메서드는 GET이 유일
-
HTTP 헤더가 없기 때문에 전송은 HTML 문서만 가능
-
응답은 오로지 파일 내용 자체로 구성 ( 상태 혹은 오류 코드가 존재하지 않았음 )
GET /mypage.html
<HTML>
A very simple HTML page
</HTML>HTTP/1.0
HTTP/0.9는 매우 제한적이었으며 브라우저와 서버 모두 좀 더 융통성을 가지도록 빠르게 확장하였다.
-
HTTP 헤더 개념 도입
-
HTML 파일들 외에 다른 문서들을 전송하는 기능이 추가
Content-Type -
상태 코드 도입
응답 시작 부분에 상태코드가 붙게되면서 브라우저가 요청 성공 실패여부를 알 수 있다. -
POST 메서드 추가
GET /mypage.html HTTP/1.0
User-Agent: NCSA_Mosaic/2.0 (Windows 3.1)
200 OK
Date: Tue, 15 Nov 1994 08:12:31 GMT
Server: CERN/3.0 libwww/2.17
Content-Type: text/html
<HTML>
A page with an image
<IMG SRC="/myimage.gif">
</HTML>- 기본적으로 Connection당 하나의 요청을 처리 하도록 설계
요청을 보낼 때마다 커넥션들이 새롭게 생성되며 응답이 오면 연결을 닫는 단기 형태로 유지되었다. 이는 TCP 상에서 동작하는 HTTP의 특성상 3-way-Handshake가 반복적으로 일어나게 되며, 불필요한 RTT 증가와 네트워크 지연을 초래하여 성능을 저하시킨다.
RTT (Round Trip Time, 왕복 시간)
패킷망(인터넷) 상에서 상대측 호스트까지 패킷을 보내고 해당 패킷에 대한 응답이 출발지로 다시 돌아오기까지의 시간
HTTP/1.1 – 표준 프로토콜
HTTP/1.1은 HTTP의 첫번째 표준 버전이며 메서드에 OPTION, PUT, DELETE, TRACE가 추가되었다.
- Persistent Connection 와 HTTP Pipelining
기존 모델의 단점을 해결하고자 한 번 열린 커넥션을 재사용하는 Persistent Connection이라는 개념과 여러개의 HTTP 요청을 할 수 있는 HTTP Pipelining이라는 개념등이 생겨나게 되었다.
- 요청과 응답이 순차적
HOL (Head Of Line) Blocking
다음의 그림과 같이 1.png, 2.png, 3.png를 요청하는 HTTP 요청이 있을 때, 1.png의 응답에 지연이 있을 시 2,3png는 대기하게 되는데 이와 같은 문제를 HOLB이라고 한다.
HTTP/2
- Multiplexed Streams
HTTP 메시지를 바이너리 형태의 프레임으로 나누고 TCP 연결 하나로 여러 요청과 응답들을 병렬적으로 보내는 특징을 가지며 순서가 뒤섞이더라도 수신측에서 재조립한다.
따라서 여러 개의 연결없이 병렬처리도 가능해지며 HOLB 문제도 해결 할 수 있게되었다.
프레임: HTTP/2 통신의 최소단위로 프레임에는 프레임 헤더가 포함되어 있다. (이 프레임 헤더로 프레임이 속하는 스트림을 식별할 수 있다)
메시지: 다수의 프레임으로 이루어진 것(즉, 우리가 평소에 HTTP를 사용해서 보내는 메시지를 잘개 쪼갠 것이 프레임이라고 생각하면된다.)
스트림: 서버와 클라이언트 사이에 주고받는 단위로 하나의 메시지 또는 복수개의 메시지로 이루어져있다.
- Header Compression
이전 Header의 내용과 중복되는 필드를 재전송 하지 않도록 하고 HPACK이라는 Header 압축방식을 이용하여 데이터 전송 효율을 높인다.
여전히 TCP를 사용하여 근본적인 원인(Handshake의 RTT로 인한Latency)은 해결하지 못해 UDP를 사용하는 HTTP/3가 등장
HTTP/3
UDP를 기반으로 하는 QUIC 프로토콜을 사용
- Handshake Latency 감소
이례적으로 이전의 버전들과 달리 UDP를 기반으로 하는 QUIC 프로토콜을 사용함으로써 새로운 연결에 대해 Handshake로 인한 Latency를 감소 시킬 수 있다.
QUIC는 TCP가 가지는 문제점들을 해결하고자 구글이 개발한 UDP 기반의 프로토콜
- TCP의 HOLB 개선
그리고 TCP를 사용한 통신에서는 패킷 손실이 발생할 경우 TCP의 HOLB은 여전히 발생했는데 HTTP/3에서는 UDP를 사용하기 때문에 패킷 손실로 인한 지연으로부터 자유로워질 수 있게 된다. (하지만 그렇다고 TCP가 가지던 신뢰성을 포기하지 않았음)
Reference
