WebTransport vs. WebSocket: A Real-World Benchmark Under Impaired Networks

In our previous analysis, The State of WebTransport: Great in Browsers, Unusable Behind Reverse Proxies, we examined the infrastructure bottleneck keeping the web on WebSockets. While modern browsers have supported WebTransport for years, reverse proxies and CDNs still struggle with its multi-stream routing model.

This raises a fair engineering question: Is WebTransport actually worth the infrastructure trouble? Does replacing WebSockets with WebTransport deliver measurable gains for real-world applications, or is it an incremental theoretical upgrade?

To answer this with hard data, we conducted a rigorous, deterministic benchmark comparing WebTransport (over HTTP/3 and QUIC) against traditional WebSockets (over TCP and TLS) inside Lupyd's open-source messaging engine, Firefly.

We simulated a production-scale workload of 500 members with 3 devices each (1,500 concurrent live endpoints) communicating over simulated cellular networks subjected to 30ms round-trip latency, ±5ms jitter, and 1.0% stochastic packet loss. The results were stark: WebTransport reduced p99 tail latency from 258.74 ms down to 51.23 ms (an 80.2% drop, or 5.05× faster) while slashing peak CPU utilization by 85.1%.

Is WebTransport Worth the Infrastructure Trouble?

When networking benchmarks are run on local loopback (127.0.0.1) with zero packet loss and sub-millisecond ping, WebSockets look deceptively fast. In an idealized lab environment, TCP performs well: operating systems buffer packets smoothly, and serialization overhead is low.

In the real world, web clients rarely operate on local loopback. Mobile devices connect over LTE and 5G cellular towers with fluctuating signal strength, subway tunnels, congested public Wi-Fi, and cross-region transit links. On these links:

• Packet loss rates of 0.5% to 2.0% are normal occurrences.
• Round-trip latencies fluctuate between 20ms and 60ms depending on radio conditions.
• Real-time applications multiplex high-frequency micro-RPCs (key exchanges, read receipts, delivery acknowledgments) alongside continuous message traffic.

Under these conditions, TCP's core guarantee (strictly ordered, reliable byte delivery) becomes its main liability. A single lost IP packet halts delivery of all subsequent data on that socket until the missing segment is retransmitted.

Benchmark Topology: 1,500 Endpoints & Linux Traffic Control

To evaluate how both protocols behave under realistic conditions without external internet noise, we isolated our benchmark inside a reproducible Docker environment using Linux Traffic Control (tc netem).

# Simulating real-world cellular carrier network impairment on Linux
# 30ms base round-trip delay, ±5ms normal jitter, 1.0% stochastic packet drop rate
tc qdisc add dev eth0 root netem limit 50000 delay 30ms 5ms loss 1%

Workload Characteristics

• Active Endpoints: 1,500 simultaneous persistent connections (500 users with phone, desktop, and web clients).
• Duration: 300 continuous seconds (5 minutes) per transport protocol.
• Traffic Cadence: Continuous 10ms message generation loop (~90 messages/second, ~27,000 messages total per run).
• Payload Sizes: Varied pseudo-random payloads (128B, 256B, 512B, 1024B) generated via ChaCha8Rng (seed 42) ensuring identical traffic between WebSocket and WebTransport runs.

Head-to-Head Results: 30ms Latency and 1% Packet Loss

Here is the complete telemetry recorded during the 5-minute impaired network benchmark run:

The Anatomy of the Collapse: Why WebSocket Fails Under Loss

Notice what happened at p50, p90, and p95 versus p99:

• At the 50th percentile (median), WebSocket and WebTransport performed almost identically (~33.2ms vs ~33.5ms). When packets are not dropped, both protocols deliver data within the 30ms network delay.
• Even at p90 and p95, latency remained tightly bounded around 37ms to 38ms.
• At p99, WebSocket latency collapsed catastrophically to 258.74 ms, with individual outliers reaching 535.96 ms.

This explains why a 1% packet loss rate is so devastating to WebSockets. In an application like Firefly that multiplexes dozens of concurrent micro-RPCs (pre-keys, MLS commits, delivery ACKs) over a single TCP socket, dropping one packet out of a hundred freezes the entire pipeline for every concurrent request on that wire.

How WebTransport Preserves Sub-55ms Tail Latency

WebTransport achieves an 80.2% reduction in tail latency because Firefly maps each RPC to a dedicated bidirectional stream via session.open_bi():

// Inside firefly-client/src/websocket.rs: WebTransport dedicated bidirectional RPC stream
// Dedicated stream per RPC: Zero head-of-line blocking across concurrent requests

pub async fn request_webtransport(
    &self,
    method: &str,
    payload: Vec<u8>,
) -> Result<Vec<u8>, FireflyError> {
    let session = self.get_webtransport_session()?;
    
    // 1. Open a fresh bidirectional stream over the established QUIC connection
    let (mut send, mut recv) = session.open_bi().await
        .map_err(|e| FireflyError::Transport(format!("open_bi failed: {e}")))?;

    // 2. Frame and transmit the protobuf ClientMessage
    let client_msg = ClientMessage {
        request: Some(Request { method: method.to_string(), payload }),
        ..Default::default()
    };
    let mut encoded = Vec::new();
    client_msg.encode_length_delimited(&mut encoded)?;
    send.write_all(&encoded).await?;
    send.finish().await?; // Signals clean EOF for the request stream

    // 3. Receive the direct response on the same isolated stream
    let response_bytes = recv.read_to_end(MAX_RPC_PAYLOAD_SIZE).await?;
    let server_msg = ServerMessage::decode_length_delimited(&response_bytes[..])?;
    
    Ok(server_msg.into_response()?)
}

Compare this with the legacy WebSocket implementation:

// Legacy WebSocket: Multiplexed over a single TCP stream with request IDs
// If any single TCP packet drops, ALL in-flight requests in pending_requests stall!

pub async fn request_websocket(
    &self,
    method: &str,
    payload: Vec<u8>,
) -> Result<Vec<u8>, FireflyError> {
    let request_id = self.next_request_id.fetch_add(1, Ordering::Relaxed);
    let (tx, rx) = oneshot::channel();
    
    // Register waiter in client-side pending table
    self.pending_requests.lock().await.insert(request_id, tx);
    
    // Write into the shared TCP socket stream
    let msg = ClientMessage {
        request_id,
        request: Some(Request { method: method.to_string(), payload }),
        ..Default::default()
    };
    self.ws_write_queue.send(msg).await?;
    
    // Wait for the server's response to be demultiplexed from the single TCP stream
    rx.await.map_err(|_| FireflyError::Timeout)
}

Under WebTransport, when packet loss occurs on the UDP link:

1. The QUIC engine (Quinn in Firefly) detects the missing datagram and schedules a retransmission specifically for that stream ID.
2. All other active bidirectional and unidirectional streams continue to read and write bytes without waiting.
3. The application layer does not maintain complex pending-request sequence maps or lock-guarded in-memory write queues.
4. At p99, latency stays at 51.23 ms, only ~13ms above the network jitter floor.

Baseline Local vs. Impaired Network Comparison

To isolate the exact impact of network impairment, compare our baseline local benchmark (<0.1ms ping, 0% loss) against the impaired benchmark (30ms ping, 1% loss):

Even on local loopback with zero packet loss, WebTransport was already 58.7% faster at p99 (4.52ms vs 10.95ms) and reduced client peak CPU by 85.1% (from 30.29% down to 4.51%). Under realistic mobile network conditions, that performance gap expands into a full order-of-magnitude difference in tail predictability.

The Trade-Offs: Memory, Bandwidth, and Framing Overhead

WebTransport is not free. Engineering requires honest accounting of costs, and the benchmark revealed two concrete trade-offs:

For our encrypted messaging platform, paying a ~35% memory premium and extra wire bytes is an easy trade-off when it eliminates 500ms freezes and drops p99 tail latency by 80%.

Firefly's Dual-Transport Implementation in Rust

A key design goal when introducing WebTransport into Firefly was zero breaking changes for existing applications and FFI consumers:

Connecting the Dots: Why Proxy Support Matters More Than Ever

These benchmark findings make the reverse proxy bottleneck described in our proxy analysis all the more urgent:

1. The performance win is proven: WebTransport is not an incremental protocol tweak. Under cellular packet loss, it completely eliminates TCP head-of-line blocking stalls and keeps tail latency under 55ms.
2. The client and backend code is ready: Libraries like wtransport, webtransport-go, and Firefly prove that dual-transport architectures with automatic fallback can ship today with zero breaking API changes.
3. The bottleneck is purely the proxy layer: As long as Nginx, HAProxy, and Cloudflare CDN refuse to route WebTransport sessions to origin pools, production architectures are forced to stay on WebSockets or expose origin IP addresses to direct UDP floods.

WebTransport is ready, proven, and waiting. The ball is squarely in the court of reverse proxy maintainers and CDN providers.

Frequently Asked Questions