8.3 Hypertext Transfer Protocol: HTTP/1.0, HTTP/1.1, HTTP/2 & QUIC

Back to Computer Networks Notes

📚Module 08: Application Layer ProtocolsTopic 8.3⏱️16 min read

🎯High-Yield For:Semester Exams (All Universities) • Placement Technical Rounds • Engineering Foundations

💡 Core Intuition: Ordering Food at a Restaurant

🍳 The Everyday Analogy: The Restaurant Service Model

Imagine dining at a busy restaurant with a table of 10 people:

1. The Telephoned Waiter (HTTP/1.0 Non-Persistent): To order water, you call the waiter from their home. They arrive, take your order, deliver the water glass, and immediately leave the restaurant and drive home. To order bread, you call them again. A complete car trip is required for every single item on the table.
2. The Table-Side Waiter (HTTP/1.1 Persistent): The waiter stays standing beside your table for your entire meal. You can order water, soup, and steak in sequence without sending them home. However, if the kitchen burns your soup, the waiter stands waiting at the kitchen door with your soup, while your cold drinks and bread sit trapped behind it (Head-of-Line Blocking).
3. The Multi-Compartment Conveyor Belt (HTTP/2 Multiplexing): Instead of a single waiter, the kitchen installs a mechanical conveyor belt. Dishes are sliced into small bite-sized colored containers. Soup bowls, water glasses, and steaks travel intermingled along the same belt simultaneously. However, if the conveyor belt gears jam for one container, the entire belt halts, stalling all food (TCP-Level Head-of-Line Blocking).
4. Independent Pneumatic Tubes (HTTP/3 over QUIC): The restaurant replaces the single conveyor belt with 10 separate pneumatic delivery tubes over a pneumatic manifold (UDP). If tube #1 clogs with soup, tubes #2 through #10 continue flying across the room delivering steaks and water at full speed without a millisecond of delay.

---

📑Table of Contents

• 🏛️ The Architectural Evolution of HTTP
• 📜 HTTP/1.0: Non-Persistent Connections & Connection Overhead
  • The Latency Disaster of Modern Web Pages
• ⚡ HTTP/1.1: Persistent Connections, Pipelining & Chunking
  • 1. Persistent Connections (Connection: keep-alive)
  • 2. The Application-Layer Head-of-Line (HoL) Blocking Flaw
  • 3. Chunked Transfer Encoding (Transfer-Encoding: chunked)
• 🚀 HTTP/2: Binary Framing Layer & True Multiplexing
  • 1. The Binary Framing Layer
  • 2. Stream Multiplexing & Prioritization
  • 3. HPACK Header Compression (RFC 7541)
• 🛑 The Fatal Bottleneck of HTTP/2: TCP Head-of-Line Blocking
• 🌐 HTTP/3 & QUIC: The UDP Revolution
  • Key Architectural Breakthroughs of QUIC & HTTP/3
• 📊 Comprehensive Protocol Feature Matrix
• 🏭 Real-World Production Context: YouTube QUIC Adoption, Cloud Microservices (gRPC) & Edge CDNs
  • 1. Google's YouTube QUIC Deployment & Cellular Latency
  • 2. High-Performance Backend Microservices (gRPC over HTTP/2)
  • 3. Modern Edge CDN Termination Architectures
• 📐 Numerical Applications & Worked Examples
  • Example 1: Web Page Loading Latency: HTTP/1.0 vs HTTP/1.1 vs HTTP/2
  • Example 2: Handshake Latency: HTTPS/TCP/TLS 1.2 vs HTTP/3 0-RTT QUIC
  • Example 3: Header Compression Savings with HPACK
• 🎯 Exam & Interview Pitfall Check

---

🏛️ The Architectural Evolution of HTTP

The Hypertext Transfer Protocol (HTTP) is the foundational application-layer protocol powering the World Wide Web.

The 4 Generations of Hypertext Transfer Protocol

How transport bottlenecks drove the architectural evolution from plaintext TCP up to UDP-based QUIC

📜

HTTP/1.0 (RFC 1945)

Non-Persistent TCP

• Opens a brand new TCP connection for every single embedded asset (image, CSS, JS).
• Suffers 2 x RTT connection setup penalty per object.
• Forces every asset through slow TCP Slow Start from cwnd = 1.
• Server closes TCP connection immediately after delivering response body.

⚡

HTTP/1.1 (RFC 2616)

Persistent & Keep-Alive

• Reuses a single TCP connection for multiple sequential requests (Connection: keep-alive).
• Introduced chunked transfer encoding and advanced cache headers (ETag).
• Supported pipelining, but rarely enabled due to proxy bugs.
• Critical Flaw: Application-Layer Head-of-Line (HoL) blocking on slow responses.

🚀

HTTP/2 (RFC 7540)

Binary Framing & Multiplexing

• Replaces ASCII text lines with a binary framing layer (HEADERS, DATA frames).
• Multiplexes dozens of concurrent streams over a single TCP connection.
• HPACK header compression compresses repetitive header strings.
• Critical Flaw: TCP-Level HoL blocking when packet drops stall all multiplexed streams.

🌐

HTTP/3 & QUIC (RFC 9114)

Native Multiplexing over UDP

• Discards TCP entirely in favor of QUIC running over UDP on Port 443.
• True stream isolation: dropped packet on Stream A does not stall Stream B.
• Zero round-trip resumption (0-RTT) and 1-RTT initial cryptographic handshakes.
• Connection Migration: uses 64-bit Connection IDs, surviving Wi-Fi to 5G handovers.

---

📜 HTTP/1.0: Non-Persistent Connections & Connection Overhead

In HTTP/1.0, every HTTP transaction operates over an ephemeral TCP connection:

1. Client initiates TCP 3-way handshake with the server ($1 \times RTT$).
2. Client transmits HTTP GET request.
3. Server transmits HTTP response and closes the TCP connection ($1 \times RTT$).

$\text{Total Latency per Object} = 2 \times RTT + \text{Transmission Time}$

The Latency Disaster of Modern Web Pages

A typical web page contains over 80 embedded resources (images, style sheets, scripts). Under HTTP/1.0:

• The client must perform 80 separate TCP handshakes ($80 \times 2 \times RTT$).
• Every connection starts at $\text{cwnd} = 1\text{ MSS}$, repeatedly paying the penalty of Slow Start without ever achieving full link bandwidth.
• Browsers attempted to mitigate this by opening up to 6 parallel TCP connections, which created aggressive router queue congestion and server socket exhaustion.

---

⚡ HTTP/1.1: Persistent Connections, Pipelining & Chunking

Published in 1999 (RFC 2616), HTTP/1.1 became the standard protocol of the modern web for over 15 years.

1. Persistent Connections (Connection: keep-alive)

HTTP/1.1 enables persistent connections by default. After the server delivers a response, the underlying TCP connection remains open. Subsequent requests for CSS, images, and JavaScript are dispatched over the pre-warmed TCP connection:

• Connection Setup Amortization: Only the initial HTML document pays the $2 \times RTT$ handshake penalty. All subsequent assets require only $1 \times RTT$ (request + response).
• TCP Congestion Window Preservation: The connection remains in Congestion Avoidance with a large $\text{cwnd}$, avoiding repeated Slow Start penalties.

2. The Application-Layer Head-of-Line (HoL) Blocking Flaw

Although HTTP/1.1 allowed requests to be pipelined (sending requests 2 and 3 before response 1 arrives), RFC 2616 strictly required that responses must be returned in the exact sequential order they were requested:

• If Request 1 is a heavy dynamic database query ($2,000\text{ ms}$) and Request 2 is a lightweight cached icon ($5\text{ ms}$), the icon response must sit buffered behind the slow database query.
• Because intermediate proxy caches frequently broke or mishandled pipelined requests, web browsers disabled HTTP pipelining by default, leaving HTTP/1.1 effectively serialized.

3. Chunked Transfer Encoding (Transfer-Encoding: chunked)

In HTTP/1.0, the server had to know the exact file size beforehand to set the Content-Length header. For dynamically generated web pages (e.g. search queries or server-rendered templates), the server had to buffer the entire HTML output in RAM before sending a single byte.

• HTTP/1.1 introduced chunking: the server streams arbitrary chunks prefixed by their hexadecimal length in bytes, terminating the stream with a chunk of size zero (0\r\n\r\n).

---

🚀 HTTP/2: Binary Framing Layer & True Multiplexing

In 2015, the IETF ratified HTTP/2 (RFC 7540), based on Google's SPDY protocol. HTTP/2 preserved HTTP semantic methods (GET, POST, 200 OK, headers), but completely revolutionized the wire format.

1. The Binary Framing Layer

HTTP/1.1 parsed newline-delimited ASCII text lines (\r\n), which was prone to parsing ambiguities and whitespace vulnerabilities (HTTP Request Smuggling). HTTP/2 replaces plain text with a rigid Binary Framing Layer:

Architecture Flow

The HTTP/2 Binary Framing Layer

How higher-layer HTTP requests and responses are decomposed into multiplexed binary frames

📝Application Layer

HTTP Semantics

Standard HTTP methods (GET, POST), status codes, and URI headers.

→

Binary Encoding

📦Framing Layer

Binary Frames

HEADERS frames carry metadata; DATA frames carry chunked payload bytes.

→

Assign Stream ID

🔀Multiplexing

Independent Streams

Interleaves frames from streams 1, 3, 5 concurrently over a single TCP socket.

→

Single TCP Pipe

⚡Transport

TCP Wire Delivery

Full wire utilization without opening redundant parallel sockets.

Core Frame Structure (9-Byte Header)

Every HTTP/2 frame begins with an invariant 9-byte header:

• Length (24 bits): Length of the frame payload (up to $16\text{ MB}$).
• Type (8 bits): Frame type (HEADERS, DATA, SETTINGS, RST_STREAM, PING, GOAWAY).
• Flags (8 bits): Frame-specific boolean flags (e.g. END_STREAM, END_HEADERS).
• Stream Identifier (31 bits): Uniquely identifies the stream to which this frame belongs (odd numbers for client-initiated, even for server-initiated).

2. Stream Multiplexing & Prioritization

Multiple requests and responses can be dispatched concurrently across a single TCP connection:

• A client can request an image (Stream 1) and a script (Stream 3) simultaneously.
• The server can interleave chunks: DATA (Stream 1) followed by DATA (Stream 3) followed by DATA (Stream 1).
• Eliminates the need for multiple parallel TCP connections and bypasses HTTP/1.1 application-layer HoL blocking entirely!

3. HPACK Header Compression (RFC 7541)

In modern web applications, every request sends dozens of repetitive headers (User-Agent, Cookie, Accept-Encoding, Authorization), wasting $1\text{ KB}$ to $2\text{ KB}$ per request.

• HPACK replaces ASCII text with indexed lookups:
  • Static Table: Predefined table of 61 common HTTP headers (e.g. index 2 represents method: GET).
  • Dynamic Table: Shared state updated dynamically during the session. If the client sends an identical cookie header twice, the second request sends only a 1-byte reference index!
  • Huffman Coding: Compresses header literals using a pre-calculated static Huffman tree.

---

🛑 The Fatal Bottleneck of HTTP/2: TCP Head-of-Line Blocking

Despite multiplexing multiple HTTP streams at the application layer, HTTP/2 still operates over a single underlying TCP connection.

Because TCP guarantees an in-order, contiguous byte stream:

1. Suppose Stream 1 carries an image and Stream 3 carries critical JavaScript.
2. An intermediate router drops one single TCP segment belonging to Stream 1.
3. The TCP receiver's socket buffer must wait for the missing segment to be retransmitted (via Fast Retransmit or RTO timeout).
4. All data belonging to Stream 3, even though successfully delivered by the network, is held hostage in the kernel TCP receive queue!

The TCP HoL Blocking Paradox

On lossy networks (e.g. mobile 4G/5G with $2\%$ packet loss), HTTP/2 frequently performs worse than HTTP/1.1 with 6 parallel connections! In HTTP/1.1, a dropped packet on connection 1 only stalls connection 1; the other 5 connections continue processing data. In HTTP/2, a single dropped packet freezes all 80 multiplexed streams simultaneously!

---

🌐 HTTP/3 & QUIC: The UDP Revolution

To eliminate transport-layer Head-of-Line blocking, the IETF developed QUIC (RFC 9000) and HTTP/3 (RFC 9114), moving transport stream management into user space over UDP.

HTTP/2 over TCP vs HTTP/3 over QUIC

Contrasting transport-level stream serialization against independent UDP streams

HTTP/2 Stack

HTTP/2 + TLS 1.2/1.3 + TCP

🛑

Dominant Architecture / DomainStandard Web over TCP Port 443

• •Connection setup: 1 RTT (TCP SYN) + 1-2 RTT (TLS Handshake) = 2 to 3 RTT total.
• •Single sequence space: TCP recognizes only bytes, not independent streams.
• •Packet loss on any stream halts all streams until segment is retransmitted.
• •Connection tied to 4-tuple (Src IP, Src Port, Dst IP, Dst Port); drops on network switch.

"Application multiplexing crippled by transport-level byte-stream ordering."

HTTP/3 Stack

HTTP/3 + QUIC over UDP

⚡

Dominant Architecture / DomainModern High-Performance Web over UDP Port 443

• •Combined transport + cryptographic handshake: 1 RTT for cold connect, 0-RTT for resumption.
• •Independent sequence spaces: loss on Stream 1 does NOT block Stream 3.
• •Integrated encryption: packet headers and payloads encrypted via TLS 1.3.
• •Connection Migration: uses 64-bit Connection ID; persists across Wi-Fi to cellular switches.

"True end-to-end stream isolation with instant cryptographic connection setup."

Key Architectural Breakthroughs of QUIC & HTTP/3

1. True Stream Independence (Zero Transport HoL Blocking)

QUIC understands streams natively at the transport layer. Each stream possesses its own independent flow control and sequence numbering. If a packet carrying data for Stream 1 is lost, QUIC delivers packets for Stream 2 and Stream 3 directly to the application layer immediately!

2. 0-RTT Connection Establishment

In classic HTTPS over TCP:

• TCP Handshake ($1 \times RTT$) $+$ TLS Handshake ($1 \times RTT$) $= 2 \times RTT$ before application data can flow.
• In QUIC, the transport and TLS 1.3 handshakes are unified into a single message exchange ($1 \times RTT$).
• If the client has previously communicated with the server, QUIC supports 0-RTT Resumption: the client encrypts and transmits HTTP requests in the very first UDP datagram!

3. Connection Migration via Connection ID

TCP connections are bound to the 4-tuple: (Source IP, Source Port, Destination IP, Destination Port). If a user walks out of their house and their phone switches from Wi-Fi to 5G cellular, their IP address changes, abruptly severing all active TCP connections.

• QUIC replaces the 4-tuple binding with an opaque 64-bit Connection ID (CID).
• When the client's IP changes, it simply dispatches the next UDP packet from the new IP using the same CID. The server seamlessly routes data without reconnecting or re-authenticating!

---

📊 Comprehensive Protocol Feature Matrix

Architectural Dimension	HTTP/1.0	HTTP/1.1	HTTP/2	HTTP/3
Transport Layer	TCP	TCP	TCP	QUIC (UDP)
Connection Persistence	Non-persistent (1 object / conn)	Persistent by default (Keep-Alive)	Persistent (Multiplexed)	Persistent (Multiplexed)
Wire Format	ASCII Text	ASCII Text	Binary Framing	Binary Framing (QPACK)
Multiplexing	❌ None	❌ None (Pipelining failed)	✅ Multiplexed over 1 TCP socket	✅ Natively Multiplexed over QUIC
Head-of-Line Blocking	❌ Severe (Per-connection)	❌ Application-Layer HoL	❌ Transport-Layer TCP HoL	✅ Eliminated entirely
Header Compression	❌ None	❌ None	✅ HPACK (Huffman + Tables)	✅ QPACK (Out-of-order safe)
Initial Handshake Latency	$2 \times RTT$	$2 \times RTT$ initial	$2 \times RTT$ initial	$1 \times RTT$ ($0 \times RTT$ resumption)
Connection Migration	❌ Reconnects	❌ Reconnects	❌ Reconnects	✅ Native Connection ID

---

🏭 Real-World Production Context: YouTube QUIC Adoption, Cloud Microservices (gRPC) & Edge CDNs

1. Google's YouTube QUIC Deployment & Cellular Latency

In 2014, Google pioneered QUIC across its consumer services:

• Over half of all Google search and YouTube video traffic was migrated to QUIC over UDP.
• On high-latency mobile networks and emerging markets with packet loss rates over $2\%$, YouTube reported a $3\%$ to $8\%$ reduction in video buffering time and a $15\%$ to $20\%$ drop in page load latency.
• When mobile users transitioned from home Wi-Fi to cellular data on the street, QUIC's Connection ID (CID) preserved active video playback buffers without interrupting playback or restarting TCP handshakes.

2. High-Performance Backend Microservices (gRPC over HTTP/2)

In cloud-native infrastructures (Kubernetes, Netflix, Uber):

• Inter-service microservice communication is dominated by gRPC (Google Remote Procedure Call).
• gRPC runs exclusively over HTTP/2. Rather than opening a new TCP socket or serializing human-readable JSON strings for every REST call, gRPC multiplexes hundreds of concurrent binary Protocol Buffer requests over a single long-lived TCP connection.
• This slashes connection handshake overhead, eliminates TCP slow-start penalties, and minimizes CPU memory footprint on container nodes.

3. Modern Edge CDN Termination Architectures

Global Content Delivery Networks (Cloudflare, Fastly, Akamai) deploy split-protocol architectures:

• Client-to-Edge: The browser communicates with the CDN edge Point of Presence (PoP) over HTTP/3 (QUIC) for lightning-fast 0-RTT connection setups on cellular devices.
• Edge-to-Origin: The CDN communicates with the backend cloud origin server over high-capacity private optical fibers using HTTP/2 or persistent HTTP/1.1 connection pools.

# Test HTTP/2 negotiation over TLS (ALPN: h2)
curl -I --http2 https://www.google.com

# Test HTTP/3 over QUIC (ALPN: h3)
curl -I --http3 https://cloudflare-quic.com

---

📐 Numerical Applications & Worked Examples

Example 1: Web Page Loading Latency: HTTP/1.0 vs HTTP/1.1 vs HTTP/2

Problem Statement: A web page consists of 1 base HTML file and 10 embedded image objects.

• Round-Trip Time between client and server: $\text{RTT} = 50\text{ ms}$.
• Base HTML transmission time: $T_{\text{HTML}} = 10\text{ ms}$.
• Each image transmission time: $T_{\text{img}} = 5\text{ ms}$.
• Neglect DNS lookup time and server processing delays. Calculate the total elapsed time to download the entire web page under:

1. HTTP/1.0 Non-Persistent: 1 TCP connection opened per object sequentially.
2. HTTP/1.1 Persistent without Pipelining: 1 TCP connection kept open; objects requested sequentially.
3. HTTP/2 Multiplexed: 1 TCP connection; all 10 image requests dispatched simultaneously.

Step-by-Step Solution:

1. HTTP/1.0 Non-Persistent Sequential:
   • For the HTML file: 1 RTT (TCP handshake) $+ 1\text{ RTT}$ (HTTP GET) $+ T_{\text{HTML}} = 2 \times 50 + 10 = 110\text{ ms}$.
   • For each of the 10 images: 1 RTT (TCP handshake) $+ 1\text{ RTT}$ (HTTP GET) $+ T_{\text{img}} = 2 \times 50 + 5 = 105\text{ ms}$.
   • Total Time: $T_{\text{HTTP/1.0}} = 110\text{ ms} + 10 \times 105\text{ ms} = 110 + 1050 = \mathbf{1,160\text{ ms}} \ (1.16\text{ seconds})$
2. HTTP/1.1 Persistent without Pipelining:
   • HTML file: 1 RTT (TCP handshake) $+ 1\text{ RTT}$ (HTTP GET) $+ T_{\text{HTML}} = 110\text{ ms}$.
   • For each of the 10 images: TCP connection is already open! Only $1\text{ RTT}$ (HTTP GET) $+ T_{\text{img}} = 50 + 5 = 55\text{ ms}$ each.
   • Total Time: $T_{\text{HTTP/1.1}} = 110\text{ ms} + 10 \times 55\text{ ms} = 110 + 550 = \mathbf{660\text{ ms}}$
3. HTTP/2 Multiplexed:
   • HTML file: $110\text{ ms}$.
   • All 10 image requests are issued in a single round-trip burst. They share the link concurrently: $T_{\text{images}} = 1\text{ RTT} + \sum_{i=1}^{10} T_{\text{img}} = 50\text{ ms} + (10 \times 5\text{ ms}) = 50 + 50 = 100\text{ ms}$
   • Total Time: $T_{\text{HTTP/2}} = 110\text{ ms} + 100\text{ ms} = \mathbf{210\text{ ms}}$
   • Conclusion: HTTP/2 delivers a $5.5\times$ speedup over HTTP/1.0 and a $3.1\times$ speedup over HTTP/1.1.

---

Example 2: Handshake Latency: HTTPS/TCP/TLS 1.2 vs HTTP/3 0-RTT QUIC

Problem Statement: A mobile smartphone with an RTT of $80\text{ ms}$ connects to an API server.

1. Calculate the initial connection setup latency for HTTPS over TCP with TLS 1.2 (separate TCP and TLS handshakes).
2. Calculate the setup latency for HTTPS over TCP with TLS 1.3.
3. Calculate the setup latency for HTTP/3 over QUIC (Cold Start) and for a QUIC 0-RTT Session Resumption.

Step-by-Step Solution:

1. TCP + TLS 1.2:
   • TCP 3-way handshake: $1 \times \text{RTT} = 80\text{ ms}$.
   • TLS 1.2 handshake (ClientHello $\to$ ServerHello/Cert $\to$ KeyExchange $\to$ Finished): $2 \times \text{RTT} = 160\text{ ms}$.
   • Total setup before sending HTTP request: $T_{\text{TLS1.2}} = 1\text{ RTT} + 2\text{ RTT} = 3 \times 80\text{ ms} = \mathbf{240\text{ ms}}$
2. TCP + TLS 1.3:
   • TCP 3-way handshake: $1 \times \text{RTT} = 80\text{ ms}$.
   • TLS 1.3 handshake: $1 \times \text{RTT} = 80\text{ ms}$.
   • Total setup: $T_{\text{TLS1.3}} = 1\text{ RTT} + 1\text{ RTT} = 2 \times 80\text{ ms} = \mathbf{160\text{ ms}}$
3. HTTP/3 over QUIC:
   • Cold Start (Initial Connect): QUIC combines transport and cryptographic parameter exchange in a single step: $T_{\text{QUIC\_cold}} = 1 \times \text{RTT} = \mathbf{80\text{ ms}}$
   • 0-RTT Resumption: Client encrypts application request with previously cached session tokens in the very first packet: $T_{\text{QUIC\_0RTT}} = \mathbf{0\text{ ms} \ (Immediate transmission)}$

---

Example 3: Header Compression Savings with HPACK

Problem Statement: An IoT telemetry device makes 1,000 HTTP requests per hour. Each HTTP request contains 12 headers averaging 600 bytes of repetitive text (e.g. User-Agent, Authorization, Host).

1. Calculate the total monthly bandwidth consumed purely by HTTP request headers using uncompressed HTTP/1.1.
2. Under HTTP/2 HPACK, the first request transmits the full 600 bytes to populate the dynamic table, but subsequent requests index the dynamic table, requiring only 25 bytes per request. Calculate the monthly bandwidth consumed and the percentage savings.

Step-by-Step Solution:

1. HTTP/1.1 Header Bandwidth: $\text{Requests per month} = 1,000 \times 24 \times 30 = 720,000\text{ requests}$ $\text{Data Consumed} = 720,000 \times 600\text{ bytes} = 432,000,000\text{ bytes} \approx \mathbf{432\text{ MB}}$
2. HTTP/2 HPACK Bandwidth:
   • First request: $600\text{ bytes}$.
   • Remaining 719,999 requests: $719,999 \times 25\text{ bytes} = 17,999,975\text{ bytes}$.
   • Total Data: $\text{Data Consumed} = 600 + 17,999,975 \approx 18,000,575\text{ bytes} \approx \mathbf{18.0\text{ MB}}$
3. Bandwidth Savings: $\text{Savings} = \frac{432\text{ MB} - 18\text{ MB}}{432\text{ MB}} \times 100\% = \frac{414}{432} \times 100\% \approx \mathbf{95.83\%}$ HPACK saves over $95\%$ of header traffic on high-frequency API endpoints!

---

🎯 Exam & Interview Pitfall Check

Question 1: Contrast the Head-of-Line (HoL) blocking problems experienced in HTTP/1.1 versus HTTP/2. How does HTTP/3 (QUIC) resolve both issues?

Answer:

• HTTP/1.1 Application-Layer HoL Blocking: RFC 2616 requires that pipelined HTTP responses be returned in the exact sequential order that requests were sent. If the first requested resource requires slow dynamic processing, all subsequent rapid or cached responses must sit blocked behind it at the application layer.
• HTTP/2 Transport-Layer HoL Blocking: HTTP/2 multiplexes multiple streams into binary frames over a single TCP connection. However, TCP is an in-order byte stream. If a single TCP segment containing a frame for Stream 1 is dropped on a congested link, the receiving OS kernel buffers all subsequent arriving TCP segments and refuses to pass them to user space until the missing segment is retransmitted. Thus, a drop on Stream 1 blocks Stream 2 and Stream 3 at the transport layer.
• HTTP/3 Solution: HTTP/3 replaces TCP with QUIC over UDP. QUIC assigns independent stream sequence spaces directly inside the transport layer. If a packet on Stream 1 is lost, the kernel and QUIC stack deliver data on Streams 2, 3, and 4 to the application layer immediately without delay, completely eliminating both application and transport HoL blocking.

---

Question 2: Explain the mechanics of HPACK header compression in HTTP/2. Why could standard gzip/deflate compression not be used directly on HTTP headers?

Answer:

• Mechanics of HPACK: HPACK compresses HTTP headers using two coordinated mechanisms:
  1. Static Table: A predefined table of 61 common headers (e.g. index 2 is method: GET, index 14 is status: 200).
  2. Dynamic Table: A connection-scoped table updated dynamically as headers are exchanged. Subsequent requests referencing previously seen header keys or values transmit only the integer table index.
  3. Static Huffman Coding: Literal values are encoded using an optimized static Huffman code.
• Why Gzip/Deflate Was Rejected (CRIME Attack): In 2012, researchers demonstrated the CRIME (Compression Ratio Info-leak Made Easy) attack. When an attacker injects chosen plaintext into an HTTP request that shares a gzip/deflate stream with a secret authentication cookie, the attacker can deduce the cookie byte-by-byte by observing the exact byte length of the compressed output (LZ77 deduplication shrinks output when guesses match). HPACK was engineered specifically to defend against compression ratio side-channel attacks by separating header names from values and restricting cross-stream dictionary sharing.

---

Core Conceptual Questions

• What is ALPN (Application-Layer Protocol Negotiation)?: In modern TLS handshakes, ALPN (RFC 7301) allows the client to send a list of supported application protocols (e.g. ["h2", "http/1.1"]) in the ClientHello message. The server selects its preferred protocol and returns it in ServerHello, allowing the client and server to negotiate HTTP/2 or HTTP/3 without paying an extra round-trip time.
• Why did HTTP/2 introduce Server Push, and why is it rarely used today?: Server Push allowed a server responding to index.html to preemptively push style.css before the client parsed the HTML. However, it was largely abandoned because servers frequently pushed assets that the browser already had cached, wasting mobile bandwidth. Modern web architectures prefer the 103 Early Hints status code instead.

Common Interview Traps

• Trap: Believing QUIC is Unreliable Because It Uses UDP: While UDP itself provides zero reliability, QUIC implements its own connection-oriented reliability, packet numbering, selective acknowledgments, and congestion control (CUBIC/BBR) directly in user space on top of UDP.
• Trap: Assuming HTTP/2 Encrypts Headers with TLS Automatically: The HTTP/2 standard (RFC 7540) technically permits unencrypted cleartext HTTP/2 (h2c). However, in practice, all major browser vendors (Chrome, Firefox, Safari) strictly implement HTTP/2 exclusively over TLS (h2), making encryption mandatory in production.

---

🗺️View Complete Computer Networks Roadmap & Syllabus

← Previous Topic8.2 Domain Name System (DNS): Hierarchical Namespaces & ResolutionNext Topic →8.4 Electronic Mail Protocols: SMTP, POP3 & IMAP4 Architecture