Network Protocols — Series 2

Preview — 3 of 10 questions

HTTP/3 doesn't run over TCP like HTTP/1.1 and HTTP/2 — it runs over QUIC, which itself sits on top of UDP. Why was this change made, and what problem does it solve?

AHTTP/3 was switched to UDP purely to reduce server costs, with no effect on client-side performance

BUDP is inherently faster than TCP in every situation because it doesn't use IP addresses

CTCP guarantees in-order delivery of the entire byte stream, so a single lost packet blocks delivery of everything after it, even unrelated HTTP/2 streams multiplexed on that one connection — a problem known as head-of-line blocking at the transport layer. QUIC (built on UDP) implements its own reliability and multiplexing where each stream's lost packets only block that stream, not the others sharing the connection, and it also folds the TLS handshake into the same initial handshake instead of doing them separately

DHTTP/3 removed the need for encryption entirely, which is the source of its speed improvement

Why does HTTP organize status codes into ranges (1xx, 2xx, 3xx, 4xx, 5xx) rather than using a single flat list of arbitrary numbers?

AThe ranges are purely historical and carry no semantic meaning that clients are expected to understand

BStatus code ranges only apply to responses larger than 1MB

CThe digit ranges exist exclusively to make status codes easier for humans to memorize, with no effect on client software behavior

DThe leading digit conveys a general category that any client can react to even without recognizing the exact code: 2xx means success, 3xx means further action/redirection is needed, 4xx means the client made an error (bad request, unauthorized, not found), and 5xx means the server failed to fulfill an apparently valid request. This lets clients apply sensible default behavior for status codes they don't specifically recognize, just based on the category digit

Before HTTP persistent connections (keep-alive) became standard, each HTTP request opened a brand-new TCP connection, and closed it once the response was received. Why was this expensive, and what does keep-alive fix?

AKeep-alive means the server keeps sending the same response repeatedly, "alive," until the client explicitly stops it

BOpening a new TCP connection requires a handshake (and, for HTTPS, a separate TLS handshake) before any actual data can be exchanged — repeating that setup cost for every single request (e.g., for a page with 50 assets) adds significant cumulative latency. Keep-alive lets a single, already-established TCP connection be reused for multiple sequential requests/responses, paying the connection setup cost only once instead of once per request

CKeep-alive is a feature that only applies to WebSocket connections, not to standard HTTP requests

DKeep-alive connections are automatically closed and reopened after exactly one request, providing no benefit over the old behavior

Answer all 10 questions (7 more), see explanations for every answer, and track your score.