Learn the vocabulary of a UDP-based transport protocol that avoids TCP's head-of-line blocking.
0 / 5 completed
1 / 5
At standup, a dev mentions a transport protocol built on UDP that eliminates head-of-line blocking between independent streams, unlike the TCP connection HTTP/2 runs on top of. What protocol is being described?
QUIC, the transport protocol underlying HTTP/3, is built on UDP and eliminates head-of-line blocking between independent streams, unlike the single TCP connection HTTP/2 multiplexes its streams over. TCP itself is exactly what causes that head-of-line blocking, since a single lost TCP packet stalls every stream sharing that connection until it's retransmitted. This UDP-based, stream-independent design is the core reason QUIC was created as HTTP/3's new transport layer.
2 / 5
During a design review, the team wants a lost packet affecting one HTTP/3 stream to stall only that stream, rather than blocking every other concurrently multiplexed stream sharing the same connection. Which capability supports this?
QUIC's per-stream loss recovery means a lost packet affecting one HTTP/3 stream stalls only that stream, rather than blocking every other concurrently multiplexed stream sharing the same connection. Multiplexing every stream over a single TCP connection means one lost packet blocks all of them until it's retransmitted, regardless of which stream it actually belonged to. This per-stream independence is exactly the head-of-line blocking problem QUIC was designed to solve compared to HTTP/2 over TCP.
3 / 5
In a code review, a dev notices a client can resume an existing QUIC connection to a familiar server using a cached connection identifier, skipping much of the handshake that a brand-new connection would otherwise require. What does this represent?
Connection migration and 0-RTT resumption let a client resume an existing QUIC connection to a familiar server using a cached connection identifier, skipping much of the handshake a brand-new connection would otherwise require. Requiring a full handshake from scratch every single time adds unnecessary round-trip latency for a client that's already established a connection to that server recently. This resumption capability is one of QUIC's notable latency advantages over establishing a fresh TCP and TLS handshake each time.
4 / 5
An incident report shows mobile users on a spotty cellular connection experienced far more stalled page loads than users on a stable connection, because the site still served HTTP/2 over TCP, where a single lost packet blocked every multiplexed stream at once. What practice would prevent this?
Serving the site over HTTP/3 with QUIC means a lost packet only stalls the one stream it actually affects, rather than blocking every multiplexed stream the way a single lost TCP packet does under HTTP/2. Continuing to serve only HTTP/2 over TCP is exactly what caused the disproportionate stalling for mobile users on a lossy connection in this incident. Offering HTTP/3 is a standard mitigation for improving performance on a network prone to packet loss, like many cellular connections.
5 / 5
During a PR review, a teammate asks why the team adopts HTTP/3 over QUIC instead of continuing to rely on HTTP/2 multiplexed over a single TCP connection. What is the reasoning?
TCP's single connection means one lost packet blocks every multiplexed stream sharing it, which can noticeably hurt performance on a lossy network like many mobile connections. QUIC's per-stream independence lets a lost packet stall only the affected stream, keeping every other stream flowing normally. The tradeoff is the added complexity of adopting a comparatively newer, UDP-based transport protocol, including ensuring it's properly supported across a client's full network path.