Understanding HTTP/2 Header Compression (HPACK) and Server Push
This article explains HTTP/2's header compression using the HPACK format—including static and dynamic tables, Huffman coding, and literal encoding—and the Server Push mechanism with PUSH_PROMISE frames, illustrating how these features reduce bandwidth and improve request latency.
In the previous article “HTTP/2 in Go (Part 1)” the binary framing and multiplexing of HTTP/2 were introduced; this article explains the remaining two major features: header compression using the HPACK format and server‑push.
HTTP/1.x transmits headers as plain text, wasting bandwidth. HTTP/2 uses HPACK, which combines a static table, Huffman coding and a dynamic table to encode header fields efficiently. The static table contains common pseudo‑headers (e.g., :method, :path) and can be referenced by index; values not present are encoded with Huffman coding or added to the dynamic table for future reuse.
+-------+-----------------------------+---------------+
| Index | Header Name | Header Value |
+-------+-----------------------------+---------------+
| 1 | :authority | |
| 2 | :method | GET |
| 3 | :method | POST |
| 4 | :path | / |
| 5 | :path | /index.html |
| 6 | :scheme | http |
| 7 | :scheme | https |
| 8 | :status | 200 |
| 9 | :status | 204 |
| 10 | :status | 206 |
| 11 | :status | 304 |
| 12 | :status | 400 |
| 13 | :status | 404 |
| 14 | :status | 500 |
| 15 | accept-charset | |
| 16 | accept-encoding | gzip, deflate |
| 17 | accept-language | |
| … | … | … |
| 58 | user-agent | |
| 59 | vary | |
| 60 | via | |
| 61 | www-authenticate | |
+-------+-----------------------------+---------------+When a header value such as :path=/post/20180811-http2_in_go_1.html is not in the static table, HPACK encodes the literal string length and value, which may occupy 25 bytes after Huffman compression, saving space compared with the raw text.
The dynamic table is shared between client and server for the lifetime of a connection; once a new header is transmitted it is stored with an index (e.g., Index = 76) so subsequent requests can reference it with a single byte.
Server Push allows the server to initiate additional streams before the client requests them. The server sends a PUSH_PROMISE frame containing a promised stream ID and a header block that describes the resource. The client may accept the push or reject it with RST_STREAM .
<!DOCTYPE html>
<html>
<head>
<link rel="stylesheet" href="push-style.css">
</head>
<body>
<h1>hello, server push</h1>
<img src="push-image.png">
</body>
</html>In HTTP/2 the original request for /index.html can be satisfied together with the two resource pushes, reducing the number of round‑trips from three to one.
The article also shows the HTTP/2 stream state machine, illustrating states such as idle, reserved, open, half‑closed (local/remote) and closed, and explains why the “reserved” state does not count toward stream‑concurrency limits, allowing PUSH_PROMISE frames to be sent even when the maximum number of active streams is reached.
For further reading see RFC‑7541 (HPACK) and the author’s notes on RFC‑7540 stream states.
360 Tech Engineering
Official tech channel of 360, building the most professional technology aggregation platform for the brand.
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.