HTTP & Protocol Evolution

1. Overview

HTTP와 프로토콜 진화(HTTP & Protocol Evolution)는 단순한 텍스트 문서를 교환하던 웹의 요람에서 시작해, 현대의 초고속, 양방향, 다중화 스트리밍을 감당하는 인터넷 최상위(L7) 대동맥의 발전사를 해부합니다.

학습자는 상태가 없고(Stateless) 매번 무거운 연결을 맺어야 했던 HTTP/1.0의 비효율을 깨닫고, 연결을 재사용하는 **HTTP/1.1 (Keep-Alive)**의 타협점을 뜯어봅니다. 나아가 수십 개의 이미지와 JS 파일을 하나의 TCP 파이프에서 동시에 쏘아 보내 병목(HoL Blocking)을 해결한 **HTTP/2 (Multiplexing)**의 이진 프레이밍 마법을 장악합니다. 마지막으로, TCP 자체의 족쇄마저 벗어던지고 UDP 기반의 QUIC 프로토콜 위에서 0-RTT 연결과 미친 속도를 구현해 낸 HTTP/3의 혁명적 아키텍처 역량을 확보합니다.

2. Scope & Boundaries

In-Scope

• HTTP/1.1: Keep-Alive, Pipelining (실패한 기능), Text-based Header, Head-of-Line (HoL) Blocking (HTTP 레벨).
• HTTP/2: Binary Framing, Multiplexing, Server Push, Header Compression (HPACK).
• HTTP/3 (QUIC): UDP 기반 전송, TCP HoL Blocking 해결, 0-RTT Handshake, Connection Migration (IP 변경 시 연결 유지).
• HTTPS & TLS: SSL/TLS 핸드셰이크에 의한 지연(Latency)과 HTTP 진화의 연관성.

Out-of-Scope

• RESTful API 설계론: URI 네이밍 규칙, HTTP Method(GET/POST)의 의미론적 설계 $\rightarrow$ 08-04-02 RESTful Architecture 영역으로 위임.
• TCP/UDP 전송 계층 심층 원리: 3-Way Handshake, TCP Congestion Control의 물리적 슬라이딩 윈도우 $\rightarrow$ 08-02 TCP, UDP & Transport 영역에서 기학습.

Boundaries

• HTTP/1.1 HoL vs TCP HoL: HTTP/1.1에서 이미지 1개를 받을 때까지 다음 이미지 요청을 못 하는 현상은 'HTTP(L7) 레벨의 HoL Blocking'입니다 (HTTP/2 멀티플렉싱으로 해결). 하지만 HTTP/2를 써도 패킷 1개가 유실되면 TCP 특성상 나머지 멀티플렉싱 된 데이터 전체가 렌더링을 멈추는 현상은 'TCP(L4) 레벨의 HoL Blocking'입니다. HTTP 진화사는 이 두 개의 서로 다른 병목(L7 $\rightarrow$ L4)을 차례대로 박살 내는 과정(HTTP/2 $\rightarrow$ HTTP/3)임을 명확히 경계 짓습니다.

3. Counterexample

• HTTP/1.1 도메인 샤딩(Domain Sharding)의 몰락: 과거 프론트엔드 개발자들이 브라우저의 HTTP/1.1 동시 연결 제한(보통 도메인당 6개)을 우회하려고, 이미지를 img1.site.com, img2.site.com 등으로 수십 개 쪼개서 로딩했습니다. HTTP/2가 도입되면서 이 짓을 계속하자, 도리어 수십 개의 무거운 TCP+TLS 핸드셰이크가 병렬로 터지면서 웹사이트 로딩 속도가 나락으로 떨어졌습니다. 프로토콜이 진화(단일 TCP 멀티플렉싱)했음에도 과거의 안티 패턴(연결 쪼개기)을 고집한 성능 재앙입니다.
• TCP 위에서의 강박적 성능 최적화: 모바일 환경에서 유저가 Wi-Fi에서 LTE로 망을 전환합니다. IP가 바뀌었기 때문에 기존 TCP 세션이 끊어지고 3-Way Handshake와 TLS 협상을 처음부터 다시 해야 합니다. 개발자가 앱 단에서 이를 매끄럽게 무마하려 수천 줄의 재접속 로직을 짰으나 잦은 버그가 났습니다. HTTP/3(QUIC)의 Connection Migration(IP가 바뀌어도 Connection ID로 세션 유지)을 몰라 앱 레이어에서 바퀴를 재발명하려 했던 헛된 노력입니다.

4. Prerequisites

• L4 Transport Layer (Basic): TCP 3-Way Handshake와 TCP HoL Blocking 현상. (08-02-01, 08-02-02)
• L7 Application Layer (Basic): HTTP Request/Response 구조와 Stateless 특성. (08-01-04 OSI Stack)

5. Learning Map

6. Learning Topics

Basic

Core Topic 01: 터널의 재사용, HTTP/1.1 (Keep-Alive)

• Why to Learn: 현대 웹페이지 하나를 띄우는 데 수십 개의 파일(HTML, JS, CSS)이 필요한 상황에서, 매번 TCP 연결을 맺고 끊는 RTT(Round Trip Time) 오버헤드를 어떻게 줄였는지 통찰하기 위함입니다.
• What to Learn:
  • Concepts: HTTP/1.0 (Short-lived connections), HTTP/1.1, Persistent Connection (Keep-Alive), RTT, TCP 3-Way Handshake Overhead.
  • Skills: 크롬 개발자 도구(Network 탭)의 Waterfall 차트를 분석하여, TCP 핸드셰이크(Initial Connection)가 1번만 일어나고 후속 요청들이 해당 연결을 재사용하는 타임라인 시각화.
• How to Learn:
  • 1단계: HTTP/1.0의 비효율: 그림 10장이 있는 웹페이지를 엽니다. 1.0 시절엔 그림 1장을 받을 때마다 TCP 연결(3-Way) -> HTTP 요청 -> 응답 -> TCP 종료(4-Way)를 10번 반복했습니다. 배보다 배꼽(제어 오버헤드)이 더 큰 대참사입니다.
  • 2단계: HTTP/1.1 Keep-Alive: "야, 한 번 연결했으면 당분간 끊지 말고 계속 쓰자!" 이게 Keep-Alive입니다. TCP 터널을 1번만 뚫고, 그림 10장을 그 안으로 차례대로 요청하고 받습니다(순차적 처리). 하지만 앞의 그림(용량 100MB)을 다 받을 때까지 뒤의 그림(10KB)들이 줄을 서서 무작정 기다려야 하는 HTTP 레벨의 HoL Blocking 딜레마를 뜯어봅니다.
• Implement: 파이썬 소켓 Keep-Alive 벤치마크. 10개의 1MB 파일을 요청함. Non_KeepAlive_Mode: 10번의 TCP Handshake 비용 포함 $\rightarrow$ 총 소요 시간 3.5초. KeepAlive_Mode: 1번의 TCP Handshake 후 터널 재사용 $\rightarrow$ 총 소요 시간 1.2초. 프로토콜 진화에 따른 RTT 오버헤드 감소량(약 3배 성능 향상) 콘솔 렌더링.

Recommended

Core Topic 02: 텍스트를 쪼개라, HTTP/2 (Multiplexing)

• Why to Learn: 무거운 파일을 다운받을 때 뒤의 작은 파일들이 갇혀버리는 HTTP/1.1의 직렬 병목(HoL)을 깨부수고, 진정한 의미의 '병렬(Parallel) 다운로드'를 단 1개의 TCP 연결로 이룩한 혁명을 장악하기 위함입니다.
• What to Learn:
  • Concepts: Binary Framing Layer, Multiplexing (멀티플렉싱), Stream ID, HPACK (헤더 압축), Server Push.
  • Skills: 여러 개의 HTTP 요청이 각각의 Stream ID로 잘게 쪼개져 순서에 상관없이 섞여서 전송(Interleaving)된 후, 브라우저가 이를 재조립하는 과정 도해.
• How to Learn:
  • 1단계: 이진 프레이밍 (Binary Framing): 1.1까지는 사람이 읽을 수 있는 텍스트(GET / HTTP/1.1)를 통째로 보냈습니다. 2.0부터는 텍스트를 기계 친화적인 이진 데이터(Binary Frame)로 박살 냅니다. 데이터 프레임마다 "난 1번 이미지 조각이야(Stream 1)", "난 2번 JS 조각이야(Stream 2)"라는 꼬리표를 붙입니다.
  • 2단계: 멀티플렉싱 (Multiplexing): 1.1에서는 100MB 이미지와 10KB 텍스트를 동시에 요청할 수 없었습니다(직렬). 2.0에서는 두 파일을 잘게 다진 프레임 조각들을 단 1개의 TCP 파이프에 무작위로 섞어서 한꺼번에 쏴버립니다. 100MB 이미지가 전송되는 와중에도 10KB 텍스트 조각이 틈새로 끼어 들어와 0.1초 만에 화면에 렌더링되는 동시성의 마법을 해부합니다.
• Implement: Multiplexing 프레임 렌더링(텍스트 애니메이션). 스트림 1(거대 이미지): [I1][I2][I3][I4][I5]... 스트림 2(작은 CSS): [C1][C2] 네트워크 파이프 전송: HTTP/1.1 [I1,I2,I3,I4,I5(5초 소요)] -> 그제야 [C1,C2(0.1초)] 렌더링. HTTP/2 [I1][C1][I2][C2][I3]... 섞여서 전송 $\rightarrow$ 0.2초 만에 CSS 렌더링 완료, 화면이 먼저 뜨고 이미지는 뒤이어 로딩되는 비동기적 유저 경험(UX) 개선 시각화.

Practical

Core Topic 03: 패러다임 전환, TCP를 버려라 (TCP HoL Blocking)

• Why to Learn: HTTP/2가 완벽해 보였지만, L7이 아닌 L4(TCP) 계층에서 패킷 하나가 유실되었을 때 1개의 파이프에 욱여넣은 모든 멀티플렉싱 데이터가 올스톱되는 최악의 나비효과를 통찰하기 위함입니다.
• What to Learn:
  • Concepts: TCP Head-of-Line Blocking, TCP Congestion/Error Control, L7 vs L4 Blocking.
  • Skills: 패킷 드롭이 잦은 모바일 무선망(Lossy Network) 환경에서 HTTP/1.1(다중 연결)보다 HTTP/2(단일 연결)가 오히려 성능이 더 떨어지는 역설적 상황 분석.
• How to Learn:
  • 1단계: 단일 TCP의 맹점: HTTP/2는 멀티플렉싱을 위해 단 1개의 TCP 연결만 씁니다. TCP는 "순서대로 완벽하게 전달한다"는 철학이 있습니다. 만약 프레임 조각 [I1][C1][I2][C2] 중 [C1]이 공중에서 유실(Loss)되었습니다.
  • 2단계: TCP HoL Blocking 발동: OS의 TCP 스택은 [C1]이 재전송되어 도착할 때까지 그 뒤에 무사히 도착한 [I2], [C2]마저 브라우저에 넘겨주지 않고 버퍼에 가둬버립니다(HoL Blocking). 이미지 I와 CSS C는 서로 완전 남남(독립된 스트림)인데도, TCP 눈에는 그저 '순서대로 온 바이트 덩어리'일 뿐이라서 하나만 깨져도 전체 웹 로딩이 완전히 멈춰버리는 끔찍한 병목을 뜯어봅니다.
• Implement: 패킷 로스 환경에서의 프로토콜 비교 차트 분석. 네트워크 패킷 로스 2% 환경 가설. HTTP/1.1: 연결이 6개. 1번 연결에서 패킷이 드롭되어도 나머지 5개 연결(다른 이미지/CSS)은 정상 렌더링. HTTP/2: 연결이 1개. 그 1개 파이프에서 패킷 하나 드롭되자 수십 개의 파일 로딩이 한꺼번에 1초 정지(프리징). 기술의 진화가 무선 환경에서 맞닥뜨린 치명적 구조적 결함 도출.

Advanced

Core Topic 04: UDP 기반의 광속 질주, HTTP/3와 QUIC (HTTP/3 & QUIC)

• Why to Learn: 구글이 작정하고 TCP를 쓰레기통에 처박은 뒤, 신뢰성이 없던 UDP 위에 독자적인 제어 로직(QUIC)을 쌓아 올려 모바일 시대의 궁극적 무지연(0-RTT) 웹 프로토콜을 창조한 과정을 장악하기 위함입니다.
• What to Learn:
  • Concepts: HTTP/3, QUIC (Quick UDP Internet Connections), UDP over L4, 0-RTT Handshake, Connection Migration, TLS 1.3 내장.
  • Skills: QUIC 스트림 개념을 통해, 패킷 유실 시 '해당 스트림'만 멈추고 다른 스트림은 정상 처리되도록 L4(UDP) 위에 새롭게 구축한 수신 버퍼 통제 모델 이해.
• How to Learn:
  • 1단계: QUIC의 등장 (UDP 기반): TCP는 OS(커널)에 박혀있어 수정이 불가능합니다. 구글은 빈 껍데기인 UDP를 골라잡아 그 위에 '사용자 레벨(User-Space)'에서 신뢰성과 암호화를 다 우겨넣은 QUIC 프로토콜을 만들었습니다. QUIC은 각 스트림(이미지, CSS)을 독립적으로 인지합니다. [C1]이 유실되어도 [I2]는 버퍼에 가두지 않고 브라우저에 바로 넘겨버립니다 (TCP HoL 완전 해결).
  • 2단계: 0-RTT와 커넥션 마이그레이션: TCP+TLS는 인사(Handshake)하는 데만 3번 왔다 갔다(3-RTT) 합니다. QUIC은 예전에 접속했던 사이트면 인사 없이 첫 패킷부터 바로 데이터를 꽂아버립니다(0-RTT). 더 소름 돋는 건, 내가 Wi-Fi에서 LTE로 넘어가 IP 주소가 확 바뀌어도 QUIC 내부의 'Connection ID'는 그대로라서, 스트리밍 영상이 0.1초도 안 끊기고 계속 재생되는 기적의 모바일 최적화를 해부합니다.
• Implement: QUIC Connection Migration 렌더링. Client IP: 192.168.0.10 (Wi-Fi) -> Server. CID: 0xABCD. 다운로드 진행 중 50%. 유저가 엘리베이터 탐. Wi-Fi 끊기고 Client IP: 211.200.1.5 (LTE)로 변경됨. TCP였다면 [RST] Connection Reset -> 재접속 0%부터 다시. QUIC은 바뀐 IP 패킷에 CID: 0xABCD를 달아 보냄. 서버가 "어? IP는 달라도 내 친구 맞네" 하고 핸드셰이크 없이 다운로드 51%부터 즉각 재개하는 무정지 로직 시각화.

7. Terminology

8. References

Primary

• [P1] CS2023 - Networking and Communication (NC) - Application Layer Protocols (HTTP Evolution)
• [P5] SFIA - Network Design (NTDS) - Web Protocol Optimization

Secondary

• [Computer Networking: A Top-Down Approach] Kurose & Ross - The Web and HTTP (HTTP/2 and HTTP/3)
• [High Performance Browser Networking] Ilya Grigorik - HTTP/2, QUIC

Industry

• [Cloudflare Learning Center] - What is HTTP/2? / What is HTTP/3?
• [IETF RFC 7540] - Hypertext Transfer Protocol Version 2 (HTTP/2)
• [IETF RFC 9114] - HTTP/3

9. Final Checklist

Primary

• 텍스트 문서를 불러오기 위해 매번 TCP 3-Way Handshake를 수행했던 HTTP/1.0의 지연(Latency) 문제를, Connection: keep-alive 헤더를 통해 파이프라인을 재사용하는 HTTP/1.1의 설계로 어떻게 극복했는지 설명할 수 있는가?
• HTTP/1.1 환경에서 브라우저가 동시 연결 개수 제한(보통 6개)을 우회하기 위해 도메인을 여러 개로 쪼갰던 도메인 샤딩(Domain Sharding) 안티 패턴을 식별할 수 있는가?

Secondary

• HTTP/2가 텍스트 기반 포맷을 버리고 Binary Framing 계층을 도입하여, 여러 스트림(Stream ID)의 조각들을 1개의 TCP 연결 위에서 교차 전송(Multiplexing)하는 병렬 처리 아키텍처를 해부할 수 있는가?
• HTTP/2가 L7 레벨의 Head-of-Line Blocking은 해결했으나, 패킷 유실이 발생할 경우 OS 커널의 TCP 수신 버퍼가 전체 멀티플렉싱 데이터의 처리를 멈춰버리는 L4 레벨의 TCP HoL Blocking 딜레마를 증명할 수 있는가?

Industry

• HTTP/3(QUIC)가 TCP 대신 UDP를 채택하여 각 스트림을 독립적으로 관리함으로써, 1번 스트림 패킷이 유실되어도 2번 스트림 렌더링에 영향을 주지 않는 궁극적 HoL Blocking 해결책을 논증할 수 있는가?
• 모바일 기기(Wi-Fi $\rightarrow$ LTE) 이동으로 클라이언트 IP가 변경되더라도, QUIC 내부의 고유한 Connection ID를 통해 TCP 재연결(TLS 핸드셰이크 포함) 없이 스트리밍을 무정지로 유지하는 Connection Migration 메커니즘을 설계할 수 있는가?