TCP vs UDP

1. What Is It?

TCP (Transmission Control Protocol) and UDP (User Datagram Protocol) are the two dominant transport-layer protocols. They sit between IP (which routes packets across the internet) and application protocols like HTTP or DNS (which define what the data means).

The core difference: TCP guarantees delivery and ordering; UDP does not. TCP establishes a connection, acknowledges every segment, retransmits lost data, and ensures bytes arrive in order. UDP sends datagrams with no handshake, no acknowledgment, and no retransmission — if a packet is lost, it's gone.

This isn't TCP-good, UDP-bad. It's a tradeoff between reliability and overhead. For most application-layer protocols (HTTP, databases, email), you want TCP's guarantees. For real-time workloads where a retransmit would arrive too late to be useful (video streaming, gaming, DNS lookups), UDP's low overhead wins.

2. How It Works

TCP Connection Lifecycle

-+ResetFullscreen

Key TCP mechanisms:

• Sequence numbers — every byte is numbered; the receiver can detect gaps and request retransmission.
• Flow control — the receiver advertises a window size telling the sender how much data it can buffer. Prevents a fast sender from overwhelming a slow receiver.
• Congestion control — TCP detects packet loss (a proxy for network congestion) and slows its send rate. Algorithms like CUBIC and BBR govern this behavior.
• Nagle's algorithm — TCP buffers small writes and coalesces them into larger segments. Can add latency for interactive protocols; disable with TCP_NODELAY when needed (used by most database drivers and HTTP/2 implementations).

UDP

UDP has an 8-byte header: source port, destination port, length, checksum. That's it. No connection, no state, no acknowledgment. The application layer handles reliability if it needs it.

Where UDP is the right choice:

• DNS — single request/response fits in one datagram; TCP handshake overhead isn't worth it. (DNS does fall back to TCP for large responses.)
• QUIC / HTTP/3 — built on UDP with reliability and multiplexing implemented in userspace, avoiding TCP's head-of-line blocking.
• Real-time media (WebRTC, VoIP) — a retransmitted audio frame arriving 200ms late is useless; better to skip it and move on.
• DHCP, NTP — simple query/response protocols with low overhead requirements.

3. What SDEs Actually Need to Know

The 3-way handshake costs a round trip. Before the first byte of HTTP data is sent over a new TCP connection, a client and server exchange SYN/SYN-ACK/ACK. On a 100ms RTT link, this is 100ms of overhead before TLS and HTTP even start. Connection pooling and HTTP/2 persistent connections exist to amortize this cost.

Half-open connections and timeouts. If a server process crashes without sending FIN, the client's TCP stack may sit in ESTABLISHED state indefinitely waiting for data. Application-level keepalives (like TCP_KEEPALIVE or HTTP keepalive pings) detect these zombie connections. This is why you should always configure connection timeouts in database and HTTP clients.

Connection refused vs. timeout:

• Connection refused (ECONNREFUSED) — the OS on the target machine is rejecting the connection, typically because nothing is listening on that port. Fast fail.
• Connection timed out (ETIMEDOUT) — no response at all. Either the machine is unreachable, a firewall is silently dropping packets, or the port is blocked. Slow fail (waits until the kernel's retry timer expires, often 75+ seconds by default).

TCP head-of-line blocking. HTTP/1.1 over TCP multiplexes requests by pipelining, but a single lost TCP segment blocks all subsequent data on the connection until the retransmit arrives. HTTP/2 uses streams within a single connection — but those streams still share one TCP socket, so one lost packet still stalls all streams. HTTP/3 (QUIC over UDP) solves this by implementing independent reliability per stream.

4. Tradeoffs & Decisions

When to use TCP:

• HTTP/REST APIs, database connections, file transfers, email — anywhere data integrity and ordering are required.
• When your application doesn't want to implement its own reliability.

When to consider UDP:

• Real-time media where latency beats reliability (WebRTC, game state updates).
• High-frequency, loss-tolerant telemetry or sensor data.
• Implementing a custom protocol where you want fine-grained control over reliability behavior (QUIC-style).

TCP tuning decisions SDEs occasionally touch:

• TCP_NODELAY — disable Nagle's algorithm when you need low-latency small messages (database drivers, Redis clients, gRPC).
• SO_KEEPALIVE — detect dead connections. Usually also set idle timeout at the application layer (database pool health check, HTTP idle timeout).
• Backlog queue size — the listen() backlog limits how many unaccepted connections the OS queues. Under heavy load, a small backlog causes clients to see Connection refused. Linux default is 128; production servers often set it to 1024+.

5. Interview Cheat Sheet

Key sentences:

• "TCP guarantees reliable, ordered delivery using sequence numbers and acknowledgments; UDP sends datagrams with no delivery guarantee and minimal overhead."
• "The TCP 3-way handshake (SYN/SYN-ACK/ACK) costs one round trip before data can flow — this is why connection pooling matters for latency-sensitive services."
• "HTTP/3 runs over QUIC on UDP to eliminate TCP's head-of-line blocking: each stream gets independent reliability without a shared TCP connection bottleneck."
• "Connection refused means nothing is listening on that port (fast); connection timeout means packets are being dropped somewhere (slow)."

Common follow-ups:

Q: Why does losing one TCP packet stall all HTTP/2 streams? A: HTTP/2 multiplexes logical streams over a single TCP connection. TCP guarantees in-order delivery, so if a segment is lost, the OS won't deliver any later segments to the application until the missing one is retransmitted and received. All streams on that connection block. QUIC (HTTP/3) avoids this by implementing per-stream reliability in userspace over UDP.

Q: What is TCP slow start? A: When a new TCP connection opens or after detecting congestion, TCP starts sending at a small congestion window and exponentially increases it until it detects a loss. This means the first few seconds of a connection are rate-limited even if both sides have high bandwidth available. It's one reason why reusing established connections (keep-alive, pooling) matters for performance.

Q: What's the difference between a FIN and a RST? A: FIN is a graceful close — "I have no more data to send" — and allows the other side to finish sending before closing. RST is an abrupt reset — "this connection is invalid, discard it immediately." You typically see RST when a process crashes, a port is unreachable, or a load balancer forcibly terminates a connection.