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 open 6 TCP connections per domain. (Still limited).

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.

sequenceDiagram
    participant C as Client
    participant S as Server
    
    C->>S: Stream 1: GET /style.css
    C->>S: Stream 2: GET /script.js
    
    S->>C: Stream 2 Data (script.js chunk 1)
    S->>C: Stream 1 Data (style.css chunk 1)
    S->>C: Stream 2 Data (script.js chunk 2 - Done)

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 introduced 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: Packet loss in Stream 1 does not affect Stream 2.
• 0-RTT Handshake: Faster connection setup (TLS 1.3 built-in).
• Connection Migration: Switch from Wi-Fi to 5G without reconnecting (Connection ID persists).

graph TD
    subgraph HTTP_Stack_Comparison
        direction LR
        
        subgraph H1 [HTTP/1.1]
            L1_H1[HTTP/1.1] --> L1_TLS[TLS]
            L1_TLS --> L1_TCP[TCP]
            L1_TCP --> L1_IP[IP]
        end
        
        subgraph H2 [HTTP/2]
            L2_H2[HTTP/2] --> L2_TLS[TLS]
            L2_TLS --> L2_TCP[TCP]
            L2_TCP --> L2_IP[IP]
        end
        
        subgraph H3 [HTTP/3]
            L3_H3[HTTP/3] --> L3_QUIC[QUIC (Reliability+TLS)]
            L3_QUIC --> L3_UDP[UDP]
            L3_UDP --> L3_IP[IP]
        end
    end

Performance Comparison

Code Example: Go Server (Generic)

Implementing versions is often transparent to app logic.

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
    http2.ConfigureServer(server, &http2.Server{})
    
    http.HandleFunc("/", handler)
    
    // Serve HTTPS (Required for H2/H3 in browsers)
    server.ListenAndServeTLS("cert.pem", "key.pem")
}

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.

Related Concepts

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