[네트워크] HTTP/1.1 → HTTP/2 → HTTP/3

 

반응형

이미지 출처:  https://dev.to/saikumar2121/http-11-vs-2-vs-3-370f

 

🌏 HTTP/1.1 → HTTP/2 → HTTP/3

✅ HTTP/1.0

처음 웹이 퍼질 때 만들어진 규칙으로 가장 간단함

• 기본적으로 한 연결당 한 요청-응답만 처리 후 연결 종료 (Non-persistent)
  • 요청마다 TCP 연결을 새로 맺어야 했기 때문에 오버헤드가 매우 큼

✅ HTTP/1.1

• Persistent Connection(Keep-Alive)
  • 기본적으로 Persistent Connection(Keep-Alive)이 기본 동작
    • 즉, 한 연결을 여러 요청/응답에 재사용할 수 있음
    • 여전히 한 연결에서 요청은 순차적으로 처리되기 때문에, 앞 요청이 느리면 뒤 요청도 막히는 HOL Blocking 문제가 발생
  • cf. 병렬 처리를 위해 파이프라이닝(Pipelining)을 지원하긴 했지만, 응답 순서 문제(HOL Blocking) 때문에 거의 쓰이지 않았고, 브라우저는 동시에 여러 리소스를 가져오려고 보통 6~8개의 병렬 TCP 연결을 열어 사용함

HOL Blocking이란?

앞에 있는 데이터가 막히면, 뒤에 오는 데이터도 같이 기다려야 하는 현상
= 네트워크 전송에서 앞부분 패킷의 지연/손실 때문에 뒤 데이터까지 지연되는 현상
= TCP 기반 프로토콜(순서를 보장하는 프로토콜)의 구조적 한계

TCP는 데이터를 순서대로 보내고, 순서대로 받아야 합니다. 만약 패킷 #2가 네트워크에서 유실되면, 수신 측은 #3, #4, #5가 이미 도착했어도 #2가 올 때까지 버퍼에 묵혀둡니다. 결과적으로 하나의 패킷 손실이 전체 데이터 흐름을 막아버리게 됩니다. TCP는 신뢰성과 순서를 위해 성능을 희생하는 구조입니다.

✅ HTTP/2 (Multiplexing)

웹 서비스가 커지고, 성능이 중요해지면서 한계를 해결하려고 나온 게 HTTP/2

• 멀티플렉싱 (Multiplexing)
  • 하나의 TCP 연결 위에서 여러 요청과 응답을 동시에 병렬 처리할 수 있도록 스트림(Stream) 단위로 데이터를 분할 전송
• → 한 연결에서 여러 요청을 동시에 보낼 수 있게 만든 것.
• 헤더 압축
  • HTTP/1.1에서는 요청마다 쿠키, User-Agent 등 동일한 헤더 정보를 반복적으로 전송했습니다.
  • HTTP/2는 중복되는 헤더를 테이블에 저장하고, 이후에는 짧은 인덱스만 참조하도록 해 네트워크 효율을 극대화했습니다.
• 서버 푸시 (Server Push)
  • 클라이언트가 HTML을 요청하면, 서버가 의존 리소스(CSS, JS 등)를 클라이언트 요청 전에 미리 전송할 수 있게 되어, 초기 로딩 속도를 줄이고 사용자 경험을 개선
• 한계: 여전히 TCP 기반이라서, 패킷 하나가 유실되면 그 뒤에 오는 것도 같이 막히는 HOL Blocking 문제

✅ HTTP/3 (UDP + QUIC)

TCP를 버리고 UDP 기반 QUIC으로 다시 만든 게 HTTP/3

• HOL Blocking 문제 해결
  • UDP의 특징인 “빠르지만 신뢰성이 없음” + QUIC이라는 프로토콜
    • QUIC 프로토콜 = 구글이 TCP가 하던 재전송, 순서 보장, 암호화 같은 기능을 UDP 위에서 직접 구현함
  • 패킷 하나 잃어버려도 나머지는 그냥 흘러가기 때문에 그래서 끊김이 훨씬 줄어듦.
• 0-RTT 연결 수립으로 지연 시간 단축
• Connection ID 기반 연결 관리
  • IP가 바뀌어도 세션이 끊기지 않음 → 연결이 자주 끊기는 모바일 환경 최적화
  • 유튜브, 넷플릭스 같은 스트리밍 서비스에서 사용

QUIC 프로토콜이란?

구글이 개발한 UDP 기반 전송 계층 프로토콜로, TCP가 가진 한계인 HOL Blocking 문제를 해결하기 위해 개발

 

도움이 되었다면, 공감/댓글을 달아주면 깃짱에게 큰 힘이 됩니다!🌟
비밀댓글과 메일을 통해 오는 개인적인 질문은 받지 않고 있습니다. 꼭 공개댓글로 남겨주세요!