HyperText Transfer Protocol
말 그대로 "하이퍼텍스트를 전송하는 규약"
쉽게 말해, 웹 브라우저(클라이언트)와 웹 서버 사이에 HTML 문서, 이미지, 동영상 등의 자원을 전송하기 위해 정해진 규칙 또는 약속이다.
웹 개발자라면 당연히 http라는 단어는 항상 보고, 듣기 때문에 익숙하지만, 그 버전에 대해서는 잘 모르기도 하고, "당연히 최신 표준을 사용하면 좋은거 아니야?"라고 생각할 것이다.
하지만 여러가지 상황에 따라 버전업을 통해 얻는 효과가 다르고, 그 때에 함께 변경해주어야 하는 설정 등에 주의해야 한다.
차이점이 너무 많은데...
도와줘 GPT!
| 특징 | HTTP/1.1 | HTTP/2 | HTTP/3 |
|---|---|---|---|
| 기반 프로토콜 | TCP | TCP | UDP 기반 QUIC |
| 메시지 형식 | 텍스트(Plain Text) | 이진(Binary) | 이진(Binary) |
| 동시성 처리 | HOL 블로킹 발생, 직렬 (다중 TCP 연결 필요) | 멀티플렉싱으로 병렬 처리 (TCP HOL 블로킹 잔존) | QUIC 스트림으로 완전한 병렬 처리 (HOL 블로킹 해결) |
| 연결 수립 | 다중 요청 시 TCP 연결 재사용 (Keep-Alive) | 단일 TCP 연결 | 더 빠름 (QUIC Handshake로 통합) |
| 헤더 | 압축 없음 (반복 전송) | HPACK으로 압축 | QUIC 내에서 효율적인 압축 |
이 표에서 정말 과장없이 모든 특징들이 다 중요하다...
TCP 연결에서는 신뢰성 있는 데이터 전송을 보장하기 위해 3-Way Handshake 과정이 필요하기 때문에 클라이언트와 서버 사이에 연결을 하는 자체만으로 상당한 시간이 소요된다.
그래서 HTTP3는 지연시간을 최소화하기 위해 UDP 기반 연결을 사용하며 UDP의 신뢰성 문제점을 해결하기 위해 QUIC이라는 기술을 도입했다.
HTTP/2로 업그레이드 되면서 기존의 일반적인 텍스트 형식에서 이진 형식으로 변경되어, http 요청을 보다 효율적이고 빠르게 처리할 수 있게 되었다.
http/1.1에서는 하나의 연결 당 하나의 요청만 처리할 수 있다. 그래서 한 번에 여러 개의 요청을 처리할 수 있도록 여러 개의 연결을 가능하게 했지만, 너무 많은 요청을 방지하기 위해 6~8개로 제한을 두었다.
하나의 연결에서 하나의 요청이 끝나면 해당 연결을 재사용하여 이후의 요청을 또 보내기 때문에, 문제가 발생하면 다음 요청이 지연되는 HOL Blocking 문제가 있다.
http/2에서는 기존 http/1.1의 HOL Blocking 문제를 완화하고 전송 속도 및 서버 부하를 개선하고자 멀티플렉싱 기술을 도입하였다. 하나의 연결만을 사용하면서도 여러 요청을 병렬적으로 처리할 수 있도록 하여 서버에서 TCP 소켓을 관리하는 부담을 줄이고, 하나의 요청에 문제가 생겨도 다른 요청들이 지연되지 않도록 하였다.
하지만 하나의 TCP 패킷이 손실되거나 지연되면, 이 패킷이 재전송되어 도착할 때까지 그 이후에 도착한 모든 패킷들은 버퍼에 대기해야 하는데, 멀티플렉싱은 여러 스트림의 데이터를 하나의 TCP 연결에 섞어서(interleaving) 전송하기 때문에, 특정 스트림의 데이터 패킷 하나가 손실되면, 해당 TCP 연결을 사용하는 다른 모든 스트림의 데이터 전송까지 함께 멈추고 지연되는 현상이 발생하므로 HOL Blocking 문제를 완전히 해결하지는 못했다.
http/3에서는 TCP 연결을 사용하지 않기 때문에 패킷에 문제가 생겨도 이후에 전송된 패킷이 이를 기다리지 않아 근본적으로 HOL Blocking 문제가 해결되었다.
잘보고갑니다 ^0^