Why Does HTTP Need Three Handshakes? A Deep Dive into HTTP Versions and Performance
This article explains the fundamentals of the HyperText Transfer Protocol, covering the OSI model layers, TCP three‑way handshake, bandwidth versus latency, and the evolution from HTTP/0.9 through HTTP/1.0, 1.1, and HTTP/2, highlighting key improvements such as persistent connections, pipelining, chunked transfer, and server push.
HTTP: HyperText Transfer Protocol (HTTP) is an application‑layer protocol for distributed, collaborative and hypermedia information systems and forms the basis of data communication on the World Wide Web.
As programmers, you’re familiar with HTTP, but the various numbered versions can be confusing; this article clarifies them.
1. Prerequisite
Before discussing HTTP, we briefly review the five‑layer OSI model, the TCP three‑way handshake, and the concepts of bandwidth and latency.
1.1 Five‑layer model
Physical layer defines how devices transmit bits (network cards, cables, fiber).
Data link layer establishes a link between communicating entities.
Network layer creates logical links for node‑to‑node transmission (IP).
Transport layer provides reliable end‑to‑end service (TCP).
Application layer offers services to software, built on TCP (HTTP).
1.2 Three‑way handshake
First handshake: client sends SYN with a sequence number, moves to SYN‑SEND state, and waits for server acknowledgment.
Second handshake: server replies with SYN‑ACK and its own sequence number, acknowledges the client’s SYN, and moves to SYN‑RECEIVED.
Third handshake: client sends ACK, acknowledges the server’s SYN, and the connection becomes ESTABLISHED.
Server receives the final ACK and also transitions to ESTABLISHED.
Why must there be three handshakes? Could it be two or four?
1.3 Bandwidth and latency
Two factors affect HTTP requests: bandwidth and latency.
Bandwidth is no longer a major concern in the modern Internet era, so latency becomes the focus.
Browser head‑of‑line blocking: browsers limit concurrent connections per domain (typically 4‑6), causing excess requests to wait.
Connection reuse: each HTTP request incurs a TCP handshake and slow start; high latency amplifies this cost.
DNS lookup: resolving a domain name to an IP address adds delay, which can be mitigated with DNS caching.
2. History of HTTP
HTTP/0.9
Introduced in 1990, HTTP/0.9 lacked a formal standard, supported only the GET method, could not handle MIME types, and closed the TCP connection after each response.
GET /index.html // request index.htmlHTTP/1.0
Standardized in May 1996 (RFC 1945). It added support for text, images, video, binary files, and introduced POST and HEAD methods. Headers, status codes, caching, and content encoding also appeared.
Request example:
GET / HTTP/1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5)
Accept: */*Response example:
HTTP/1.0 200 OK
Content-Type: text/plain
Content-Length: 137582
Expires: Thu, 05 Dec 1997 16:00:00 GMT
Last-Modified: Wed, 5 August 1996 15:55:28 GMT
Server: Apache 0.84
<html>
<body>Hello World</body>
</html>Drawback: each TCP connection can send only one request; a new connection is required for additional resources.
Browsers mitigate this by adding the Connection: keep-alive header.
HTTP/1.1
Published in 1997 (RFC 2068, later RFC 2616) and now the dominant version. Key improvements:
Persistent connections are default; connections remain open unless Connection: close is sent.
Pipelining allows multiple requests to be sent without waiting for each response.
Content‑Length header declares the size of the response body.
Chunked transfer encoding enables sending data in chunks when the total size is unknown.
New request methods: PUT, PATCH, OPTIONS, DELETE, HEAD.
Example headers:
Content-Length: 2485Transfer-Encoding: chunkedHTTP/2
Released in 2015 and built on HTTPS. It dramatically improves performance through:
Binary framing: both headers and payload are binary, enabling new frame types.
Multiplexing: multiple request/response streams share a single TCP connection, eliminating head‑of‑line blocking.
Streams: each request/response is a separate stream with a unique ID; streams can be prioritized or cancelled independently.
Header compression reduces redundant header transmission.
Server push: the server can proactively send resources without an explicit client request.
These enhancements make HTTP/2 faster and more efficient than its predecessors.
References: "HTTPS – What You Must Know", "HTTP Protocol Introduction", and related articles on HTTP version differences.
Signed-in readers can open the original source through BestHub's protected redirect.
This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactand we will review it promptly.
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.