Why HTTP/2 Beats HTTP/1.1: Deep Dive into Requests, Responses, and Pipelining
This article explains the structure of HTTP/1.1 request and response messages, the limitations of TCP such as head‑of‑line blocking, the evolution from SPDY to HTTP/2 with binary framing, multiplexed streams, header compression, server push, ALPN negotiation, and practical Wireshark capture techniques for HTTP/2 traffic.
HTTP/1.1 Request Message
HTTP request messages consist of a request line, request headers, and payload data. Boundaries are marked by \r\n and spaces.
Request Line
The request line contains Method, a space, URI, a space, Version, and \r\n.
Method Types
Methods are evaluated for safety and idempotence.
Method
Function
Description
Safety
Idempotent
GET
SELECT
Retrieve one or many resources, optionally using query parameters and pagination.
✓
✓
POST
CREATE
Create a resource from the request body.
✗
✗
PUT
UPDATE
Replace a resource with the request body.
✗
✓
PATCH
UPDATE
Modify a resource partially.
✗
✓
DELETE
DELETE
Delete a resource.
✗
✓
HEAD
Fetch metadata without the body.
✓
✓
OPTIONS
Query server capabilities or resource options.
✓
✓
URI Format
A complete URI structure is illustrated below.
Request Header
Common request header fields include Host, Authorization, Accept, Accept-Charset, Accept-Encoding, Accept-Language, User-Agent, Cache-Control, Connection, and Cookie.
HTTP/1.1 Response Message
Response messages consist of a response line, response headers, and payload data, separated by \n and spaces.
Response Line
The response line contains Version, a space, Status Code, a space, Status Description, and \r\n.
Status Codes
1xx: Informational
2xx: Success
3xx: Redirection
4xx: Client error
5xx: Server error
Response Header
Common response header fields include Server, Allow, Set-Cookie, Location, Content-Type, Content-Length, Content-Encoding, Content-Language, Expires, and Last-Modified.
TCP Continuous ARQ Pipelining
HTTP/1.1 pipelining relies on TCP Continuous ARQ, allowing multiple HTTP requests to be sent in parallel over a single TCP connection, improving efficiency.
Head‑of‑Line Blocking
TCP’s stop‑and‑wait ACK can cause head‑of‑line blocking when a segment is lost, stalling subsequent data until retransmission.
TCP Keepalive and Long Connections
HTTP/1.1 defaults to keep‑alive connections, enabling multiple requests/responses over the same TCP connection and reducing latency.
Cookie Mechanism
Cookies give the otherwise stateless HTTP protocol memory by storing identifiers on the client that the server can use to recognize subsequent requests.
SPDY Protocol
SPDY introduced data frames, multiplexing, header compression, and priority to improve transport efficiency; it later evolved into HTTP/2.
HTTP/2 Protocol
HTTP/2, standardized in RFC 7540, builds on SPDY to provide binary framing, multiplexed streams, header compression (HPACK), server push, and ALPN for protocol negotiation.
Basic Concepts
Connection: a TCP connection that can host multiple streams.
Stream: a virtual tunnel identified by a stream ID.
Message: one or more frames forming a request or response.
Frame: the smallest binary unit of HTTP/2.
Frames
Frames are binary encoded, replacing the textual delimiters of HTTP/1.1.
Streams and Multiplexing
Multiple streams share a single TCP connection, allowing concurrent request/response pairs without head‑of‑line blocking.
Stream Priority
Each stream carries a 31‑bit priority value (0 = highest) that servers can use to allocate resources.
Header Compression (HPACK)
HPACK uses a static table, a dynamic table, and optional Huffman coding to compress header fields, dramatically reducing overhead.
:method: GET<br/>:scheme: httpServer Push
Servers can proactively send resources (e.g., CSS, images) associated with an HTML page without explicit client requests, reducing load time.
ALPN (Application‑Layer Protocol Negotiation)
ALPN, a TLS extension, lets the client and server agree on using HTTP/2 or HTTP/1.1 during the TLS handshake.
Using Wireshark to Capture HTTP/2
Enable HTTP/2 decoding in Wireshark, capture traffic, and optionally provide SSL key logs or server private keys to decrypt TLS‑encrypted streams.
SSLKEYLOGFILE for Browsers
Set the SSLKEYLOGFILE environment variable to capture TLS secrets for Chrome or Firefox, then load the log file in Wireshark.
cURL SSLKEYLOG
Use SSLKEYLOGFILE=ssl_log.txt curl … to generate a key log while capturing packets with tcpdump.
Server Private Key Decryption
Import the server’s RSA private key into Wireshark to decrypt TLS traffic (not applicable to TLS 1.3).
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.
