TCP vs UDP
TCP is a connection-oriented, reliable protocol that guarantees ordered delivery via acknowledgments and retransmissions. UDP is connectionless and unreliable — packets may be lost, duplicated, or reordered, but it has lower overhead.
TCP = sending a certified letter (signature required, guaranteed delivery, slow). UDP = shouting across the yard (fast, no guarantee they heard you, perfect for 'dinner's ready!' where a retry is just shouting louder).
TCP: use when reliability and ordering are required (HTTP, databases, file transfer). Three-way handshake adds 1 RTT latency at connection establishment; retransmissions add latency on packet loss. UDP: use when low latency matters more than reliability (video streaming, gaming, DNS, VoIP). Applications can implement their own reliability on top of UDP if needed (QUIC is essentially TCP semantics over UDP). HTTP/3 uses QUIC (UDP-based), eliminating TCP's head-of-line blocking.
TCP's head-of-line blocking: within a TCP stream, a lost packet blocks delivery of all subsequent packets until retransmitted. HTTP/2 multiplexes multiple streams over one TCP connection — a lost packet blocks all streams simultaneously (head-of-line blocking at the TCP level). HTTP/3 + QUIC solves this: each HTTP/3 stream is independently flow-controlled at the QUIC layer — a lost packet only blocks the stream it belongs to, not all streams. QUIC also bakes TLS 1.3 into the handshake, reducing connection setup to 1 RTT (vs TCP's 3-way handshake + TLS handshake = 2 RTTs). For real-time applications (gaming, WebRTC), UDP with application-level selective retransmission gives control over which packets are worth retransmitting — stale video frames are discarded rather than retransmitted.
I use TCP for everything requiring reliability (APIs, databases, messaging). I'd choose UDP (via QUIC or WebRTC) for real-time media or gaming where head-of-line blocking in TCP would cause perceptible jitter. For a live video streaming system, I'd use HLS (HTTP/TCP) for broad compatibility but offer a WebRTC (UDP-based) path for real-time low-latency streams. For the API layer, I'd adopt HTTP/3 at the edge to eliminate TLS+TCP handshake overhead on mobile networks.
Assuming UDP means you lose all reliability. QUIC over UDP implements its own reliable ordered delivery per stream. WebRTC has its own congestion control (NACK/FEC). UDP is not 'unreliable' in applications — it's 'unreliable at the transport layer, with optional application-layer reliability.'