Networking

TCP vs UDP: what each guarantees

TCP gives you a reliable, ordered byte stream. Lost segments are retransmitted, out-of-order arrivals are reassembled, and the sender backs off when the network is congested. You pay for that with setup latency and with head-of-line blocking: one lost segment stalls everything queued behind it. Web pages, API calls, database connections, anything that must arrive intact rides TCP.

UDP is a thin wrapper over IP. Send a datagram and hope. No handshake, no ordering, no retransmission, no congestion control. That sounds worse until the data is time-sensitive and self-superseding: live audio, video frames, game state, DNS queries. A packet that arrives late is useless, so you would rather drop it and move on. QUIC (under HTTP/3) is built on UDP for exactly this reason, then rebuilds the reliability it needs on top.

Wrong "UDP is unreliable, so real systems avoid it." DNS, video calls, and HTTP/3 all run on UDP. It trades the delivery guarantees for lower latency and hands recovery to the application, a different contract rather than a worse one.

The TCP handshake, and why a cold connection is slow

Before one byte of your request goes out, TCP runs a three-way handshake: the client sends SYN, the server replies SYN-ACK, the client sends ACK. That ACK can carry the request itself, so setup costs about one round trip. Over HTTPS, TLS then runs its own handshake on top (it authenticates the server via a certificate and agrees a shared key), adding another round trip before the request. A cold HTTPS request pays TCP, then TLS, then the request/response.

The fix is connection reuse. Keep the connection open with HTTP keep-alive and pool it, and the next request skips both handshakes:

# three requests, one connection: one handshake, not three
curl -sw '%{time_connect}c  %{time_starttransfer}ttfb\n' -o /dev/null \
  https://api.example.com/a https://api.example.com/b https://api.example.com/c

The first call shows a real connect time; the reused calls show near-zero connect and only the request round trip. Opening and tearing down a socket per call is the classic latency bug: the client spends most of its time shaking hands instead of moving data.

How DNS turns a name into an address

A hostname has to become an IP before any connection opens. Your stub resolver asks a recursive resolver; if nothing is cached, that resolver walks the hierarchy. A root server points at the .com TLD server, which points at the domain's authoritative server, which returns the address. Every layer caches the answer for its TTL, so most lookups are served from a cache near you and cost almost nothing.

TTL is the gotcha during a migration. Drop a record's TTL well before you cut over; flip an IP while a 24-hour TTL still sits in caches and clients keep hitting the old address until it expires.

What network latency is actually made of

Four components stack up on every path. Propagation delay is distance over signal speed (about two-thirds of c in fiber), so New York to London is roughly 40 ms one way regardless of bandwidth. Transmission delay is packet size over link rate, the time to clock bits onto the wire. Queueing delay is time in buffers behind other packets, the part that spikes under congestion. Processing delay is the routers and the stack doing their work.

A cold connection's cost is round trips times RTT, and RTT is propagation-bound. Moving a 100 Mbps link to 1 Gbps does nothing for a handshake waiting on light to cross an ocean. The levers are fewer round trips (reuse, resumption), shorter distance (a CDN edge, anycast), and fewer bytes on the critical path. A fatter pipe is not one of them.

TLS 1.3, session resumption, and 0-RTT

The handshake authenticates the server through its certificate chain, agrees a shared symmetric key via ephemeral Diffie-Hellman, and turns on integrity for everything after. TLS 1.2 needed two round trips. TLS 1.3 folds the key exchange into the first flight and finishes in one; a resumed session with a pre-shared key can send 0-RTT early data in the very first packet.

Wrong "0-RTT is just a faster handshake, always turn it on." Early data is replayable and not forward-secret. An attacker who captures that first flight can resend it, so 0-RTT is safe only for idempotent requests. A 0-RTT POST that moves money is a live vulnerability, not a tuning win.

Flow control vs congestion control

Two mechanisms, routinely confused. Flow control is the receive window: the receiver advertises how much it can buffer so a fast sender cannot overrun a slow reader. Congestion control is the congestion window (cwnd): the sender's estimate of what the network will bear, grown by slow start then AIMD, cut on loss. The window protects the receiver; the other protects the shared path.

Both feed head-of-line blocking. TCP hands you one ordered byte stream, so a single lost segment stalls every byte behind it, including bytes for the logically independent HTTP/2 streams multiplexed on that connection. QUIC gives each stream its own delivery over UDP, so one loss no longer blocks the rest. That is the transport reason HTTP/3 exists.

Sockets, ports, and TIME_WAIT

A connection is a 5-tuple: protocol, source IP, source port, destination IP, destination port. A client is not capped at roughly 28k connections total, only about 28k per destination (the Linux ephemeral range is 32768-60999). After an active close, the closing side holds TIME_WAIT for 2*MSL (around 60 s on Linux) so a late duplicate cannot land on a new connection reusing the same tuple, and so the final ACK can be retransmitted if lost.

ss -tan state time-wait | wc -l   # sockets parked in TIME_WAIT

Under high churn those pile up and exhaust ephemeral ports or conntrack entries. The answer interviewers want is connection reuse and pooling, not lowering the timer blindly. Whoever calls close first inherits TIME_WAIT, which is why a busy server usually prefers the client to be the active closer.