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

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. Keepalives (TCP keepalive probes via SO_KEEPALIVE, or application-level pings such as HTTP/2 PING frames) 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 pipelining sends several requests on one connection without multiplexing (responses must return in order). 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 full backlog makes Linux drop new SYNs, so clients see slow connects or timeouts rather than Connection refused. Linux caps the backlog at net.core.somaxconn (default 4096 since kernel 5.4, 128 before). Production servers often pass a backlog of 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.