[네트워크] HTTP 버전별 차이점(1.0, 1.1, 2.0, 3.0)
HTTP(Hyper Text Transfer Protocol)는 인터넷상에서 데이터를 주고받기 위한 프로토콜이다. HTTP는 오래전부터 인터넷상에서 사용되어져 왔는 만큼 여러 버전이 나오며 개선되어졌다. 현재는 대부분 HTTP 1.1을 사용하며 몇몇 IT기업에서는 2.0, 3.0까지 사용하고 있다. 이번 글에선 HTTP의 각 버전별 특징과 어떤 기술로 이전 버전의 문제점을 해결했는지 알아보자.
HTTP 0.9
1991년도에 등장하였으며 HTTP 초기 버전으로써 0.9 버전이라고 부른다. HTTP 초기버전은 매우 간단한 매커니즘을 가진다.
👉 HTML 파일만 전송가능
👉 GET method만 존재
JSON, 문자열 등 HTML 파일 외의 다른 타입으로 전송이 불가능했으며 메타데이터를 담을 헤더또한 존재하지 않았다. 데이터를 주고받기에는 유연하지 못하고 확장이 어려운 구조였다.
HTTP 1.0
1996년에 등장하였으며 단순한 HTML 파일 응답 도구였던 HTTP 초기버전에서 확장가능하고 유연한 프로토콜로 개선되었다.
HTTP 헤더 도입
HTTP 헤더가 도입되면서 메타데이터를 주고 받을 수 있게 되었다. 상태코드, User-Agent 등 통신 및 데이터에 대한 정보를 넣음으로써 유연하고 확장가능한 통신을 할 수 있게 되었다.
Content-Type 도입
HTTP 헤더 정보에 Content-Type이 추가되었다. 이 헤더 키에는 주고받는 데이터의 형식을 지정할 수 있다. text/html, application/json 등 여러가지 타입을 지정할 수 있다. 기존 HTML 파일만을 수신할 수 있었던 초기버전보다 유연하게 데이터를 주고받을 수 있게 되었다.
/* 요청 */
GET /index.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>
hello
</HTML>
Method 확장
기존 GET 요청만 가능했던 초기버전에서 POST, HEAD 메서드가 추가되었다. 보다 의미를 가지는 통신이 가능해졌다.
문제점
하나의 TCP Connection(handshake)에 하나의 요청만 가능하다는 문제가 있다.많은 요청을 한꺼번에 가져올때 딜레이가 길어지는 큰 단점이 존재한다.
HTTP 1.1
1997년에 등장하였으며 HTTP 1.0보다 응답속도 개선을 위한 기술들이 추가 되었으며 몇몇 헤더를 이용한 기술이 추가되었다. 현재 HTTP 1.1이 포준이다.
Persistent Connection(커넥션 유지)
keep-alive가 표준화되어 기본옵션으로 설정되었다. 기존 하나의 연결당 하나의 요청에서 하나의 TCP Connection안에서 여러 요청과 응답을 처리할 수 있게 개선되었다.
Pipelining(파이프라이닝)
Persistent Connection기능이 추가된 것 뿐만 아니라 동시 요청 기능인 파이프라이닝이 추가되었다. 기존 앞선 요청에 대한 응답을 받기 전까지 기다려야했지만 파이프라이닝은 앞선 응답을 받기전 요청을 할 수 있는 방법이다. 이를 통해서 전체적인 응답속도를 높일 수 있다. 하지만 파이프라이닝은 응답을 받기전 요청을 동시에 보낼 순 있지만 응답은 요청을 보낸 순서대로 받아야하기 때문에 HOL Blocking이라는 문제가 발생한다.
Host Header
가상 호스팅 기술이 생겨나 하나의 IP주소에 여러개의 도메인을 적용시킬 수 있게 되었다. 이때 클라이언트가 접속하고자하는 도메인을 알려줘야하는데 이를 Host 헤더에 담아서 보내준다.
💡 가상 호스팅
하나의 물리적인 서버에서 다수의 도메인을 호스팅하기 위해 가상으로 구분한 것을 말한다.
보통 웹서버를 이용해 구현하며 클라이언트측에선 각 도메인마다 다른 서버가 존재하는 것처럼 인식된다. 가상호스팅을 사용하면 물리적인 서버의 사용률을 효율적으로 높일 수 있다.
Improved Authentication Procedure(향상된 인증 절차)
기존에 서버 측이 클라이언트에 인증을 요구할때 www-authentication 헤더를 이용한다. 하지만 그 사이에 프록시가 존재한다면 프록시가 사용자의 인증을 요구할 방법이 없었다. 이 문제를 해결하기 위해 proxy-authentication(응답헤더) proxy-authorization(요청헤더)가 생겨났다.
문제점
- Head Of Line(HOC) Blocking
- 앞 요청의 응답이 오래 걸리면 뒷 요청의 응답이 Blocking되어 느려짐
- 무거운 헤더 구조
- 헤더에 많은 메타데이터가 존재하며 압축이 되어 있지 않아 크기가 무겁다
HTTP 2.0
2015년에 처음 등장하였으며 1.1에 비해 데이터 경량화 및 병렬처리 기술로 성능 향상시켰다.
바이너리 형식 전송
기존에는 일반 텍스트형식으로 전송되었지만 Binary Framing 계층을 추가해 보내는 메시지를 프레임 단위로 분할하고 바이널로 인코딩한다. 이는 파싱속도 및 전송속도가 빨라지고 오류 발생 가능성이 낮아지는 효과가 있다.
Multiplexed Streams(멀티플렉싱)
1.1버전의 파이프라이닝의 문제점인 HOLB 해결하였다. 하나의 커넥션 내에서 요청별 여러개의 스트림을 만들어 스트림별로 데이터를 수신받는다. 이를 통해 순차적 응답처리 문제를 해결하였다.
서버 푸시
기존엔 한번의 요청엔 하나의 응답만을 제공해야했지만 2.0 부터는 하나의 요청에 필요한 여러 응답을 push 할 수 있게 되었다.(html을 보내면서 연관된 css, script도 같이 보낼 수 있게 됨)
헤더 압축
1.1버전에서는 요청/응답마다 같은 헤더 정보를 반복해서 전달하는 문제점을 가지고 있다. 이는 결국 응답 시간을 늦췄었는데 2.0버전부터는 헤더의 반복 전송을 효율적으로 낮추기 위해 압축을 이용하였다. 허브만 인코딩을 이용하는 HPACK 압축형식으로 데이터를 압축하여 이용한다.
문제점
- TCP 고유의 HOL Blocking 존재
- Handshake의 RTT로 인한 지연
- 하나의 TCP 연결 내에서 이루어지기 때문에 하나의 패킷 손실이 모든 Stream에 영향을 미친다.
HTTP 3.0
가장 근래에 나온 HTTP 버전으로 Google에서 개발되었다. 최근(2022년 11월) 네이버가 3.0을 도입하면서 큰 이슈가 되었다. HTTP 3.0은 이전 버전들의 기반이 되었던 TCP에서 UDP로 기반 프로토콜을 변경하면서 속도가 크게 개선되었다.
QUIC
첫 연결 설정 시 신호 한 번만을 주고 받으면 된다. 뿐만 아니라 QUIC은 순방향 오류 수정 메커니즘(FEC)를 적용하여 패킷 손실시 수신 측에서 에러를 검출하고 수정하는 방식을 이용한다.
댓글남기기