Beyond QUIC Streams: Low-Latency Tunnels Over HTTP/3 Datagrams and MASQUE

QUIC (RFC 9000, May 2021) and HTTP/3 (RFC 9114, June 2022) changed how web traffic moves. Streams on a QUIC connection are independent, so a lost packet on one stream no longer stalls the others, which was the classic TCP head-of-line (HoL) blocking problem. QUIC also supports connection migration, so a connection can survive a switch between networks such as Wi-Fi and cellular.

Streams still have a constraint: reliability. Every byte on a QUIC stream is delivered, in order, or the stream fails. That is what you want for page loads and API calls. It is a poor fit for data that goes stale quickly, such as live telemetry, voice, or game state, where a late packet can be worse than a missing one.

QUIC and HTTP/3 now have a standardized answer: unreliable datagrams (RFC 9221), exposed to HTTP through HTTP Datagrams (RFC 9297) and used by the MASQUE family of proxying protocols (RFC 9298 for UDP, RFC 9484 for IP). This article explains how the pieces fit together, where they work today, and where the limits are.

1. Why Reliable Streams Can Hurt Real-Time Data

When a packet carrying stream data is lost, QUIC retransmits the missing data. It holds back delivery of that stream’s later bytes until the gap is filled, to preserve ordering. Other streams on the connection keep flowing.

For most traffic this is correct. For real-time data it can cost you. Take a hypothetical sensor feed sending a reading every 5 ms, or a game server sending player positions 60 times a second. If one packet is lost and the retransmission arrives tens of milliseconds later, newer readings have already arrived but sit behind the gap. The application sees a stall followed by a burst of outdated state. Tail latency (p99) and jitter rise, and the late data is of little use.

[ Reliable QUIC stream ]
Packet 1 -> Packet 2 (lost) -> Packet 3 (held until 2 is retransmitted) -> Packet 2' -> Packet 3 released
                                      └── later data waits behind the gap

[ QUIC DATAGRAMs ]
Frame 1 -> Frame 2 (lost, not retransmitted) -> Frame 3 (delivered immediately)
                                      └── the application decides what a gap means

Datagrams let the application skip this ordering and recovery. They do not make the network faster. They let the application accept loss instead of waiting for repair.

2. The Standards Stack

QUIC DATAGRAM frames (RFC 9221, March 2022)

RFC 9221 adds two QUIC frame types, 0x30 and 0x31, that carry application data without retransmission. Support is negotiated with the max_datagram_frame_size transport parameter (0x20). The RFC recommends advertising 65535 for most uses, which means the endpoint accepts any DATAGRAM frame that fits in a QUIC packet.

Some details are often misdescribed:

• Not retransmitted, but still acknowledged. DATAGRAM frames are ack-eliciting, so they take part in loss detection and congestion control. If one is lost, QUIC does not resend it.
• Subject to congestion control. RFC 9221 lists this as an intentional design point. Reliable and unreliable data share one congestion controller, so datagrams cannot flood a path.
• Not flow-controlled. A receiver under memory pressure may drop datagrams.
• Not tied to a stream at the QUIC layer. They belong to the connection as a whole.

HTTP Datagrams and the Capsule Protocol (RFC 9297, August 2022)

RFC 9297 defines how HTTP uses datagrams. On HTTP/3, each endpoint advertises the SETTINGS_H3_DATAGRAM setting (identifier 0x33). Each datagram begins with a Quarter Stream ID: the ID of the associated client-initiated bidirectional request stream, divided by four. That is how many independent datagram flows share one connection.

RFC 9297 also defines the Capsule Protocol. It carries the same HTTP Datagrams reliably inside a request stream, for transports that lack QUIC DATAGRAM frames, such as HTTP/2 and HTTP/1.1. The RFC states that HTTP Datagrams and the Capsule Protocol are meant for use by HTTP extensions rather than directly by applications.

3. MASQUE: Proxying UDP, and IP, Over HTTP

MASQUE (Multiplexed Application Substrate over QUIC Encryption) is the IETF working group name for proxying other traffic through HTTP. Two published standards matter here:

• CONNECT-UDP, RFC 9298 (August 2022). Proxies UDP through an HTTP server, as HTTP CONNECT does for TCP.
• CONNECT-IP, RFC 9484 (October 2023). Proxies full IP packets. It updates RFC 9298 and works similarly.

Two corrections to common descriptions:

• CONNECT-UDP is not an HTTP method. On HTTP/2 and HTTP/3, RFC 9298 uses Extended CONNECT with the connect-udp token as the :protocol pseudo-header. On HTTP/1.1 it uses the Upgrade mechanism.
• There is no masque URI scheme. The request uses https. The proxy is identified by a URI Template, with a default of https://$PROXY_HOST:$PROXY_PORT/.well-known/masque/udp/{target_host}/{target_port}/.

Inside the tunnel, each HTTP Datagram begins with a Context ID, and Context ID 0 carries raw UDP payloads. RFC 9298 also has sections on performance and MTU considerations, which matter for the engineering notes below.

Fallback is part of the design

Because RFC 9298 supports all HTTP versions through HTTP Datagrams and capsules, a client can fall back to HTTP/2 or HTTP/1.1 when UDP is blocked. The tunnel still works, but datagrams travel inside a reliable TCP stream. You get connectivity and lose the loss-tolerance that motivated the design, and head-of-line blocking returns.

What is still a draft

The CONNECT-UDP Bind draft (draft-ietf-masque-connect-udp-listen, revision 16 in August 2026) extends RFC 9298. Standard CONNECT-UDP sends to one target host and port per request. The draft lets a client send and receive UDP payloads to multiple hosts within one request, with the proxy returning a Connect-UDP-Bind header to confirm support. The draft states a WebRTC-style goal, enabling connectivity between peers. It is still an Internet-Draft, so do not build production dependencies on its details.

4. How the Options Compare

	Raw UDP	WebSockets	HTTP/3 Datagrams via MASQUE
Transport	UDP	TCP (usually with TLS)	QUIC over UDP
Reliability	None	Reliable, ordered	Datagrams: unreliable. Streams on the same connection: reliable
Head-of-line blocking	None	Yes (TCP)	None for datagrams
Congestion control	Application’s responsibility	TCP	QUIC’s, applied to datagrams as well
Typical network path	Custom ports often filtered	Port 443, widely allowed	UDP/443, allowed on many networks but blocked on some
Fallback	None	n/a	HTTP/2 or HTTP/1.1 with capsules (reliable)

A caveat on firewall traversal: MASQUE traffic is encrypted QUIC on UDP port 443, which many networks permit. Networks that block or throttle UDP/443 will block it too, and encryption does not make it invisible to a network that chooses to classify or block QUIC.

5. Who Already Runs This

MASQUE is deployed in production:

• Apple iCloud Private Relay uses MASQUE. Apple’s documentation describes QUIC connections to relays over port 443 with TLS 1.3. CONNECT and CONNECT-UDP over HTTP/3 let multiple TCP and UDP flows share a single QUIC connection. Private Relay uses two relay hops: the first sees the client’s IP address but not the destination, and the second sees the destination but not the client’s address.
• Cloudflare offers a Privacy Proxy product built on MASQUE that proxies TCP and UDP through HTTP CONNECT and CONNECT-UDP over HTTP/2 and HTTP/3. Cloudflare’s documentation says it powers Microsoft Edge Secure Network and acts as a second-hop relay for iCloud Private Relay.

Support in open-source libraries is also growing. For example, an Erlang MASQUE library implementing RFC 9298, with RFC 9484 support added later, was publishing releases through mid-2026. Check each library’s feature coverage before you depend on it.

6. A Protocol Walkthrough

The following describes a CONNECT-UDP session over HTTP/3.

Step 1: Negotiate datagram support. During connection setup, both endpoints must advertise QUIC’s max_datagram_frame_size transport parameter and send the HTTP/3 SETTINGS_H3_DATAGRAM setting with a value of 1.

Step 2: Open the tunnel with Extended CONNECT. The proxy must also have advertised Extended CONNECT support for the request to be valid. A request looks like this:

:method = CONNECT
:protocol = connect-udp
:scheme = https
:authority = proxy.example.org:443
:path = /.well-known/masque/udp/192.0.2.6/443/
capsule-protocol = ?1

Step 3: Receive the response. A 2xx status means the proxy has committed to converting HTTP Datagrams into UDP packets and the reverse. The request stream stays open for the life of the tunnel.

Step 4: Send datagrams. Each UDP payload is sent in a QUIC DATAGRAM frame whose payload starts with the Quarter Stream ID of the request stream, then Context ID 0, then the UDP payload:

[ Client ] ──(1. QUIC + HTTP/3 SETTINGS: datagram support)──> [ MASQUE proxy ]
[ Client ] ──(2. Extended CONNECT, :protocol=connect-udp)───> [ MASQUE proxy ]
[ Client ] <─(3. 2xx response)──────────────────────────────  [ MASQUE proxy ]
[ Client ] ──(4. QUIC DATAGRAMs: Quarter Stream ID + Context ID 0 + UDP payload)──> [ MASQUE proxy ] ──UDP──> Target

When the request stream closes, the tunnel ends.

7. Use Cases, With Caveats

Real-time telemetry

For live feeds, data freshness often matters more than completeness. With datagrams, a lost reading is not retransmitted, so a recovering link does not flush a backlog of stale values into a dashboard. Separate logical flows can share one HTTP/3 connection as separate requests, each with its own Quarter Stream ID. That lets you keep control messages and bulk logs apart from lossy telemetry.

Be precise about what the transport does and does not do:

• Datagrams are not retransmitted, but they are still congestion controlled. If the path is saturated, QUIC will slow sending or queue data. Whether stale datagrams are dropped before being sent depends on your QUIC library’s queue behavior. Design your sender to discard old samples rather than assuming the stack will.
• Sequence numbers and timestamps are your responsibility. Datagrams can be lost, duplicated by the network, or reordered.

Game-server and network testing

A MASQUE tunnel can carry UDP game traffic through a single proxy connection, and you can inject loss at the datagram layer in your test harness to see how client prediction and interpolation cope. Treat it as a complement to existing tools rather than a replacement. A tunnel adds its own overhead, its own congestion control, and a proxy hop, so measured RTT will include those. Linux tc netem and similar emulators remain the standard way to shape and impair traffic at the network level.

“Local tunnels”

CONNECT-UDP is client-initiated and outbound: the client asks a proxy to send UDP to a target. That is not the same as publishing a service on your own machine to the internet, which needs inbound traffic. The Bind extension discussed above points in that direction, but it is a draft. For ingress-style tunneling today, plan on running your own relay and treat inbound behavior as implementation-specific.

8. Engineering Notes

MTU and payload size

QUIC requires endpoints to support UDP payloads of at least 1200 bytes. Larger sizes can be discovered with Path MTU Discovery or Datagram Packetization Layer PMTU Discovery (DPLPMTUD). A tunneled datagram has to fit inside the outer QUIC packet along with the Quarter Stream ID, the Context ID, QUIC packet overhead, and the encryption tag. If you tunnel UDP applications that assume a 1200-byte payload, you can exceed the available space. Measure it, and follow the guidance in RFC 9298’s MTU considerations.

Nested congestion control

QUIC’s congestion control applies to the tunnel. RFC 9002 describes a NewReno-style algorithm, and implementations commonly offer others such as CUBIC or BBR. If the tunneled application is itself congestion controlled (for example, QUIC inside the tunnel), two controllers interact. Test this combination before assuming it behaves well. RFC 9298 has a performance considerations section for this reason.

Mixing streams and datagrams

Both share one congestion window. Heavy datagram bursts can reduce capacity available to streams, and the reverse. Rate-limit your datagram sender, and prioritize control traffic if your library supports it.

Security

A CONNECT-UDP proxy opens UDP sockets to targets chosen by the client, so unrestricted use makes it an open relay. Authenticate clients, restrict permitted targets, and block private address ranges and cloud metadata endpoints unless you intend to reach them. RFC 9298 includes a security considerations section.

9. WebTransport: the Browser Route

If your clients are browsers, the relevant API is WebTransport, which exposes both streams and unreliable datagrams over HTTP/3. Reports from March 2026 say Safari 26.4 shipped WebTransport, bringing it to Baseline status alongside Chrome, Edge, and Firefox.

Some caveats:

• WebTransport is not MASQUE. It is a separate protocol, though it also uses HTTP/3 and QUIC datagrams.
• Browser support is recent. Reports describe uneven implementation details between engines, so test the specific features you need.
• The W3C API and the IETF WebTransport-over-HTTP/3 specification were still being finalized when last checked in 2026 sources. Expect details to shift.
• Server-side support in common runtimes is still developing. Node.js, for example, does not ship built-in WebTransport, so third-party packages are needed.

10. Conclusion

QUIC datagrams give applications a way to opt out of retransmission and ordering while keeping encryption and congestion control. MASQUE builds on them to carry UDP and IP traffic over standard HTTP infrastructure, with fallbacks for networks that block UDP. Apple and Cloudflare run it at scale, and browsers can now use datagrams through WebTransport.

It is not a free speedup. Datagrams trade reliability for timeliness, so your application must handle loss, reordering, and size limits. Tunnels add overhead and interact with congestion control. Specifications such as the Bind extension are still evolving. Measure against your own traffic, and build in the fallback.

References

• RFC 9000: QUIC Transport Protocol
• RFC 9002: QUIC Loss Detection and Congestion Control
• RFC 9114: HTTP/3
• RFC 9221: An Unreliable Datagram Extension to QUIC
• RFC 9297: HTTP Datagrams and the Capsule Protocol
• RFC 9298: Proxying UDP in HTTP
• RFC 9484: Proxying IP in HTTP
• Proxying Bound UDP in HTTP (Internet-Draft)
• Cloudflare Privacy Proxy documentation
• iCloud Private Relay (Wikipedia)
• WebKit Features for Safari 26.4