Packet Loss Recovery: TCP vs QUIC

Loss Recovery: TCP vs QUIC

Packet loss is inevitable on the internet. How a transport protocol recovers from loss directly impacts user-perceived performance, especially on mobile and Wi-Fi networks where 1-5% packet loss is common.

TCP Loss Recovery (HTTP/1.1 and HTTP/2)

TCP uses a single byte stream with strict ordering. When a packet is lost:

1. The receiver detects a gap in sequence numbers
2. It sends duplicate ACKs to signal the loss
3. The sender retransmits the lost packet
4. All subsequent data is buffered until the lost packet arrives
5. Once received, the entire buffer is delivered to the application

This means a single lost packet can stall all HTTP/2 streams, even those whose data was not in the lost packet. This is TCP-level head-of-line blocking.

QUIC Loss Recovery (HTTP/3)

QUIC uses per-stream ordering. Each stream maintains its own delivery state:

1. The receiver detects a gap in a specific stream
2. Only that stream is paused
3. Other streams continue receiving and delivering data
4. When the lost packet is retransmitted, only the affected stream resumes

5% packet loss scenario (loading a page with 10 resources):

TCP/HTTP/2:  All 10 resources stall on each loss event
QUIC/HTTP/3: Only 1 resource stalls, other 9 continue loading

Impact on Real-World Performance

Studies by Google and Cloudflare have shown that HTTP/3 provides the most significant improvements on high-latency, lossy connections:

• < 0.1% loss: HTTP/2 and HTTP/3 perform similarly
• 1% loss: HTTP/3 is 5-15% faster in page load time
• 5% loss: HTTP/3 can be 30-50% faster than HTTP/2

This makes HTTP/3 especially valuable for mobile users in developing regions where network quality varies significantly.