Reducing HTTP Latency with QUIC

Problem Statement

Page Load Time (PLT) is a critical metric for user experience and conversion rates. However, PLT depends on three factors:

• Bandwidth — Available bitrate (Mbps)
• Latency — Round-trip time (RTT, milliseconds)
• Protocol Efficiency — How well the protocol utilizes available bandwidth

While bandwidth and latency are properties of the network path, the protocol layer presents a significant opportunity for optimization. Traditional HTTP/1.1 has inherent inefficiencies (connection establishment overhead, head-of-line blocking) that impact PLT, especially on high-latency or lossy networks.

HTTP Protocol Evolution

• HTTP/1.0 — Single request per connection (connection-close model)
• HTTP/1.1 — Persistent connections, pipelining (limited adoption due to head-of-line blocking)
• HTTP/2.0 — Multiplexing over single connection, header compression, server push
• HTTP/3.0 — Built on QUIC (UDP-based), 0-RTT resumption, improved loss recovery

Experimental Setup

Testbed Configuration:

• HTTP server: Apache/2.4.10 with TLS 1.2
• SPDY server: nghttp2 with TLS 1.2 (nghttp2 supports SPDY 4, which is Google's implementation of HTTP/2.0)
• QUIC server: version 24 server in the Chromium code base with QUIC-Crypto
• Netshaper: sets channel capacity and propagation delays

Real experiments were run using the open-source browser Chromium. An example of testbed usage is available on GitHub.

Testbed settings: Buffer sizes: Q = BDP • Base RTT: 50ms • Bottleneck Capacity: 3 Mbps • Loss free channel. The web page used to compare HTTP/1.1, HTTP/2.0 (SPDY), and QUIC contains only JPEG images, without any JavaScript code or CSS file.

Protocol Comparison Charts

Experiment with HTTP/1.1 — Page Load time: 2.03s

• Six TCP connections are opened (each requires a TCP and TLS handshake)
• One resource at a time is transferred over each connection

Experiment with HTTP/2.0 — Page Load time: 1.45s

• One TCP connection is opened. All requests are sent when the DOM is loaded
• Resources are multiplexed and sent simultaneously over a single TCP connection

Experiment with QUIC — Page Load time: 1.14s

• One UDP connection
• No handshake required

Experimental Results

QUIC reduces the overall page retrieval time with respect to HTTP in the case of a channel without induced random losses, and outperforms HTTP/2.0 in the case of a lossy channel.

Detailed Analysis

Gaetano Carlucci, Luca De Cicco, Saverio Mascolo — HTTP over UDP: an experimental investigation of QUIC — Proc. of 30th ACM/SIGAPP SAC 2015, Salamanca, Spain, April 2015

Key Performance Insights

• Connection Overhead Matters — HTTP/1.1's 6 parallel connections add significant latency on high-RTT networks (satellite, intercontinental)
• Multiplexing Benefits — Consolidating to single connection saves setup overhead but doesn't solve head-of-line blocking at transport layer
• Loss Recovery — QUIC's stream-level recovery eliminates transport-layer head-of-line blocking, critical on lossy networks (mobile, WiFi)
• Handshake Amortization — QUIC's 0-RTT resumption provides the largest benefit for repeat visits (potential 1-RTT saving)

Reference

Detailed experimental results published in:

G. Carlucci, L. De Cicco, S. Mascolo — HTTP over UDP: an experimental investigation of QUIC — ACM SIGAPP SAC 2015 (also available as PDF)

Testbed and Reproduction

To reproduce these experiments, use the WAN emulation and NetEM configuration tools provided here:

• GitHub: WAN Emulation with TC and NetEM