HTTP (Hypertext Transfer Protocol)
- 웹 브라우저 상에서 데이터 교환의 기초가 되는 프로토콜
HTTP/1.0
- 매 요청마다 연결 및 해제 과정 발생
- Stateless의 특징을 살려 더 많은 연결을 하기 위함
- 매 연결에 대한 정보를 저장하지 않음으로 인한 리소스 절약 가능
- 그러나 100번의 요청이 이루어지면 100번의 연결 및 해제가 발생하고 이로 인한 오버헤드 발생 및 시간 지연
- 이를 보완할 필요성 대두
HTTP/1.1
- Persistent Connection, HTTP Pipelining 연결 방식 추가
Persistent Connection

- 서버는 응답을 보낸 후 TCP 연결을 그대로 유지
- 모든 요청, 응답이 Connection을 재상요하도록 설계되어 있으며 필요 없는 경우만 TCP연결을 종료하는 방식으로 변경됨
- 그러나 커넥션을 길게 유지하게 되는 TCP가 많아지며 서버의 자원이 고갈되면 다른 클라이언트들이 접속하지 못하는 상황 발생
Pipelining

- 위에 제시된 서버간 요청과 응답의 효율성을 개선하기 위해 만들어진 연결방식
- 기본적으로 HTTP 요청은 연속적이며 순차적으로 동작
- HTTP1.1에서는 요청에 대한 응답을 기다리지 않고 여러개의 요청을 하나의 TCP/IP 패킷으로 연속적으로 패킹해서 보냄
- 하나의 커넥션으로 다수의 요청 및 응답을 처리할 수 있게끔하여 네트워크 지연현상을 줄일 수 있다.
- 그러나 이러한 파이프라이닝도 단점이 존재
HOL (Head Of Line) Blocking (특정 응답의 지연)

- 파이프라이닝의 기능을 통해 여러 요청을 받고 처리하는 과정에서 특정 요청의 처리가 길어지면 나머지 요청들도 길어지는 처리를 기다려야한다.
HTTP/1.1의 문제점
- HOL blocking
- 3way handshake가 반복적으로 일어나며 불필요한 오버헤드 증가
- 무거운 헤더로 인한 불필요한 리소스 사용
HTTP/2.0
참고
HTTP/2.0에는 프레임이 존재
프레임은 HTTP/2.0에서 사용되는 가장 작은 단위를 의미하며 프레임 2개가 합쳐지면 스트림이 된다
프레임과 스트림을 통해 HOL Blocking을 해결
Binary Framing

- HTTP/1.1에서 Text 형식으로 전달하던 요청, 응답 메시지를 프레임 단위로 나누고, 바이너리 데이터로 인코딩
- 바이너리는 컴퓨터가 더욱 이해하기 쉽기에 파싱 및 전송 속도가 개선됨
**Multiplexed Streams**

- Connection한 개로 동시에 여러 개의 메시지를 주고 받을 수 있으며 응답은 순서에 상관없이 Stream으로 주고 받음
- 병렬적으로 처리
Stream Prioritization
- 스트림에 우선순위를 지정하는 방식
- 문서 내에 CSS 파일 1개와 이미지 파일 2개가 존재하고 이를 클라이언트가 요청하는 상황에서, 이미지 파일보다 CSS 파일의 수신이 늦어진다면 브라우저 렌더링에 문제가 발생. HTTP/2에서는 이러한 상황을 고려하여 리소스 간의 의존관계에 따른 우선순위를 설정하여 리소스 로드 문제를 해결
Server Push
- 서버는 클라이언트가 요청하지 않은 리소스를 사전에 푸쉬를 통해 전송할 수 있음. 이렇게 리소스 푸쉬가 가능해지면 클라이언트가 추후에 HTML 문서를 요청할 때 해당 문서 내의 리소스를 사전에 클라이언트에서 다운로드할 수 있도록 하여 클라이언트의 요청을 최소화 할 수 있음
- HTTP/1.1에서는 HTML문서를 요청하고, 해당 HTML에서 필요로 하는 CSS, Image같은 리소스가 필요할 경우 재요청을 보냄
- 그러나 HTTP/2.0의 ServerPush를 이용하면 클라이언트가 요청하지도 않은 HTML 문서에 포함된 리소스들을 Push해줌으로써 클라이언트의 요청을 최소화 할 수 있음
- 이를 PUSH_PROMISE라 부르며 PUSH_PROMISE를 통해 서버가 전송한 리소스에 대해 클라이언트는 요청을 보내지 않음.

- HPACK 알고리즘 사용
- 첫번째 요청에서 6개의 필드를 보냄
- 두번째 요청에서는 중복되는 5개의 필드를 제외한 1개의 필드만을 전송
- 이렇게 중복 헤더 데이터를 전송하지 않음으로써 오버헤드를 줄일 수 있음
- 같은 요청을 보내는 경우 헤더의 데이터가 변한 것이 없으므로 오버헤드는 0이 된다.
- 이렇게 헤더 중복을 제거하고, 허프만 인코딩 방식으로 한번 더 압축 진행
HTTP/3.0
- TCP/IP 기반의 애플리케이션 레이어 프로토콜인 HTTP를 UDP 기반의 QUIC(Quick UDP Internet Connections) 위에 얹음
- 이를 HTTP over QUIC라고 표현하며, 줄여서 HQ라 칭함
- HTTP/2.0에서 사용하던 프레임, 스트림 등은 그대로 HTTP/3.0으로 승계되었으며 명칭만 변경됨
- 데이터 그램 방식을 사용하는 UDP 프로토콜에 기반하기 때문에 순서가 존재하지 않는 독립적 패킷을 사용한다. 또한 데이터 그램 방식은 패킷의 목적지만 정해져있다면 중간 경로는 어디로 가든 신경쓰지 않기에 연결 설정 또한 하지 않는다. 이는 핸드쉐이크 과정이 필요 없다는 의미
- 이러한 이유로 속도가 빠르다
- 하지만 이러한 장점에 추가적으로 기존에 TCP가 가지던 신뢰성과 패킷의 무결함 또한 사라지지 않는다
- UDP는 커스터마이징이 용이하기에 기존의 TCP가 가지고 있던 기능 전부 구현할 수 있다.
예상질문
- HTTP/1.1과 HTTP/2.0의 차이점에 대해 설명해주세요
- HOL Blocking에 대해 설명해주세요
- HTTP/3.0의 주요 특징에 대해 설명해주세요
- TCP와 UDP의 차이에 대해 설명해주세요
- HTTP가 TCP를 사용하는 이유에 대해 설명해주세요
- HTTP/3.0에서 UDP(QUIC)를 사용하는 이유에 대해 설명해주세요
출처