Mastering HTTP/2 in Go: Binary Framing, Multiplexing, and Server Push Explained

Introduction

In many projects developers increasingly use the Go language. This article, originally submitted by the 360 Search Technical Team (author Fu Kun), shares a Go‑based development example that combines HTTP/2.

Why HTTP/2?

HTTP/2 does not change the application semantics of HTTP. Methods, status codes, and URIs remain the same as in HTTP/1.1, but the protocol now uses binary framing to hide complexity, enabling new features while staying compatible with existing applications. For ordinary web apps the usage is identical to HTTP/1, but to exploit new features a deeper understanding is required.

New Features of HTTP/2

Binary framing (HTTP Frames)

Multiplexing

Header compression

Server push

Binary Framing Basics

HTTP/2 decomposes communication into three core concepts:

Frame – the smallest unit of communication, each with its own format and type.

Message – similar to a Request/Response, composed of one or more frames.

Stream – a bidirectional byte stream established after the connection, used to carry messages.

All communication occurs over a single TCP connection, with one or more streams carrying data.

Frame Basic Structure

<code>+-----------------------------------------------+<br>|               Length (24)                   |<br>+---------------+---------------+---------------+<br>|   Type (8)    |   Flags (8)   |<br>+-+-------------+---------------+-------------------------------+<br>|R|               Stream Identifier (31)               |<br>+=+=============================================================+<br>|               Frame Payload (0...)               ...<br>+---------------------------------------------------------------+</code>

Length

Specifies the size of the Frame Payload. It is a 24‑bit integer, theoretically up to 2^24‑1 bytes, but the default maximum is 2^14 bytes. The limit can be changed with the SETTINGS frame using SETTINGS_MAX_FRAME_SIZE .

Type

Indicates the frame type; currently ten types (0‑9) are defined.

Flags

Reserved bits used by specific frame types (e.g., HEADERS, DATA, SETTINGS, PING).

R

A 1‑bit reserved field that must be set to 0.

Stream Identifier

Identifies the stream (0‑2^31‑1). Stream 0 is reserved for control frames (e.g., SETTINGS, PING). Client‑initiated streams have odd IDs; server‑initiated streams have even IDs. IDs must increase monotonically; when the maximum is reached a new TCP connection is required.

Frame Types

DATA

Type 0x0 . Carries variable‑length binary data, essentially the body of an HTTP request or response.

<code>+---------------+<br>|Pad Length? (8)|<br>+---------------+-----------------------------------------------+<br>|               Data (*)               ...<br>+---------------------------------------------------------------+<br>|               Padding (*)               ...<br>+---------------------------------------------------------------+</code>

The END_STREAM flag (0x1) indicates the end of a stream. Padding is used to obscure frame size for security.

HEADERS

Type 0x1 . Opens a stream and carries HTTP header fields.

<code>+---------------+<br>|Pad Length? (8)|<br>+-+-------------+-----------------------------------------------+<br>|E|           Stream Dependency? (31)               |<br>+-+-------------+-----------------------------------------------+<br>|   Weight? (8)   |<br>+-+-------------+-----------------------------------------------+<br>|          Header Block Fragment (*)          ...<br>+---------------------------------------------------------------+<br>|               Padding (*)               ...<br>+---------------------------------------------------------------+</code>

The optional fields E , Stream Dependency , and Weight control stream priority.

PRIORITY

Type 0x2 . Specifies stream priority; cannot be sent on stream 0.

<code>+-+-------------------------------------------------------------+<br>|E|               Stream Dependency (31)               |<br>+-+-------------+-----------------------------------------------+<br>|   Weight (8)   |<br>+-+-------------+</code>

RST_STREAM

Type 0x3 . Immediately terminates a stream, optionally providing a 32‑bit error code.

<code>+---------------------------------------------------------------+<br>|                Error Code (32)                |<br>+---------------------------------------------------------------+</code>

SETTINGS

Type 0x4 . Configures connection‑wide parameters. Must be sent on stream 0 and acknowledged with the ACK flag.

Common settings include:

SETTINGS_HEADER_TABLE_SIZE (0x1) : Controls the size of the header compression table.

SETTINGS_ENABLE_PUSH (0x2) : Enables or disables server push.

SETTINGS_MAX_CONCURRENT_STREAMS (0x3) : Limits the number of concurrent streams (recommended ≥ 100).

Other settings such as SETTINGS_INITIAL_WINDOW_SIZE , SETTINGS_MAX_FRAME_SIZE , SETTINGS_MAX_HEADER_LIST_SIZE .

PUSH_PROMISE

Type 0x5 . Sent by the server before a server‑push, indicating the promised stream and associated headers.

<code>+---------------+<br>|Pad Length? (8)|<br>+-+-------------+-----------------------------------------------+<br>|R|           Promised Stream ID (31)               |<br>+-+-----------------------------+-------------------------------+<br>|          Header Block Fragment (*)          ...<br>+---------------------------------------------------------------+<br>|               Padding (*)               ...<br>+---------------------------------------------------------------+</code>

PING

Type 0x6 . Measures round‑trip time and checks connection liveness. Contains 64‑byte opaque data and an ACK flag.

<code>+---------------------------------------------------------------+<br>|                           Opaque Data (64)                |<br>+---------------------------------------------------------------+</code>

GOAWAY

Type 0x7 . Gracefully shuts down a connection, indicating the last stream that will be processed and an error code.

<code>+-+-------------------------------------------------------------+<br>|R|               Last-Stream-ID (31)               |<br>+-+-------------------------------------------------------------+<br>|                Error Code (32)                |<br>+---------------------------------------------------------------+<br>|          Additional Debug Data (*)          |<br>+---------------------------------------------------------------+</code>

WINDOW_UPDATE

Type 0x8 . Implements flow control; not covered in this article.

<code>+-+-------------------------------------------------------------+<br>|R|               Window Size Increment (31)               |<br>+-+-------------------------------------------------------------+</code>

CONTINUATION

Type 0x9 . Continues a header block that did not fit in a single HEADERS, PUSH_PROMISE, or CONTINUATION frame.

<code>+---------------------------------------------------------------+<br>|           Header Block Fragment (*)           ...<br>+---------------------------------------------------------------+</code>

Multiplexing

In HTTP/1.x each parallel request requires a separate TCP connection. HTTP/2’s binary framing allows multiple streams to be interleaved over a single connection, eliminating head‑of‑line blocking and reducing latency.

For example, a client may send a DATA frame on stream 5 while the server concurrently sends frames on streams 1 and 3, achieving true parallelism within one TCP connection.

Benefits of HTTP/2

Parallel, interleaved requests and responses without interference.

Multiple requests/responses share a single connection.

No need for workarounds such as domain sharding or image sprites.

Reduced latency and better network utilization, leading to faster page loads.

Elimination of head‑of‑line blocking and lower deployment cost.

Conclusion

This article covered the conceptual foundations of HTTP/2. To leverage its advanced features in Go, a solid understanding of frames, streams, and settings is essential. Future posts will dive deeper into practical usage.

References

RFC 7540 – HTTP/2: https://httpwg.org/specs/rfc7540.html#top

Web Performance Guide – HTTP/2: https://developers.google.com/web/fundamentals/performance/http2/