HTTP 초기 버전에는 버전 번호가 없었다.
HTTP 0.9 이후에 차후 버전과 구별하기 위해 버전 번호가 명시되었다.
HTTP/0.9 : 원-라인 프로토콜
- 특징
요청이 단일 라인으로 구성되어 리소스에 대한 메서드는 GET이 유일하다.
| 요청
GET /mypage.html
| 응답
A very simple HTML page
HTTP/1.0 : 확장성 만들기
핵심 : 여러 메타정보(헤더)가 포함되기 시작했다.
-
특징
HTTP 헤더 개념이 도입되어 요청과 응답에 추가되었다.
메타데이터를 주고 받고 프로토콜을 유연하고 확장 가능하도록 개선하였다.
버전 정보와 요청 메서드가 함께 전송되기 시작했다.
상태 코드 라인도 응답의 시작 부분에 추가되어 브라우저 요청의 성공, 실패 여부를 파악할 수 있다.
Content-Type 도입으로 HTML 이외에 문서 전송 기능이 가능하다. -
한계
커넥션 하나 당 요청 하나, 응답 하나만 처리가 가능했다. (HTTP 1.1에서 개선)
| 일반적 요청
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
A page with an image
| 이미지 요청
GET /myimage.gif HTTP/1.0
User-Agent: NCSA_Mosaic/2.0 (Windows 3.1)
| 이미지 응답
200 OK
Date: Tue, 15 Nov 1994 08:12:32 GMT
Server: CERN/3.0 libwww/2.17
Content-Type: text/gif
(image content)
HTTP/1.1 : 표준 프로토콜
핵심 : 사용된 커넥션을 다시 열어 시간을 절약했다
-
특징
- Persistent Connection 추가
- 지정한 timeout 동안 커넥션을 닫지 않는 방법을 통해 커넥션 사용성 증가
- Pipelining 추가
- 여러 개의 요청을 보낼 때 처음 요청이 응답될 때까지 기다리지 않고 바로 요청을 보내는 것을 의미한다.
- 순차적으로 하나씩 요청 / 응답이 처리되는 기존 방식을 개선하여 많은 대기 시간을 줄일 수 있다.
- 동시에 여러 개의 요청을 처리하는 것(멀티플렉싱)이 아니다. -
한계
- Head Of Line Blocking (HOL)
- 앞선 요청의 응답이 오래 걸리면 기다리는 요청은 Blocking 된다.
- Header 구조 반복
- 연속된 요청이 이어질 경우 헤더의 많은 중복이 발생한다.
| 요청
GET /en-US/docs/Glossary/Simple_header HTTP/1.1| 응답
Host: developer.mozilla.org
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0) Gecko/20100101 Firefox/50.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Referer: https://developer.mozilla.org/en-US/docs/Glossary/Simple_header
200 OK
Connection: Keep-Alive
Content-Encoding: gzip
Content-Type: text/html; charset=utf-8
Date: Wed, 20 Jul 2016 10:55:30 GMT
Etag: "547fa7e369ef56031dd3bff2ace9fc0832eb251a"
Keep-Alive: timeout=5, max=1000
Last-Modified: Tue, 19 Jul 2016 00:59:33 GMT
Server: Apache
Transfer-Encoding: chunked
Vary: Cookie, Accept-Encoding
HTTP/2 : 멀티플렉싱
핵심 : 기존 HTTP 1점대 버전의 성능 향상에 초점을 맞춘 프로토콜
특징
1. HTTP 메시지 전송 방식의 전환
2. Multiplexed Streams
3. Stream Prioritization
4. Server Push
5. Header Compression
| HTTP 메시지 전송 방식의 전환한계
기존 : 일반 텍스트 형식
개선 : Binary Framing 계층을 추가해서 보내는 메시지를 프레임이라는 단위로 분할하며 추가적으로 바이너리로 인코딩한다. (바이너리 형식 사용으로 파싱 속도 및 전송 속도가 빠르고 오류 발생 가능성이 낮아진다. )
| Multiplexed Streams
기존 : HTTP 1.1의 파이프라이닝으로 하나의 커넥션에 여러 요청이 있지만, 동시에 여러 개의 요청을 처리해주지는 않았다.
개선
- 바이트의 양방향 흐름을 의미하는 Stream으로 요청 / 응답이 교환된다. (하나의 커넥션 내 여러 개의 Stream 존재 가능)
- 메시지가 이진화된 텍스트인 프레임으로 나뉘어 요청마다 구분되는 Stream을 통해 전달
- 즉, 프레임이 각 요청의 스트림을 통해 전달되며 하나의 커넥션 안에 여러 개의 스트림을 가질 수 있게 되어 멀티플렉싱(다중화)이 가능해졌다.
=> 동시에 여러 요청을 처리하는 것이 가능해졌다.
=> Stream을 통해서 각 요청의 응답의 순서가 의미가 없어져서 HOL Blocking이 자연스럽게 해결되었다.
| Stream Prioritization
리소스 간 우선순위를 설정하는 기능
Stream에 우선순위를 부여해서 인터리빙(끼워넣기)되고 전달하는 것이 가능해졌다.
| Server Push
단일 클라이언트 요청에 여러 응답을 보낼 수 있는 특징을 이용해 Server에서 Client에게 필요한 추가적인 리소스를 Push해주는 기능
| Header Compression
기존 : 연속된 요청의 경우 많은 중복된 헤더의 전송으로 오버헤드가 많이 발생했다.개선 : 요청과 응답의 헤더 메타데이터를 압축하여 오버헤드를 감소
1. 전송되는 헤더 필드를 static dynamic table로 서버에서 유지
2. 이전에 표시된 헤더를 제외한 필드를 허프만 인코딩(데이터를 압축하는 알고리즘)을 수행하여 데이터를 압축
- 각 요청마다 Stream으로 구분해서 병렬적으로 처리가 가능하지만, 결국 TCP 고유의 HOL Blocking 존재
- 왜냐하면 서로 다른 Stream이 전송되고 있을 때 하나의 Stream에서 데이터 유실이 발생되거나 문제가 생기면
결국 다른 Stream도 문제가 해결될 때까지 지연되는 현상이 발생되기 때문이다.
HTTP/3 : HTTP Over QUIC
- HTTP/3
QUIC를 기반으로 나온 새로운 HTTP 메이저 버전
- QUIC
1. Google에서 개발한 UDP 기반의 전송 프로토콜(Quick UDP Internet Connections)이다.
2. Google에서 TCP의 구조적 문제로 성능 향상이 어렵다고 판단하여 UDP 기반을 선택하였다.
3. TCP의 3-way handshake 과정을 최적화하는 것에 초점을 두고 개발되었다.
4. TCP의 Stream은 하나의 chain으로 연결되는 것과 다르게 각 Stream 당 독립된 Stream Chain을 구성하여
TCP HOL Blocking 문제를 해결했다.
