In legacy TCP-based protocols (such as raw WebSockets or HTTP/2), all application data flows through a single sequential byte stream. If a single TCP packet is dropped in the network, the operating system kernel TCP stack pauses delivery of ALL subsequent packets to the application until the missing packet is retransmitted and acknowledged. In time-critical applications like cloud gaming, competitive multiplayer tick sync, spatial audio, and live sensor telemetry, old data is completely worthless—waiting 100ms for a retransmitted coordinate stalls fresh position updates. RFC 9297 specifies HTTP Datagrams over QUIC/UDP. Datagrams are out-of-order, unreliable, and message-oriented. If packet #3 drops, packets #4 and #5 are delivered to the browser runtime IMMEDIATELY with zero stall, eliminating Head-of-Line blocking entirely.

WebSockets operate over TCP with TLS, providing single-stream, strictly reliable, ordered delivery, but suffer from Head-of-Line blocking and cannot send unreliable messages. WebRTC DataChannels (RTCDataChannel) operate over UDP using SCTP encapsulated in DTLS, supporting unreliable and out-of-order delivery. However, WebRTC requires complex Session Description Protocol (SDP) offer/answer negotiation, Interactive Connectivity Establishment (ICE), STUN NAT traversal, and expensive TURN relay servers, making client-server multiplexing complex and resource-heavy. WebTransport combines the simplicity of client-server HTTP architectures with the power of QUIC. Over a single TLS 1.3 / QUIC UDP connection negotiated via HTTP/3 CONNECT, WebTransport provides: (1) Unreliable Datagrams (via transport.datagrams), (2) Independent Unidirectional Streams, and (3) Bidirectional Streams, with unified QUIC congestion control (BBRv2 / CUBIC) and zero-RTT session resumption.

RFC 9297 introduces the Capsule Protocol to allow datagrams and metadata to be multiplexed inside an HTTP CONNECT stream. When an HTTP/3 client initiates a WebTransport session, it sends: CONNECT /webtransport-endpoint HTTP/3 with :protocol=webtransport and capsule-protocol=?1. Inside this stream, datagrams can be framed using QUIC DATAGRAM frames (frame type 0x30 or 0x31) with a Quarter Stream ID. The Quarter Stream ID (varint) identifies which WebTransport session or stream context the datagram belongs to, enabling the server to demultiplex thousands of concurrent client datagram flows across a single UDP 4-tuple.

Even though WebTransport datagrams are unreliable (the sender does not retransmit them upon loss), they are still strictly bounded by QUIC Congestion Control (BBRv2, CUBIC, or NewReno). Every datagram consumes congestion window (CWND) bandwidth. If the network becomes congested and packets drop, the QUIC sender throttles the transmission rate. Furthermore, WebTransport datagrams can be dropped client-side if the local send queue exceeds maxDatagramSize or high-water marks, preventing bufferbloat inside client memory.