HTTP/1.1 vs HTTP/2 vs HTTP/3

// HTTP/1.1 — one outstanding request per connection
// Connection: keep-alive reuses TCP connection but requests are serial:
//
// Connection 1: GET /index.html → wait → response
//               GET /style.css  → wait → response    (serial, HOL blocking)
//
// Browser workaround: open 6 connections per origin
// 6 connections × TLS handshake overhead = 6 × ~2 RTT = expensive

// HTTP/1.1 request format:
// GET /api/users HTTP/1.1
// Host: api.example.com
// Accept: application/json
// Connection: keep-alive
//
// Headers are plain text — verbose, repetitive across requests
// No header compression → ~500B overhead per request minimum

// Java HttpURLConnection (HTTP/1.1):
URL url = new URL("https://api.example.com/users");
HttpURLConnection conn = (HttpURLConnection) url.openConnection();
conn.setRequestMethod("GET");
conn.setRequestProperty("Accept", "application/json");
int status = conn.getResponseCode();   // blocks until response arrives

// HTTP/2 key features:
// 1. Binary framing — requests/responses are split into frames
// 2. Multiplexing — many streams over ONE TCP connection
// 3. HPACK header compression — headers sent once, referenced later
// 4. Stream prioritisation — client hints which responses matter most
// 5. Server push — server sends /style.css before client asks

// Multiplexing visualised:
// Single TCP connection:
// ├── Stream 1: GET /api/users     (concurrent)
// ├── Stream 2: GET /api/products  (concurrent)
// └── Stream 3: GET /api/orders    (concurrent)
// All three in-flight simultaneously — no 6-connection workaround needed

// Java HttpClient (HTTP/2 by default in Java 11+):
HttpClient client = HttpClient.newBuilder()
    .version(HttpClient.Version.HTTP_2)
    .build();

HttpResponse<String> response = client.send(
    HttpRequest.newBuilder(URI.create("https://api.example.com/users"))
               .header("Accept", "application/json")
               .build(),
    HttpResponse.BodyHandlers.ofString()
);
System.out.println("Protocol: " + response.version()); // HTTP_2

// gRPC requires HTTP/2 — uses multiplexed streams for bidirectional streaming

// HTTP/3 = HTTP/2 semantics over QUIC (UDP)
//
// TCP head-of-line blocking problem:
// Stream 1 packet lost → TCP retransmits → ALL streams stall waiting
//
// QUIC solution:
// Each stream is independently reliable
// Stream 1 packet lost → only stream 1 retransmits → streams 2, 3 continue
//
// Connection establishment comparison:
// HTTP/1.1 + TLS 1.2:  TCP(1 RTT) + TLS(2 RTT) = 3 RTT before data
// HTTP/2  + TLS 1.3:   TCP(1 RTT) + TLS(1 RTT) = 2 RTT before data
// HTTP/3  + QUIC:      QUIC+TLS combined = 1 RTT (or 0-RTT for repeat)
//
// 0-RTT: client stores session ticket from previous visit
//        next visit: sends HTTP request + session ticket in first packet
//        server decrypts and responds without waiting for handshake
//
// Who uses HTTP/3?
// Cloudflare, Google, Facebook, YouTube — majority of their traffic
// Spring Boot: experimental via Netty QUIC / Vert.x
//
// Detect HTTP/3 support:
// Server sends Alt-Svc header: Alt-Svc: h3=":443"; ma=86400
// Browser upgrades to HTTP/3 on next request