v158 · network · webtransport
WebTransport anticipated concurrent incoming streams
A WebTransport client opens with a QUIC stream allowance — a budget of how many streams the server may have in flight at once. If the server needs more concurrency than that initial budget, it waits for credit, one round trip at a time. Chrome 158 adds anticipatedConcurrentIncomingUnidirectionalStreams and anticipatedConcurrentIncomingBidirectionalStreams — as constructor options and as read-write attributes — so an application that knows its server will fan out hundreds of streams can say so up front.
concepts
-
Does this build read the hint?
Hand the constructor an options bag whose members are getters that throw, and the two new dictionary members announce whether this build reads them — with control rows that make the answer trustworthy. Then read the prototype for the attribute half.
-
Allowance tuner
Choose a unidirectional and a bidirectional hint, construct a real
WebTransportwith them, and read back what the object actually stored — then raise the hint on the live object through the read-write attributes. -
The edges: EnforceRange, null, and the floor of 100
Both members are
[EnforceRange] unsigned short?. Feed the constructor 0, 100, 65535, 65536, −1, andnull, and record which values are stored, which throw a realTypeError, and what an older build silently ignores.
why it shipped
The WebTransport spec requires a client to initially allow at least 100 concurrent server-initiated streams of each type. That is plenty for request/response patterns, but some applications — pub/sub fan-out, one stream per tracked object, media with many concurrent tracks — expect the server to hold far more streams open at once. Before this feature the server would hit the initial allowance and stall until the client granted more credit via MAX_STREAMS, adding avoidable latency exactly when the application was busiest.
The hints let the application declare its expected concurrency when the connection is created, so the browser can advertise an appropriate initial allowance in the QUIC transport parameters. Values above the required minimum are preserved; values below 100 do not reduce the effective allowance, because the spec's floor still applies. The same names exist as read-write attributes so an application whose needs grow mid-session can raise the hint on the live connection.
the API
const transport = new WebTransport("https://example.com:4433/feed", {
// "I expect the server to have ~400 unidirectional streams in flight."
anticipatedConcurrentIncomingUnidirectionalStreams: 400,
anticipatedConcurrentIncomingBidirectionalStreams: 50,
});
// The same names are read-write attributes on the instance,
// so the hint can be raised later:
transport.anticipatedConcurrentIncomingUnidirectionalStreams = 800;
Both members are [EnforceRange] unsigned short?: integers 0–65535, null to leave the hint unset, and a real TypeError for anything outside the range. The hint is advisory — the browser stays free to advertise more, and never less than the spec's floor of 100.
research notes — use-case portfolio
Angles built: basic/canonical (hint-probe — is the exact dictionary member read by this build), configuration/inspection tool (allowance-tuner — real construction plus attribute readback and mid-object update), and edge/failure (range-and-null — EnforceRange boundaries, nullability, the spec floor). A practical live-traffic angle (watching a server actually get blocked on stream credit and then not blocked once the hint is set) and a novel composition both require a live HTTP/3 WebTransport endpoint; this showcase's Deno Deploy host terminates HTTP/1.1/2 only and cannot accept a WebTransport CONNECT, so those angles are recorded as not applicable here rather than simulated as fake successes. The exact surface demonstrated is the one the spec names: WebTransportOptions.anticipatedConcurrentIncomingUnidirectionalStreams / …BidirectionalStreams and the same-named attributes on WebTransport, runtime flag WebTransportAnticipatedConcurrentIncomingStreams.