Networking Protocols
TCP vs UDP, the HTTP request/response structure and its versions, and QUIC over HTTP/3.
3 questions
JuniorTheoryVery commonWhat parts make up an HTTP request and response?
What parts make up an HTTP request and response?
HTTP is a text-based request/response protocol. A request is a start line (method, resource path, protocol version), then headers, then an optional body. A response is the same shape but its start line carries a status code instead of a method and path. Status codes group by class — 1xx informational, 2xx success, 3xx redirect, 4xx client error, 5xx server error.
Common mistakes
- ✗Putting a status code in the request start line
- ✗Forgetting the body is optional and headers are key-value lines
- ✗Mixing up the status-code classes (2xx vs 4xx vs 5xx)
Follow-up questions
- →Why is static content often served from a separate cookie-less domain?
- →What is the difference between a 4xx and a 5xx status in practice?
JuniorTheoryCommonHow do TCP and UDP differ, and when would you pick UDP?
How do TCP and UDP differ, and when would you pick UDP?
TCP is connection-oriented and reliable: it sets up a connection, acknowledges data, and delivers bytes in order, which makes it slower. UDP is connectionless and sends independent datagrams that may be lost, duplicated, or reordered, but it is faster because it skips acknowledgements and supports broadcast. UDP fits streaming audio/video, online games, and DNS, where speed beats guaranteed delivery.
Common mistakes
- ✗Swapping which protocol is connection-oriented and reliable
- ✗Claiming UDP guarantees ordering or delivery
- ✗Thinking the choice is about encryption rather than reliability versus speed
Follow-up questions
- →What syscalls set up a TCP server and client socket lifecycle?
- →How does QUIC get reliability while running on top of UDP?
MiddleTheoryRareWhat is QUIC, and how does HTTP/3 build on it?
What is QUIC, and how does HTTP/3 build on it?
QUIC is a transport protocol over UDP with built-in TLS 1.3, independent multiplexed streams, and connection migration. HTTP/3 runs HTTP over QUIC instead of TCP, so a lost packet stalls only its own stream — removing the TCP head-of-line blocking of HTTP/2 — and a connection survives an IP change via its connection ID.
Common mistakes
- ✗Believing QUIC runs over TCP rather than UDP
- ✗Thinking HTTP/3 still suffers TCP-style head-of-line blocking
- ✗Missing that a QUIC connection survives an IP change via its connection ID
Follow-up questions
- →Why does QUIC achieve a faster handshake than establishing TCP plus TLS separately?
- →What makes connection migration useful for a mobile client switching networks?
