HTTP/0.9 ~ HTTP/2.0 까지는 기본적으로 TCP 전송 프로토콜 사용
HTTP/3.0 은 UDP 프로토콜 사용
HTTP/1.0
/* 요청 */
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>특징
- 1996년에 발표
- HTTP 헤더 개념이 도입되어 요청과 응답에 추가됨 (단순 텍스트 기반 메시지 형식)
- 버전 정보와 요청 메서드가 함께 전송되기 시작
- 상태 코드가 응답의 시작 부분에 추가되어 요청의 성공과 실패의 파악이 가능해 짐
- Content-Type 도입으로 HTML뿐만 아니라 텍스트 파일, 이미지, 오디오, 비디오 등 다양한 형태의 데이터를 전송할 수 있게 됨
한계
- 커넥션 하나 당 요청 하나와 응답 하나만 처리 가능
- 매번 요청-응답 쌍마다 TCP 프로토콜 단계에서 3-way-handshake 및 4-way-handshake 과정이 필요
- 요청마다 새로운 TCP 연결을 설정하고 응답을 받은 후에 연결을 끊음
- 매우 비효율적이며, 서버 부하 문제도 생김
HTTP/1.1
/* 요청 */
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
(content)특징
- 1997년에 발표
- Keep-Alive 기능 도입
- 지정된 timeout 기간 동안 하나의 TCP 연결을 유지하며, 여러 번의 데이터 송수신이 가능
- 이를 통해 각 요청마다 새로운 TCP 연결을 설정하는 과정(handshaking)을 생략
- Pipelining 추가로 기존에 순차적으로 요청/응답이 처리되는 방식이 개선됨
- 하나의 커넥션에 여러개의 요청이 들어 있을 뿐, 동시에 여러개의 요청을 처리해 응답으로 보내
주는 것은 아니다 (multiplexing 되지는 않음)
- 하나의 커넥션에 여러개의 요청이 들어 있을 뿐, 동시에 여러개의 요청을 처리해 응답으로 보내
한계
- Head Of Line Blocking
- 순서대로 처리(요청/응답)하는 TCP의 특성으로, 첫 번째 처리가 완료되기까지 다른 요청들이 모두 대기하게 되는 문제
- 앞 요청의 응답이 너무 오래걸리면, 뒤 요청은 Blocking 되어버림
- 헤더 구조의 중복
- 연속된 요청의 경우 많은 중복된 헤더의 전송으로 오버헤드가 많이 발생
HTTP/2.0
특징
- 2015년도 발표
- HTTP 메시지 전송 방식의 전환
- 텍스트 형식에서 Binary Framing 계층을 추가해서 보내는 메시지를 프레임 단위로 분할하여
추가적으로 바이너리로 인코딩을 수행 - 바이너리 형식 사용으로 파싱속도 및 전송 속도가 빨라짐
- 텍스트 형식에서 Binary Framing 계층을 추가해서 보내는 메시지를 프레임 단위로 분할하여
- Multiplexed Streams 도입으로 병렬 요청이 이루어지는 다중화 프로토콜로 개선됨
- 프레임이 각 요청의 스트림을 통해 전달되며, 하나의 커넥션 안에 여러개의 스트림을 가질 수 있게되어
동시에 여러 요청을 처리하는 다중화가 가능해짐- 스트림을 통해서 각 요청의 응답의 순서가 의미가 없어져서 Head Of Line Blocking 문제 해결
- 스트림을 통해서 각 요청의 응답의 순서가 의미가 없어져서 Head Of Line Blocking 문제 해결
- Stream Prioritization 기능 도입
- 리소스간 우선순위를 설정할 수 있음
- 스트림에 우선순위를 부여해서 인터리빙되고 전달하는 것이 가능해짐
- Server Push 기능 도입
- 단일 클라이언트 요청에 여러 응답을 보낼 수 있는 특징을 통해 서버에서 클라이언트에게 필요한
추가적인 리소스를 push해주는 기능
- 단일 클라이언트 요청에 여러 응답을 보낼 수 있는 특징을 통해 서버에서 클라이언트에게 필요한
- Header Compression
- 요청과 응답의 헤더 메타데이터를 중복 제거 및 압축해서 오버헤드를 감소
- 요청과 응답의 헤더 메타데이터를 중복 제거 및 압축해서 오버헤드를 감소
한계
- 여전히 TCP 고유의 Head Of Line Blocking이 존재
- 서로 다른 스트림이 전송되고 있더라도 하나의 스트림에서 유실이 발생되거나 문제가 생기면 결국
다른 스트림도 문제가 해결될 때 까지 지연되는 현상이 발생되기 때문 - 이 문제를 해결하기 위해 UDP 기반 프로토콜인 QUIC / HTTP3.0이 등장
- QUIC은 독립적인 스트림 관리와 비순차적 데이터 전송을 함
- 서로 다른 스트림이 전송되고 있더라도 하나의 스트림에서 유실이 발생되거나 문제가 생기면 결국
ref.
https://csj000714.tistory.com/m/733
https://velog.io/@neity16/HTTP-HTTP-버전-별-특징
