HTTP/1.1 vs. HTTP/2 – Definition and Differences
Compare the two protocol versions: text versus binary framing, multiplexing, header compression, and which optimisations became obsolete.
HTTP/2 keeps the semantics of HTTP/1.1 — the same methods, statuses, and headers — and changes how those are put on the wire. The differences are all in transport, not meaning.
1. Key Differences
| Aspect | HTTP/1.1 | HTTP/2 |
|---|---|---|
| Framing | Text | Binary |
| Requests per connection | One at a time | Many, multiplexed |
| Head-of-line blocking | At the application layer | Removed there; remains at TCP |
| Headers | Sent in full each time | Compressed with a shared table |
| Prioritisation | None | Streams can be prioritised |
| Server push | No | Defined, and largely abandoned in practice |
2. Multiplexing Is the Central Change
In HTTP/1.1 a connection carries one request at a time. A slow response blocks everything queued behind it, which is why browsers opened several connections per host and why developers worked around the limit.
HTTP/2 interleaves many streams over one connection, so a slow response no longer blocks the others at the application layer.
3. Header Compression Matters More Than Expected
Requests to one site repeat nearly identical headers — cookies, user agent, accept values. Over dozens of requests that repetition is substantial.
HTTP/2 maintains a shared table of previously sent headers and refers to entries by index, which materially reduces overhead on header-heavy traffic.
4. Optimisations That Became Obsolete
Several HTTP/1.1 workarounds are now counterproductive:
- Domain sharding — spreading assets across hostnames to get more parallel connections. Now it fragments one efficient connection into several.
- Concatenating files to reduce request count — less necessary, and it harms caching granularity.
- Image sprites — same reasoning.
- Inlining resources to avoid requests — trades cacheability for a saving that no longer applies.
5. What Did Not Change
Methods, status codes, headers, cookies, and caching semantics are identical. An application does not need to change to benefit; the transport does the work.
6. TCP Head-of-Line Blocking Remains
Multiplexing removes blocking at the application layer, but all streams share one TCP connection. A lost packet stalls delivery for every stream until it is retransmitted.
That limitation is precisely what HTTP/3 addresses by moving to QUIC over UDP, where streams are independent at the transport layer.
7. Why It Matters for Client Identification
HTTP/2's framing exposes implementation choices — settings values, window sizes, header ordering, priority handling — that differ between browsers and libraries.
Those choices form a fingerprint available from a connection's first frames, which is why protocol behaviour became a client-classification signal in a way HTTP/1.1 never allowed.
8. Summary
HTTP/2 preserves HTTP semantics and replaces the wire format: binary framing, multiplexed streams, and compressed headers.
It removes application-layer blocking and makes several HTTP/1.1 optimisations obsolete, while leaving TCP-level blocking for HTTP/3 to solve — and it exposes implementation details that identify clients.