Fundamentals 24 min read

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.

AI Cyberspace
AI Cyberspace
AI Cyberspace
Why HTTP/2 Beats HTTP/1.1: Deep Dive into Requests, Responses, and Pipelining

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: http

Server 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).

TCPHTTPHTTP/2
AI Cyberspace
Written by

AI Cyberspace

AI, big data, cloud computing, and networking.

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.