How Safari Uses HTTP/3 and QUIC to Reduce Cellular Latency

This article provides an overview of how the Safari web browser utilizes the HTTP/3 and QUIC protocols to significantly reduce connection latency on unstable, high-packet-loss cellular networks. By shifting away from traditional TCP connections in favor of a modern UDP-based transport layer, Safari eliminates head-of-line blocking, shortens cryptographic handshakes, and enables seamless network switching. These advancements directly translate to faster page loads and a more resilient browsing experience when cellular signals are weak.

The Shift from TCP to UDP

To understand how Safari reduces latency, it is necessary to look at the underlying transport protocols. Older web standards, such as HTTP/1.1 and HTTP/2, rely on the Transmission Control Protocol (TCP). TCP is designed for reliability and strict ordering, requiring constant back-and-forth verification between the browser and the server. On a cellular network with high packet loss, this strictness creates severe bottlenecks.

HTTP/3 abandons TCP entirely. Instead, it runs on QUIC (Quick UDP Internet Connections), a transport layer protocol built on top of the User Datagram Protocol (UDP). By default, UDP "fires and forgets" data packets without waiting for confirmation. QUIC takes the raw speed of UDP and builds its own lighter, faster reliability and security mechanisms directly into the protocol.

Eliminating Head-of-Line Blocking

The primary cause of latency on high-packet-loss cellular networks is a phenomenon known as Head-of-Line (HoL) blocking.

When loading a webpage, Safari requests multiple files simultaneously—such as HTML, CSS, JavaScript, and images. Under HTTP/2, these files are sent as multiple streams over a single TCP connection. However, TCP views all these streams as one single sequence of bytes. If a single packet of data is lost due to a poor cellular signal, TCP halts the entire connection. None of the already-received data can be processed by Safari until that one missing packet is retransmitted and received.

QUIC solves this by managing streams independently at the transport layer. When Safari uses HTTP/3 over QUIC, each file is assigned its own distinct stream. If a packet containing an image is lost on a spotty cellular connection, QUIC only pauses the stream for that specific image. The HTML, CSS, and JavaScript streams continue to load and render on the screen without waiting.

Faster Handshakes with 0-RTT

Establishing a secure connection over a cellular network inherently involves high latency because signals must travel between the mobile device, cell towers, and the target server.

With TCP, the browser must first complete a three-way handshake to establish the connection, followed by a separate TLS handshake to secure and encrypt it. This requires multiple round-trip times (RTT) before Safari can even ask for the webpage data. If a packet drops during this setup phase, the delay multiplies.

QUIC combines the transport and cryptographic (TLS 1.3) handshakes into a single step.

1-RTT (First Visit): When connecting to a new server, Safari establishes a secure QUIC connection in just one round trip.
0-RTT (Repeat Visits): If a user visits a website they have connected to previously, Safari can use Zero Round-Trip Time (0-RTT) resumption. The browser sends the actual webpage request in the very first packet, along with the encryption keys, eliminating handshake latency entirely.

Seamless Connection Migration

Mobile users are constantly in motion, which causes their devices to switch between different cell towers or transition from Wi-Fi to cellular data.

TCP connections are defined by a four-part identifier: the source IP, source port, destination IP, and destination port. When a user's cellular network shifts and their device is assigned a new IP address, the existing TCP connection breaks. Safari is forced to tear down the connection and start a new handshake from scratch, causing a massive latency spike.

QUIC bypasses this issue using "Connection IDs." When Safari initiates an HTTP/3 session, a unique Connection ID is generated that remains independent of the user's IP address or network interface. If the user loses Wi-Fi and drops onto a lossy 4G network, Safari simply continues sending packets with the same Connection ID. The server recognizes the ID and continues the session seamlessly, requiring no reconnection or re-authentication.

Enhanced Packet Loss Recovery

Cellular networks experience erratic fluctuations in bandwidth and signal quality. In TCP, when a packet is lost and then retransmitted, the protocol struggles to distinguish whether an acknowledgment (ACK) from the server is for the original packet or the retransmitted one. This "retransmission ambiguity" leads to inaccurate latency calculations and inefficient data throttling.

Safari’s QUIC implementation assigns a new, unique packet number to every single transmission, even if it is carrying retransmitted data. This gives the browser precise measurements of the cellular network's current round-trip time. Furthermore, QUIC supports many more ACK ranges than TCP, allowing Safari to quickly inform the server exactly which packets survived a burst of cellular interference and which ones need to be resent.