HTTP 1.1 2.0 3.0
HTTP 1.1이 느린 이유
-
연결당 하나의 요청과 응답을 처리하기 때문에 동시 전송 문제와 다수의 - 리소스를 처리하기에 속도와 성능 이슈가 존재
- HOL(Head Of Line) Blocking (특정 응답 지연)
-
HTTP/1.1의 사양상의 제한으로 클라이언트의 리퀘스트의 순서와 서버의 응답순서는 동기화해야 됨
-
RTT(Round Trip TIme) 증가 (양방향 지연)
-
헤더가 크다 (특히 쿠키 때문)
-
http/1.1의 헤더에는 많은 메타 정보들이 저장되어 있음.
-
사용자가 방문한 웹페이지는 다수의 http 요청이 발생하게 되는데 이 경우 매 요청시 마다 중복된 헤더 값을 전송하게 되며 각 도메인에 설정된 쿠키 정보도 매 요청시 마다 헤더에 포함되어 전송
-
HTTP 2.0이 빠른 이유
-
Multiplexed Streams (한 커넥션에 여러개의 메세지를 동시에 주고 받을 수 있음)
-
요청이 커넥션 상에서 다중화 되므로 HOL(Head Of Line) Blocking 이 완화됨
-
Stream Prioritization (요청 리소스간 의존관계를 설정)
-
Header Compression (Header 정보를 HPACK 압축 방식을 이용하여 압축 전송)
-
Server Push (HTML문서 상에 필요한 리소스를 클라이언트 요청없이 보내줄 수 있음)
-
프로토콜 협상 메커니즘 - 프로토콜 선택, 예. HTTP / 1.1, HTTP / 2 또는 기타.
-
HTTP / 1.1과의 높은 수준의 호환성 - 메소드, 상태 코드, URI 및 헤더 필드
-
페이지 로딩 속도 향상
HTTP 3.0
-
TCP가 아닌 UDP를 사용
-
HTTP3는 QUIC라는 프로토콜 위에서 돌아가는 HTTP인데, QUIC는 Quick UDP Internet Connection의 약자로 UDP를 사용하는 프로토콜
-
TCP는 3 way hand shake, 끝날 때 4way hand shake 등 오버헤드와 HOLB 등의 문제를 피할 수 없다.
-
QUIC는 TCP hand shake 과정을 최적화하는 것에 초점을 맞추어 설계
-
UDP는 데이터그램 방식을 사용하는 프로토콜이기에 각각의 패킷 간 순서가 존재하지 않는 독립적인 패킷
-
UDP는 TCP에 비해 헤더가 많이 비어있기에, 커스터마이징할 수 있는 여지가 많고 이를 이용해 개발자가 구현을 어떻게 하느냐에 따라서 신뢰성을 확보
Reference
https://velog.io/@kcwthing1210/HTTP-1.1-vs-HTTP-2.0-vs-HTTP-3.0
