HTTP/2와 HTTP/3

1. HTTP

HTTP 발전 과정

- HTTP/0.9(1991년) ▶️ HTTP/1(1996년) ▶️ HTTP/1.1(1997년) ▶️ HTTP/2(2015년) ▶️ HTTP/3(2020년)

 

HTTP/0.9(1991년)

- 최초 생성 시 버전이 없었으나 HTTP/1이 생기면서 구분하기 위하여 HTTP 0.9로 불리기 시작

- 단순 HTML만 전송 가능

- GET 메서드만 가능

 

HTTP/1(1996년)

- 헤더 등장

- 서버 상태 확인 가능

- HTML 외 컨텐츠 파일 전송 가능

- POST, PUT 메서드 추가

 

HTTP/1.1(1997년)

- 표준 모델

- Keep Alive 기능 추가

- 지속 커넥션 기능으로 TCP Connection 재활용

- 파이프라이닝 기능 추가

- OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE 메서드 추가

 

HTTP/2(2015년)

- 구글이 개발한 SPDY를 기반

- HTTP 헤더 압축

- 서버 푸시 기능 추가

- 바이너리 프로토콜로 변환

- 다중 처리 기능 추가

 

HTTP/3(HTTP over QUIC)(2019년)

- 구글이 개발한 QUIC(Quick UDP Internet Connections) 이용

- UDP로 변경

- QUIC 3 way handshaking 구현

- 보안 강화

 

2. HTTP/2 특징

HTTP/1.1 호환 가능

- 브라우저나 OS에 따라 HTTP/2를 미지원하기도 하여 호환 필요

- HTTP/2를 미지원하는 Client에서는 HTTP/1.1로 통신

 

HTTP 헤더 압축(Header compression)

- 헤더 테이블을 관리하여 이전 Request에 중복된 값은 인덱스 값만 전송하여 데이터 양을 줄임

- HTTP/1.1에서는 플레인 텍스트로 전송했지만 HTTP/2에서는 Huffman으로 인코딩하여 텍스트적인 압축

- HPACK 알고리즘을 통해 헤더의 크기를 80% 이상 압축 

 

 

서버 푸시(Server Push)

- Client가 단일 Request 혹은 Request 없이 Server가 Client가 필요할 Response(PUSH_PROMISE)를 보냄

 

바이너리 프로토콜(Binary Protocol)

- HTTP/1.1에서는 플레인 텍스트로 전송하였지만 HTTP/2에서는 프레임 구조(Header Frame, Data Frame)로 전송

- 바이너리 프로토콜은 Header Frame과 Data Frame(이진 데이터)으로 구성

- 프레임이 모여 메세지가 되고, 메세지가 모여 스트림이 됨(전송 단위 메세지)

 

다중 처리(Multiplexing)

- 지속 커넥션(Persistent Connection)으로 TCP Connection 재활용

- 파이프라이닝(Pipeling)으로 Reqeust를 여러개 날릴 수 있도록 함 

- 프레임마다 스트림(요청 순서 번호) 표기하여 Response 순서대로 받지 않아도 됨

- 스트림별 우선 순위 지정 가능(Prioritization)

 

HTTP HOL(Head of Line) Blocking 문제 해결

- HTTP HOL Blocking 문제 : HTTP/1.1에서도 파이프라이닝 가능했지만 여러개의 Request를 순서에 맞게 Response를 받아야만 했음(가장 먼저 받은 Reqeust의 Response의 지연 발생할 경우 이후 Requset들도 함께 지연 됨)

- HTTP/2에서는 다중 처리로 인하여 HTTP HOL Blocking 문제 해결

 

브라우저 웹 로딩 속도 빨라짐

- HTTP 헤더 압축 기능으로 데이터 양을 줄이고 압축

- 서버 푸시 기능으로 불필요한 Request 대기 시간 줄임

- 바이너리 프로토콜, 다중처리 기능으로 메세지를 프레임으로 쪼개고 다중 처리 가능

 

보안 강화

- TLS 필수

 

3.  HTTP/2 통신 과정

TLS Handsahking 과정 중 Client Hello 패킷과 Server Hello 패킷의 Extension : application_layer_protocol_negotiation(ALPN)필드에 현재 브라우저에서 지원 가능한 HTTP 버전 

Client Hello 패킷의 Extension : application_layer_protocol_negotiation

Server Hello 패킷의 Extension : application_layer_protocol_negotiation

HTTPS일 경우 Application Data 패킷은 암호화되어 HTTP 버전을 확인할 수 없음

Application Data

크롬 개발자도구에서의 HTTP/2 프로토콜

 

4. HTTP/3 특징

현재 실험 중으로 크롬 실험실에서 QUIC 기능을 켜야 HTTP/3를 제대로 테스트해볼 수 있습니다 🤔

 

QUIC(Quick UDP Internet Connections)

- 구글에서 개발한 프로토콜

- HTTP/2가 QUIC 위에서 동작

- IP가 아닌 Connection ID로 통신을 하여 IP가 바뀌어도 기존 연결을 유지할 수 있음

 

 

UDP로 변경

- TCP Handshaking 필요 없음

- UDP는 TCP보다 비교적 빠름

 

TCP와 UDP ▶️ https://eunhyee.tistory.com/96

TCP와 UDP

 

QUIC 3 way Handshaking

- TLS Handshaking 과정 포함

 

브라우저 웹 로딩 속도 빨라짐

- UDP 변경으로 속도 빨라짐(TCP와 UDP는 전송 계층으로 속도 차이가 있음)

- QUIC 3 way Handshaking 기능으로 Handshaking 과정 단축

첫 Application Data(1.180671) - DNS Query(0.000046) = 1.180624

첫 Application Data(0.740320) - DNS Query(0.503021) = 0.237299

 

보안 강화

- TLS 1.3 필수

 

참고 : https://velog.io/@zzzz465/HTTP1.1-2-3-%EC%9D%98-%EC%B0%A8%EC%9D%B4%EC%A0%90

HTTP/1.1, /2, /3 의 차이점

https://ably.com/topic/http3

HTTP/3 Deep Dive | Ably Realtime