Building a Zero-Allocation HTTP/2 HPACK Header Encoder in Go

At a transaction rate of 250,000 requests per second, a microservice built with Go can easily spend 15% of its CPU time doing nothing but collecting garbage. When investigating p99.9 latency spikes exceeding 50 milliseconds using go tool pprof and go tool trace, the culprit is often not business logic, database queries, or network I/O. Instead, it is the short-lived heap allocations generated by the HTTP/2 framing layer. HPACK (RFC 7541), the header compression standard for HTTP/2, is a notorious source of this overhead. Every incoming and outgoing request requires encoding and decoding headers, and the standard Go implementations dynamically allocate slices, strings, and hash maps to maintain the dynamic indexing tables. Under high concurrency, these allocations quickly accumulate, triggering the Go scavenger and forcing the runtime into frequent concurrent mark-and-sweep cycles. This article walks through the design and implementation of a zero-allocation HPACK header encoder in Go, demonstrating how to bypass the heap entirely using pre-allocated circular ring buffers, state-free Huffman encoders, and custom byte-level lookup tables.

The HPACK Allocation Problem

HPACK compresses HTTP headers by exploiting redundancy. Instead of transmitting string keys and values verbatim, it leverages two indexing tables:

1. The Static Table: A read-only table of 61 common header fields (e.g., :method: GET, accept-encoding: gzip, deflate).
2. The Dynamic Table: A stateful FIFO queue shared between the encoder and decoder that stores custom headers observed during the lifetime of the connection.

When a header field is sent, the encoder checks if it exists in either table. If it finds an exact match (both name and value), it simply transmits the integer index. If it matches only the name, it transmits the index along with the new value. If no match is found, it transmits both name and value as raw strings, optionally compressed using a static Huffman code.

The standard library implementation (golang.org/x/net/http2/hpack) is designed for general-purpose use. It relies on standard Go strings and maps to track entries in the dynamic table. This design introduces several allocation vectors:

• String Promotion: Converting incoming byte slices (from the network reader) to Go strings so they can be keys in search maps or stored in the dynamic table.
• Map Overhead: Standard Go maps are bucket-based structures. Inserting and deleting items dynamically triggers bucket allocations and rehashing.
• Intermediary Buffers: Formatting varints and Huffman streams often utilizes temporary slices that escape to the heap due to compiler limitations in proving escape bounds.

For a long-lived HTTP/2 or gRPC connection handling hundreds of streams, these allocations degrade memory locality and pressure the garbage collector. To build a zero-allocation encoder, we must manage memory manually using pre-allocated contiguous buffers and avoid Go’s standard map and string types entirely.

Designing the Memory Layout

To achieve zero heap allocations during the encoding process, we must enforce a strict memory budget. All memory required by the encoder—for tracking the dynamic table, Huffman compression, and output serialization—must be allocated once at startup.

The core of our zero-allocation design is the DynamicTable struct. Instead of storing pointers to individual header objects, it uses:

• A contiguous byte slice (storage) that acts as an arena for all header names and values.
• A pre-allocated ring buffer (fields) of fixed size to keep track of the logical headers.
• A secondary scratchpad byte slice (scratch) of identical capacity to storage for defragmentation.

When we evict an item from the dynamic table, we do not free the memory. We simply advance the tail index of our ring buffer. When the storage slice runs out of space, we slide the active data to the beginning of the buffer (defragmentation) without performing new heap allocations.

Let’s begin by implementing the lowest-level encoder component: the variable-length integer encoder.

1. Zero-Allocation Varint Encoding

HPACK uses prefix integer encoding to represent table indices, string lengths, and configuration values. An integer is represented by an $N$-bit prefix on the first byte, with subsequent bytes carrying 7 bits of data plus a continuation bit.

In // snippet-1, we modify the last byte of dst in place to write the prefix value, and then we append subsequent bytes directly to the slice. Since Go slices are passed by value (with the slice header copied to the stack), appending to a slice with sufficient capacity does not trigger a heap allocation.

2. In-Place Huffman Encoding

HPACK specifies a static Huffman code for compressing header names and values. Standard libraries write compressed bits to a temporary buffer and copy them to the destination. We can eliminate this intermediary allocation by implementing a state-free bit writer that encodes ASCII characters directly into the output byte slice.

By packing bits into a uint64 register in // snippet-2, we can write up to 8 bytes of compressed data before flushing. This removes the need for any byte-level allocation during Huffman compression.

3. Fixed-Capacity Dynamic Table

The dynamic table is a FIFO queue. In a standard implementation, this is represented by a slice of structs containing strings:

type HeaderField struct {
    Name, Value string
}

This pattern is disastrous for GC latency. The HeaderField structs are allocated individually, and the strings they reference contain pointers to separate memory locations on the heap. When the garbage collector runs, it must traverse these pointers (pointer chasing), significantly increasing mark-and-sweep times.

To fix this, we define a cache-friendly, flat structure:

In // snippet-3, the HeaderField elements in the fields slice point to sub-slices of storage. No new heap allocations are performed when entries are inserted; we simply slice the existing storage array.

4. Eviction and Defragmentation

When inserting a new entry into the dynamic table, we must first verify if adding it would exceed the maximum byte capacity (maxSize). If it does, we evict the oldest entries at the tail of the queue.

Over time, evicting items leaves dead space at the beginning of the storage buffer. If the remaining active items drift toward the end of the buffer, we will eventually run out of contiguous space, even if the total active bytes are well within limits. To solve this, we implement a defragmentation routine that packs the remaining active headers into the front of our buffer, swapping storage and scratch to avoid allocations.

In // snippet-4, defragmentation relies on the fact that both storage and scratch are pre-allocated during table initialization. By swapping their slice references, we shift active data without requesting new segments from the OS memory manager.

5. In-Place Header Matching

To check if a header should be encoded as an index, we must search the static and dynamic tables. In standard Go libraries, this search involves allocating temporary keys or strings. We can write an allocation-free search using bytes.Equal.

The lookup algorithm in // snippet-5 returns a logical index that accounts for the table layout (where 1–61 refers to the static table and $62+$ refers to the dynamic table, ordered from newest to oldest).

6. The Encoder State Machine

Now we combine these components into the final Encoder struct. The encoder takes a header field, performs the search, formats the output based on the result type (indexed, literal with indexing, or literal without indexing), and appends it to a destination byte slice.

The EncodeHeader function in // snippet-6 is the main interface. Because it takes and returns slice types, and relies entirely on our pre-allocated table buffers, it runs without triggering dynamic memory allocation.

7. Lifecycle Management and Pooling

In a production Go network server, each HTTP/2 connection is assigned its own stream writer. To optimize resources across connections, we should reuse Encoder instances using a pool. Since Go’s sync.Pool operates on the heap, retrieving an object does not allocate memory as long as the pool has warm instances.

As demonstrated in // snippet-7, by calling Reset() on the dynamic table inside Put and Get, we clear the logical trackers while retaining the allocated memory backing our buffers. This keeps the execution hot and prevents allocations during connection setup and teardown.

Performance Profile: Standard vs. Zero-Allocation

To verify our encoder’s design, we can run benchmarks using Go’s testing package. We compare our implementation with Go’s official golang.org/x/net/http2/hpack encoder using a realistic batch of HTTP headers:

• :method: GET
• :path: /api/v1/resource
• user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)...
• cookie: session_token=deadbeef1234567890

Here are the results obtained under Go 1.22:

Our zero-allocation design is approximately 3.6x faster than the standard library, but the primary benefit is the allocation metrics. Moving from 6 allocations per frame sequence to zero completely eliminates the garbage collection overhead associated with HPACK framing. At 250,000 requests per second, this optimization prevents over 96 megabytes of garbage allocations per second per core, resulting in a cleaner heap profile and reduced latency jitter.

Production Pitfalls and Trade-Offs

While zero-allocation techniques offer clear performance benefits, they introduce trade-offs that must be managed:

1. Thread Safety

The Encoder struct is not thread-safe. It is designed to be used by a single connection writer thread. If your application needs to write headers concurrently from multiple goroutines (for instance, when pushing server-initiated HTTP/2 streams), you must synchronize access to the encoder or dedicate one encoder instance per stream write queue.

2. Giant Headers (Buffer Overflow)

The dynamic table size limit (maxSize) is negotiated via HTTP/2 settings frames (typically 4096 bytes). In our design, the storage size is static. If an upstream service tries to write a custom header field larger than maxSize (for example, a large authentication token or JSON web token), our encoder evicts all existing records and defaults to using literals. You should ensure that your storage capacity is sized to handle your application’s expected header limits safely.

3. Escape Analysis Violations

When integrating this code into your server, pay close attention to escape analysis. Run your builds with compiler flags to inspect variables:

go build -gcflags="-m -l" ./...

If you pass the resulting slice from EncodeHeader to an interface method (such as io.Writer.Write), the slice header will escape to the heap. To prevent this, make sure your stream writer handles the raw byte slices directly without wrapping them in intermediate interface layers.

Conclusion

By substituting standard Go maps and strings with pre-allocated circular buffers, flat memory layouts, and inline bit-shifting Huffman encoders, you can build network protocols that operate efficiently and bypass Go’s garbage collector. Zero-allocation design requires a shift in how we think about data structures in Go, prioritizing static allocations and predictable memory layouts over runtime convenience. When deployed in low-latency systems, this investment pays off in stable p99 latencies and improved throughput.