v0.1.12613 Aug 2026·Networking

Real HTTP/2 multiplexing: many streams share one connection

Floati has spoken HTTP/2 for a while, but one request at a time per connection - so a page's resources from one host still opened several connections and ran them one after another. This release makes HTTP/2 do what it was designed for: a single connection now carries many requests AT ONCE, interleaving their data. When a page pulls a dozen things from the same server, they now ride one shared TCP and TLS handshake as concurrent streams instead of racing for separate connections. It is built the way the rest of this engine's network stack is - hand-written, no async runtime, no new dependencies: a single I/O thread owns the socket and demultiplexes frames to each waiting request, so the TLS state stays coherent and many threads can submit at once. Proven both in-process (a test server that withholds every response until it has seen several streams open on one socket, which a one-at-a-time client could never satisfy) and live (six concurrent fetches from one real HTTP/2 host, including multi-megabyte bodies, all correct). This closes the scorecard's own 'no real multiplexing' caveat. Networking moves 52 to 53; overall holds at 52.

Parity with the reference browser

74overall, as of v0.1.343

Web APIs / DOM surface42

Security architecture66

GPU / graphics acceleration68

DevTools / extensions72

Networking85

Media85

Accessibility85

Real-world site compatibility99

HTML parsing100

CSS parsing + selectors100

Layout: block / flex / grid / tables / writing-modes100

Paint + visual100

JavaScript language100

JavaScript performance (JIT)100

HTML parsing100

What changed 3 changes

Networking	A multiplexing HTTP/2 connection (h2/mux.rs): one I/O thread owns the socket, drains a queue of outgoing frames, then reads with a short timeout so queued writes are never starved behind a blocking read; incoming frames are demultiplexed by stream id into per-stream response slots, and callers block on a condvar until their stream completes. Request HEADERS are HPACK-encoded under the shared lock in wire order so the dynamic table stays coherent; the decoder lives only on the I/O thread. Per-stream and connection flow-control windows are honoured, as is the peer's max-concurrent-streams limit.
Networking	Wired into the connection pool: the HTTP/2 pool now holds one SHARED multiplexing connection per host (behind an Arc) instead of a stack of single-stream ones, so the fetch workers submit concurrent streams over it at once; a dead connection is evicted and re-dialed. The single-stream client remains as the reference implementation and keeps its own tests over the frame and HPACK layers.
Networking	Proven honestly: an in-process test server accepts one connection, withholds all responses until three client streams are open at once (a single-stream client would deadlock), then replies in reverse order with interleaved data - only a true multiplexer returns every body to the right stream. A live test fetches six resources from one real HTTP/2 host concurrently, all 200, including two multi-megabyte responses. Whole conformance suite unchanged. Research dossier docs/next-floors-research.md.