TCP/IP Stack

What is the TCP/IP stack?

The TCP/IP stack is the internet’s layered division of labor: the link layer moves frames across one physical hop; IP routes packets across networks with no delivery promises; TCP builds ordered, reliable byte streams on that unreliable base (while UDP deliberately doesn’t); and the application layer — HTTP, TLS, DNS — speaks in terms your code understands. The model’s enduring value to practitioners isn’t taxonomy; it’s diagnosis. Every network symptom lives at a layer, and knowing which one turns mysteries into checklists.

The engineer’s working knowledge

Handshakes cost round trips: TCP’s three-way handshake plus TLS negotiation means a cold HTTPS connection burns 2–3 RTTs before any data — the entire reason connection pooling, keep-alives, and TLS session resumption exist, and why serverless functions that open fresh connections per invocation feel slow. TCP interprets loss as congestion and throttles — correct on the wired internet, painful on flaky Wi-Fi, and the motivation for QUIC/HTTP/3 rebuilding transport atop UDP. Ephemeral ports, connection-table limits, and TIME_WAIT are the invisible ceilings behind “we can’t open more connections” incidents at load-balancer and NAT layers.

Debugging by layer

Can you ping the IP (layer 3)? Does the TCP port open (layer 4 — nc -zv)? Does TLS negotiate (openssl s_client)? Does the HTTP request succeed (curl -v)? Four commands walk the stack and localize virtually any connectivity failure — the difference between “network’s broken” and a fixable ticket.

What people get wrong

• Blaming the app for transport problems: slow uploads on lossy paths are TCP congestion behavior, not your API.
• Forgetting MTU — VPNs and tunnels shrink packet size; black-hole drops of only large packets are the signature.
• Treating UDP as unreliable-therefore-bad: DNS, QUIC, and most realtime media choose UDP precisely to escape TCP’s guarantees.

Primary source: RFC 1122 — Requirements for Internet Hosts

Why the Layer Model Matters for Debugging

Understanding which layer a given networking problem lives at is often the fastest path to diagnosing it: a DNS resolution failure is an application-layer problem, a TLS handshake failure is a presentation/session-layer concern, a dropped connection under load might point to transport-layer issues like TCP retransmission or exhausted ephemeral ports, and a complete inability to reach a host at all often points to network-layer routing or link-layer physical connectivity. Experienced network engineers use this layered mental model specifically to narrow down where in the stack a problem is occurring before diving into specific tools, since the right diagnostic tool (DNS lookup utilities, TLS handshake analyzers, packet capture tools, routing table inspection) differs meaningfully depending on which layer the actual fault lives in.