📌 HTTP 1.1
✅ HTTP 1.1이 느린 이유
- 연결당 하나의 요청과 응답을 처리하기 때문에 동시 전송 문제와 다수의 - 리소스를 처리하기에 속도와 성능 이슈가 존재
- HOL(Head Of Line) Blocking (특정 응답 지연)
- HTTP/1.1의 사양상의 제한으로 클라이언트의 리퀘스트의 순서와 서버의 응답순서는 동기화해야 됨
- RTT(Round Trip TIme) 증가 (양방향 지연)
- 헤더가 크다 (특히 쿠키 때문)
- http/1.1의 헤더에는 많은 메타 정보들이 저장되어 있음.
- 사용자가 방문한 웹페이지는 다수의 http 요청이 발생하게 되는데 이 경우 매 요청시 마다 중복된 헤더 값을 전송하게 되며 각 도메인에 설정된 쿠키 정보도 매 요청시 마다 헤더에 포함되어 전송
📌 HTTP 2.0
✅ HTTP/2.0의 등장
- SDPY(구글 제안 프로토콜) 기반으로 HTTP/2.0 등장
- HTTP/2.0은 HTTP/1.1이 느려서 버전을 개선한 것
✅ 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에 비해 헤더가 많이 비어있기에, 커스터마이징할 수 있는 여지가 많고 이를 이용해 개발자가 구현을 어떻게 하느냐에 따라서 신뢰성을 확보할 수 있다.
✅ QUIC
✔ 연결 레이턴시 감소
RTT : Round Trip Time. 클라이언트가 요청하고 서버가 처리해 다시 응답해주는 사이클
HTTPS over TCP + TLS 소요 레이턴시 : 1RTT(TCP) + 2RTT(TLS) = 3RTT
HTTPS over QUIC 소요 레이턴시 : 1RTT
첫번째 hand shake를 할 때 연결 설정에 필요한 정보와 데이터를 함께 보내 RTT를 것이다. TCP+TLS는 데이터 보내기 전 신뢰성 있는 연결과 암호화에 필요한 정보를 교환 후 데이터를 교환한다.
✔ 패킷 손실 감지에 걸리는 시간 단축
TCP는 송신 측이 패킷을 보낸 후 타이머를 사용해 일정 시간 동안 응답이 오지 않으면 패킷이 손상되었다고 판단해 재전송한다. 이때 문제는 TCP가 타임아웃을 언제 낼 것인가를 동적으로 계산해야 한다. 패킷 재전송시 ACK을 받았을 때 첫 번째로 보낸 패킷의 ACK인지 두 번째로 보낸 패킷의 ACK인지 확인해야 한다. 이를 재전송 모호성이라고 한다.
QUIC는 헤더에 별도의 패킷 번호 공간을 부여해 패킷 손실 감지에 걸리는 시간을 단축한다.
✔ 멀티플렉싱 지원
여러 개의 스트림을 사용하면 특정 스트림의 패킷이 손실되어도 해당 스트림에만 영향을 미치고 나머지 스트림은 멀쩡히 사용할 수 있다.
HTTP2와 마찬가지로 멀티플렉싱을 지원해 이점을 그대로 가져간다
✔ 클라이언트의 IP가 바뀌어도 연결 유지
TCP는 발신지 IP, 발신지 port, 수신지 IP, 수신지 port로 연결을 식별해 클라이언트 IP가 바뀌면 연결이 끊어져 버린다. 이는 다시 연결을 생성하기 위해 3 way hand shake를 다시 해야하고, 레이턴시가 또 다시 발생된다.
요즘같이 모바일로 인터넷을 사용하는 경우 wifi에서 셀룰러로 전환될 때 클라이언트 IP 전환되는 경우가 많아 문제가 심각해진다.
QUIC는 connection ID사용해 서버와 연결을 생성한다. 이는 클라이언트 IP와는 전혀 무관하기 때문에 클라이언트 IP가 변경되더라도 기존의 연결을 계속 유지할 수 있다.
🧩 Reference
