Skip to content
Production Stack Concerns
step 1/5

Reading — step 1 of 5

Read

~1 min readProduction Concerns

Production Stack Concerns

Real TCP/IP stacks (Linux, BSD, gVisor) handle a thousand edge cases:

Path MTU discovery (PMTUD): if a router can't fit a packet, it sends ICMP "fragmentation needed" with the MTU. Sender lowers PMTU; future packets fit.

Nagle's algorithm: delay sending small packets until ACK or buffer fills (avoid sending many tiny segments). Disabled with TCP_NODELAY for latency-sensitive apps (SSH, gaming, RPC).

Delayed ACKs: receiver bundles ACKs with response data or holds 200ms. Combined with Nagle on the other side: deadlock-style stalls. Modern systems prefer TCP_QUICKACK for low latency.

Keepalives: detect dead peers. Periodically send ACK with seq one less than expected; peer responds. No response after N tries → connection dead.

Half-open connections: peer crashed without FIN. Detected via timeout or keepalive.

Listen backlog: kernel queues SYNs and ESTABLISHED-but-unaccepted connections. Overflow = drops, retried by client. Hence accept() should be fast.

SYN flood: attacker sends many SYNs without finishing. Defense: SYN cookies — encode connection state in ISN, free server memory.

Connection tracking (conntrack): NAT and stateful firewalls track every connection. Has its own table — overflowing → drops.

TCP_NOTSENT_LOWAT, SO_BUSY_POLL, GRO/LRO, TSO, GSO — performance tuning beyond basic stack semantics.

Most of this is invisible to apps. The kernel does it. But when something breaks, you reach for tcpdump, ss, netstat, wireshark — and knowing what TCP DOES informs what to look for.

Our toy stack stops here. Production = orders of magnitude more.

Discussion

Ask a question, share an insight, or help someone who’s stuck.

Sign in to post a comment or reply.

Loading…