Request-Response Pattern

HTTP is the foundation of data communication on the web and the most common protocol for synchronous service-to-service communication. Yet HTTP is not a single, static protocol—it has evolved dramatically across three major versions, each addressing fundamental limitations of its predecessor.

Understanding the differences between HTTP/1.1, HTTP/2, and HTTP/3 is not merely academic. These differences profoundly impact latency, throughput, connection management, and system architecture. A system architect who doesn't understand these protocols cannot make informed decisions about service communication, load balancer configuration, or performance optimization.

This page provides a comprehensive technical exploration of each HTTP version, explaining not just what changed, but why it changed and how it affects your systems.

HTTP/1.1, standardized in 1997 (RFC 2068, later RFC 2616 and RFC 7230-7235), has been the backbone of the web for over two decades. Despite its age, it remains widely supported and understood. To appreciate its successors, we must first deeply understand HTTP/1.1's mechanics and limitations.

Request-Response Model:

HTTP/1.1 follows a strict request-response model over TCP connections:

1. Client opens a TCP connection to the server (3-way handshake)
2. Client sends an HTTP request (method, headers, optional body)
3. Server processes and sends an HTTP response (status, headers, body)
4. Connection may be kept alive for subsequent requests

Persistent Connections (Keep-Alive):

Before HTTP/1.1, every request required a new TCP connection. HTTP/1.1 introduced persistent connections (keep-alive) as the default, allowing multiple requests over a single connection:

[TCP Handshake] → [Request 1] → [Response 1] → [Request 2] → [Response 2] → ... → [Close]

This reduced the overhead of connection establishment but introduced a new problem: head-of-line blocking.

Pipelining (The Failed Solution):

HTTP/1.1 included pipelining, which allows sending multiple requests without waiting for responses:

Client: [Request 1][Request 2][Request 3] → Server
Server: [Response 1][Response 2][Response 3] → Client

However, pipelining had critical flaws:

• Responses MUST be returned in request order (still head-of-line blocking)
• Intermediate proxies often didn't support it correctly
• A failed request would require re-sending all subsequent requests
• Browser support was inconsistent

In practice, pipelining was disabled by default in browsers and rarely used.

The Workaround: Multiple Connections:

To work around head-of-line blocking, browsers open multiple parallel connections to each origin (typically 6 connections per domain). This allows parallelism but has costs:

• Each connection requires TCP handshake (1 RTT minimum, 2 for TLS)
• Each connection competes for bandwidth (no coordinated congestion control)
• Each connection consumes server resources (memory, file descriptors)
• Connection limits are per-origin, leading to domain sharding hacks

HTTP/2, standardized in 2015 (RFC 7540), was a major overhaul designed to address HTTP/1.1's performance limitations. It originated from Google's SPDY protocol and introduces several revolutionary concepts.

Binary Framing Layer:

The most fundamental change in HTTP/2 is the introduction of a binary framing layer. Instead of text-based request/response pairs, HTTP/2 breaks communication into frames:

• DATA frames: Carry request/response body data
• HEADERS frames: Carry HTTP headers (compressed)
• PRIORITY frames: Indicate stream priority
• RST_STREAM frames: Cancel a stream
• SETTINGS frames: Configure connection parameters
• PUSH_PROMISE frames: Server push announcements
• PING frames: Heartbeat/RTT measurement
• GOAWAY frames: Graceful connection shutdown
• WINDOW_UPDATE frames: Flow control
• CONTINUATION frames: Large header blocks

Each frame has a fixed 9-byte header containing length, type, flags, and stream identifier.

Streams: The Key to Multiplexing:

HTTP/2 introduces the concept of streams—independent, bidirectional sequences of frames within a single TCP connection. Each request-response pair gets its own stream, identified by a unique stream ID.

┌─────────────────────────────────────────────────────────────┐
│                    Single TCP Connection                     │
├─────────────────────────────────────────────────────────────┤
│  Stream 1: [HEADERS][DATA][DATA][DATA]                      │
│  Stream 3: [HEADERS][DATA]                                  │
│  Stream 5: [HEADERS][DATA][DATA]                            │
│  Stream 7: [HEADERS][DATA][DATA][DATA][DATA]                │
│                                                             │
│  Frames are interleaved, multiple requests in flight:       │
│  [H:1][D:1][H:3][D:5][D:1][D:3][H:7][D:5][D:7][D:1]...     │
└─────────────────────────────────────────────────────────────┘

This solves application-layer head-of-line blocking. A slow response on Stream 1 doesn't block Stream 3's frames from being sent. Streams are logically independent even though they share a single TCP connection.

Key Point: Client-initiated streams use odd numbers (1, 3, 5...), server-initiated streams use even numbers (2, 4, 6...). Stream 0 is reserved for connection-level control.

HPACK: Header Compression:

HTTP/2 introduces HPACK compression for headers, addressing the significant overhead of repeating headers in HTTP/1.1:

1. Static Table: 61 pre-defined header name-value pairs (common headers like :method: GET, :status: 200)
2. Dynamic Table: Connection-specific table built from previously sent headers
3. Huffman Encoding: Literal values can be Huffman-encoded

How HPACK Works:

First Request:
  :method: GET           → Index 2 (static table)
  :path: /api/users      → Literal, add to dynamic table
  Authorization: Bearer X → Literal, add to dynamic table

Second Request:
  :method: GET           → Index 2 (static table)
  :path: /api/users      → Index 62 (dynamic table) - 1 byte!
  Authorization: Bearer X → Index 63 (dynamic table) - 1 byte!

Headers that were 500+ bytes in HTTP/1.1 can be represented in 10-20 bytes after initial exchange. On a connection with many requests, this compression is dramatic.

Stream Prioritization:

HTTP/2 allows clients to indicate the relative importance of streams through:

1. Weight: Each stream has a weight (1-256) indicating relative importance
2. Dependencies: Streams can depend on other streams, creating a priority tree

                    ┌─────────┐
                    │ Root (0)│
                    └────┬────┘
              ┌──────────┴──────────┐
        ┌─────┴─────┐         ┌─────┴─────┐
        │ Stream 1  │         │ Stream 3  │
        │ CSS (w:16)│         │ JS (w:16) │
        └─────┬─────┘         └───────────┘
              │
        ┌─────┴─────┐
        │ Stream 5  │
        │ Image(w:1)│
        └───────────┘

        CSS loads first, then JS, then (after CSS) images

However, prioritization is advisory—servers may respect it differently, and it's been removed in HTTP/3 in favor of a simpler priority scheme.

Server Push:

Server push allows the server to send resources before the client requests them:

1. Client requests index.html
2. Server responds with index.html AND pushes style.css and app.js
3. Client receives all resources without additional round-trips

In practice, server push has seen limited adoption due to:

• Complexity of knowing what to push
• Risk of pushing resources already in browser cache
• Better alternatives (preload hints, HTTP/103 Early Hints)

HTTP/3, standardized in 2022 (RFC 9114), represents a fundamental shift: it abandons TCP entirely in favor of QUIC (RFC 9000), a new transport protocol built on UDP. This isn't just an incremental improvement—it's a reimagining of how HTTP should work at the transport layer.

Why Leave TCP?

TCP was designed in the 1970s for a different era:

1. TCP is kernel-bound: Updating TCP requires OS updates, deployed across millions of devices
2. TCP has a fixed handshake: 1 RTT minimum (2 with TLS), cannot be improved without breaking compatibility
3. TCP provides ordered, reliable delivery: But this means packet loss blocks ALL data, not just the affected stream
4. TCP connections are tied to IP:port 4-tuples: Network changes (WiFi to cellular) break connections

QUIC: Designed for Modern Networks:

QUIC solves these problems:

1. User-space protocol: Runs over UDP, can be updated via application updates
2. 0-RTT handshake: For resumed connections, send data in first packet
3. Independent stream delivery: Packet loss only affects the stream whose data was lost
4. Connection migration: Connections survive IP address changes

QUIC's Architecture:

┌─────────────────────────────────────────────────────────────┐
│                      HTTP/3 Layer                            │
│  (Request/Response semantics, QPACK header compression)     │
├─────────────────────────────────────────────────────────────┤
│                      QUIC Layer                              │
│  ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐           │
│  │ Stream 1│ │ Stream 2│ │ Stream 3│ │ Stream N│           │
│  └─────────┘ └─────────┘ └─────────┘ └─────────┘           │
│  Connection Management | Encryption | Flow Control          │
├─────────────────────────────────────────────────────────────┤
│                      UDP Layer                               │
│              (Unreliable datagram delivery)                  │
└─────────────────────────────────────────────────────────────┘

Key QUIC Features:

1. Integrated TLS 1.3:

QUIC integrates TLS 1.3 directly, providing:

• 1-RTT handshake for new connections (TLS + QUIC combined)
• 0-RTT for resumed connections (send data immediately)
• All packets encrypted (even packet numbers)

2. True Stream Independence:

Unlike TCP where a single lost packet blocks everything, QUIC delivers packets independently per stream:

HTTP/2 over TCP (packet loss in Stream 1):
  Stream 1: [Data][Data][LOST][Data] → ALL STREAMS BLOCKED
  Stream 2: [Data][Data] ← Blocked waiting for TCP retransmit
  Stream 3: [Data] ← Blocked waiting for TCP retransmit

HTTP/3 over QUIC (packet loss in Stream 1):
  Stream 1: [Data][Data][LOST][Data] → Only Stream 1 blocked
  Stream 2: [Data][Data] → Delivered immediately
  Stream 3: [Data] → Delivered immediately

3. Connection Migration:

QUIC connections are identified by a Connection ID, not IP:port tuple:

• User moves from WiFi to cellular → Connection survives
• NAT rebinding changes port → Connection survives
• VPN connects/disconnects → Connection survives (if Connection ID preserved)

QPACK: HTTP/3's Header Compression:

HTTP/3 uses QPACK instead of HPACK due to QUIC's stream independence. The challenge: HPACK requires ordered delivery (dynamic table updates must be received in order), but QUIC streams may arrive out of order.

QPACK solution:

• Uses separate unidirectional streams for encoder/decoder instructions
• Allows references to dynamic table only after explicit acknowledgment
• Slightly less compression than HPACK, but works with unordered delivery

HTTP/3 Priority System:

HTTP/3 replaces the complex priority trees of HTTP/2 with a simpler system:

• Urgency (0-7): How urgent is this request? (0 = most urgent)
• Incremental: Can partial data be used? (useful for progressive images)

Expressed via the Priority header:

Priority: u=3, i

(Urgency 3, incremental rendering supported)

This simplicity improves interoperability—HTTP/2's complex priority system was inconsistently implemented.

Understanding performance differences between HTTP versions requires examining multiple dimensions: connection establishment, throughput, latency under loss, and resource utilization.

Connection Establishment Latency:

The time from connection initiation to first data transmission varies significantly:

Multiplexing Effectiveness:

On a page loading 50 resources:

HTTP/1.1 (6 connections):
  50 resources ÷ 6 connections = ~8 sequential rounds
  With 100ms RTT and 50ms processing: 8 × 150ms = 1200ms minimum

HTTP/2 (1 connection):
  All 50 requests sent immediately
  Bottleneck is bandwidth + server processing
  With sufficient bandwidth: ~200-300ms

HTTP/3 (1 connection):
  Same multiplexing as HTTP/2
  Better on lossy networks (independent streams)
  With 2% packet loss: ~200-350ms (vs HTTP/2's 400-600ms)

Real-World Performance Data:

Measurements from large-scale deployments show:

Google (2020 QUIC deployment):

• Search latency reduced by 8% on average
• YouTube rebuffering reduced by 18%
• Improvement more pronounced on mobile networks

Cloudflare (HTTP/3 analysis):

• Time to First Byte improved by 12.4% globally
• More significant improvements in high-latency regions
• Connection migration particularly valuable for mobile users

Akamai (HTTP/2 vs HTTP/1.1):

• Page load times improved 5-15% on average
• Improvement highly dependent on number of resources
• Pages with many small resources benefit most

Key Insight:

The performance benefit depends heavily on:

1. Network quality: HTTP/3 shines on lossy networks
2. Number of requests: More requests = more multiplexing benefit
3. Request size: Header compression matters more for small requests
4. Connection reuse: 0-RTT benefits returning visitors

Choosing the right HTTP version depends on your specific context. Here's practical guidance for different scenarios:

For External APIs (Public-Facing):

1. Default to HTTP/2: Broad client support, significant improvements over HTTP/1.1
2. Enable HTTP/3: As supplementary protocol for capable clients
3. Maintain HTTP/1.1 fallback: For oldest clients and debugging

For Internal Services (Microservices):

1. HTTP/2 is typically ideal: Multiplexing benefits inter-service communication
2. Consider gRPC (HTTP/2): If you need streaming or binary efficiency
3. HTTP/3 consideration: May help if services span data centers with variable network quality

For Mobile Applications:

1. Prioritize HTTP/3: Mobile networks are lossy; connection migration is valuable
2. HTTP/2 fallback: When HTTP/3 is blocked (enterprise WiFi, some cellular networks)
3. Connection pooling: Reuse connections aggressively for 0-RTT benefits

Let's examine practical configuration for enabling different HTTP versions in common scenarios.

We've traced HTTP's evolution from the text-based, sequential protocol of HTTP/1.1 to the modern, multiplexed protocols of HTTP/2 and HTTP/3. Let's consolidate the key insights:

What's Next:

With an understanding of HTTP protocol mechanics, we'll examine the request lifecycle in detail—what happens from the moment code initiates a request to when the response is processed, including DNS resolution, connection establishment, TLS negotiation, and response handling.