HTTP Evolution (H1 to H3)

The Need for Speed

The web has changed. We went from simple HTML pages to complex applications with hundreds of assets (JS, CSS, Images).

HTTP/1.1 (1997)

Protocol: Text-based (ASCII). Transport: TCP.

The Problem: Head-of-Line Blocking (HOL)

HTTP/1.1 processes requests sequentially on a connection.

1. Browser asks for style.css.
2. Browser asks for script.js.
3. If style.css takes 5 seconds, script.js waits (blocked).

Workaround: Browsers commonly open several parallel connections per origin; the exact limit depends on the browser.

HTTP/2 (2015)

Protocol: Binary. Transport: TCP.

The Solution: Multiplexing

HTTP/2 allows multiple streams over a single TCP connection.

• Requests are broken into binary frames.
• Frames are interleaved.
• script.js frames can arrive before style.css frames if they are ready first.

Other Features

• Header Compression (HPACK): Don't send User-Agent: Chrome repeatedly.
• Server Push: Server sends style.css before browser asks (Deprecated in Chrome 2022 due to complexity).

The New Problem: TCP HOL Blocking

HTTP/2 fixed Application HOL blocking but still inherits TCP’s transport HOL blocking. If one packet is lost in TCP, the OS holds back all streams until that packet is retransmitted. One dropped packet slows down everything.

HTTP/3 (2022)

Protocol: Binary (QUIC). Transport: UDP (User Datagram Protocol).

The Solution: QUIC

Builds reliable transport on top of UDP in user-space.

• Independent Streams: Missing data blocks delivery within the affected stream; other streams can progress. Shared congestion control and application dependencies can still delay them.
• Connection setup: Typically a one-RTT cryptographic handshake; eligible resumed connections may send replayable 0-RTT early data.
• Connection Migration: Switch from Wi-Fi to 5G without reconnecting (Connection ID persists).

Performance Comparison

Code Example: Go Server (Generic)

This HTTP/2 example requires the golang.org/x/net/http2 module, valid certificate files and permission to bind port 443. It does not implement HTTP/3.

package main

import (
	"fmt"
	"net/http"
	"golang.org/x/net/http2"
)

func handler(w http.ResponseWriter, r *http.Request) {
	fmt.Fprintf(w, "Protocol: %s", r.Proto)
}

func main() {
    server := &http.Server{Addr: ":443"}
    
    // Enable HTTP/2 automatically if using TLS
    if err := http2.ConfigureServer(server, &http2.Server{}); err != nil {
        panic(err)
    }
    
    http.HandleFunc("/", handler)
    
    // Serve HTTPS (Required for H2/H3 in browsers)
    if err := server.ListenAndServeTLS("cert.pem", "key.pem"); err != nil {
        panic(err)
    }
}

Interview Tips 💡

• "Why UDP?" — TCP is too hard to change (ossified in middleboxes). UDP is just a raw socket. We implemented TCP features (reliability, congestion control) on top of UDP in user-space (QUIC).
• "What is HOL blocking?" — Explain both App-layer (H1) and Transport-layer (H2/TCP) variations.
• "0-RTT" — If client has talked to server before, it can send data in the first packet. Risk: Replay Attacks.
• "Server Push" — Mention it failed in practice because server doesn't know browser cache state. 103 Early Hints is the modern replacement.

Worked decision: a lossy mobile link

Test the same page over HTTP/2 and HTTP/3 with controlled RTT, packet loss and a warm connection. Keep the server, content encoding and cache state fixed. Compare page milestones and tail latency, not just a single resource’s transfer time. HTTP/3 may help independent streams progress through loss, but a slow database response remains slow on either transport. Preserve an HTTP/2 fallback for networks that block UDP.

The stream and congestion distinctions come from HTTP/3, RFC 9114 and QUIC, RFC 9000.

Related Concepts

• TCP Handshake
• TLS 1.3 specification
• Load Balancing (L7 vs L4)