HTTP/1.1, HTTP/2, HTTP/3 차이점은?
한 줄 답변
HTTP/1.1은 텍스트 기반으로 HOL Blocking 문제가 있었고, HTTP/2는 멀티플렉싱을 통해 이를 개선했으며, HTTP/3는 UDP 기반의 QUIC을 도입해 TCP의 태생적 한계를 극복했습니다.
핵심 개념 정리
HTTP/1.1은 1997년에 표준화된 이후 오랫동안 웹의 기본 프로토콜로 자리 잡았습니다. 이 버전의 핵심은 Keep-Alive를 통한 연결 유지와 파이프라이닝이었으나, 앞선 요청이 지연되면 뒤의 요청도 대기해야 하는 'Head-of-Line(HOL) Blocking' 현상이 고질적인 성능 저하의 원인이었습니다. 이로 인해 브라우저들은 한 도메인당 6개 정도의 커넥션 제한을 두는 등의 고육지책을 사용해야 했습니다.
이를 해결하기 위해 2015년에 등장한 HTTP/2는 텍스트 대신 바이너리 프레임 계층을 도입했습니다. 하나의 TCP 연결 내에서 여러 스트림을 동시에 주고받는 '멀티플렉싱(Multiplexing)' 기능을 통해 애플리케이션 레벨의 HOL Blocking을 획기적으로 줄였습니다. 또한 헤더 압축(HPACK)과 서버가 클라이언트 요청 전에 자원을 보내는 서버 푸시 기능을 지원하여 효율성을 극대화했습니다.
하지만 HTTP/2 역시 TCP 프로토콜을 기반으로 하기에, 네트워크 패킷 손실이 발생하면 전체 TCP 윈도우가 멈추는 'TCP 수준의 HOL Blocking' 문제가 여전히 존재했습니다. 이에 구글이 주도하여 개발한 HTTP/3는 신뢰성보다 속도와 유연성이 강점인 UDP 기반의 QUIC 프로토콜을 채택했습니다. QUIC은 연결 설정 시간을 단축하고 패킷 손실 시 해당 스트림만 영향받도록 설계되어 현대적인 불안정한 모바일 네트워크 환경에서도 강력한 성능을 발휘합니다.
비교 정리
| 항목 | HTTP/2 (TCP) | HTTP/3 (UDP/QUIC) |
|---|---|---|
| 전송 프로토콜 | TCP (신뢰성 위주) | UDP/QUIC (성능 및 유연성) |
| 연결 설정 지연 | TCP+TLS (2-3 RTT 발생) | QUIC (0-1 RTT로 즉시 통신) |
| 패킷 손실 영향 | 전체 스트림이 일시 중단됨 | 손실된 스트림만 영향받고 나머지는 진행 |
| 보안 방식 | TLS 별도 레이어 구성 필요 | 프로토콜 자체에 TLS 1.3 기본 내장 |
면접에서 이렇게 답하세요
단순히 버전을 나열하기보다 기술적 병목이 어떻게 이동했는지 서술하는 것이 좋습니다. 'HTTP/1.1의 앱 레벨 HOL -> HTTP/2의 TCP 레벨 HOL -> HTTP/3의 QUIC 해결' 구조로 답변하세요. 또한 HTTP/3가 왜 UDP를 선택했는지에 대한 논리적 근거(TCP 지연 한계 및 OS 커널 수정의 어려움)를 명확히 제시하면 깊이 있는 답변으로 평가받을 수 있습니다.
자주 묻는 추가 질문
Q. QUIC이 UDP 위에서 신뢰성을 보장하는 방식은?
TCP의 재전송, 혼잡 제어 기능을 애플리케이션 수준에서 직접 구현하여 손실된 데이터의 복구를 보장합니다.
Q. HTTP/3의 0-RTT 연결이란 무엇인가요?
이전 연결 정보를 재사용하여 첫 번째 패킷부터 데이터를 실어 보내는 방식으로 핸드쉐이크 지연을 제거하는 기술입니다.
Q. 모든 웹사이트가 HTTP/3로 전환해야 할까요?
전환 비용과 방화벽의 UDP 차단 이슈 등을 고려해야 하며, 실시간성이 중요한 고용량 서비스에 우선 권장됩니다.
커뮤니티 하이라이트
“실무에서는 아직 HTTP/2가 대세지만, 고도화된 글로벌 서비스는 HTTP/3 도입으로 초기 로딩 속도를 20% 이상 개선하기도 합니다.”
“네트워크 장비에서 UDP를 차단하는 경우가 있어 HTTP/3는 항상 HTTP/2로의 폴백 전략을 함께 고민해야 하는 주제입니다.”
42명의 개발자가 이 질문에 참여했습니다
관련 면접 질문
앱에서 직접 답변해보세요
매일 3개의 면접 질문에 답변하고,
다른 개발자들의 답변을 비교해보세요.