Skip to content

TCP/IP Deep Dive

Scope

This document gives a dense operator-level view of TCP/IP and packet flow, focused on what matters for Linux, troubleshooting, and interviews.

It covers:

  • IP routing
  • TCP handshake and teardown
  • ports and sockets
  • MTU/MSS
  • retransmissions
  • flow control vs congestion control
  • NAT/conntrack intuition
  • packet life on Linux
  • common failure patterns

Big Picture

Networking is not "the app talks to the wire."

It is:

application
  -> socket API
  -> transport (TCP/UDP)
  -> IP routing
  -> link layer / NIC
  -> switch/router path
  -> reverse path on the other side

TCP/IP is layered because each layer solves a different problem:

  • IP: addressing and routing
  • TCP: ordered reliable byte stream with congestion/flow control
  • application protocol: meaning

IP: Delivery Without Promise

IP gives you: - addressing - packet forwarding - hop-by-hop routing

IP does not guarantee: - delivery - ordering - uniqueness - no duplication

That is why TCP exists.

TCP: Reliable Byte Stream, Not Message Bus

TCP gives: - connection orientation - ordered byte stream - retransmission - flow control - congestion control

Important phrase: TCP is a byte stream, not a message protocol.

If an app writes three chunks, the receiver may observe different read boundaries. That confuses people who think "one send equals one receive."

The Three-Way Handshake

Classic connection setup:

  1. client sends SYN
  2. server replies SYN-ACK
  3. client replies ACK

Now the connection is established.

Why three steps? To synchronize sequence number state and confirm both directions are reachable/acceptable.

Connection Teardown

Often a FIN/ACK exchange in each direction.

But in real life you also see: - resets (RST) - time-wait states - half-closed connections - abortive closes

A lot of "mystery network bugs" are really lifecycle misunderstandings.

Ports and Sockets

A port is not a process. It is a transport-layer demultiplexing number.

A socket is the kernel object representing an endpoint and its state.

For TCP, a specific flow is identified by the tuple:

src ip, src port, dst ip, dst port, protocol

This is why many clients can talk to one server port simultaneously.

Routing

When Linux sends a packet, it consults the routing table and chooses:

  • egress interface
  • next hop
  • source address behavior
  • policy route if configured

Routing is destination-driven. The kernel does not ask "what app is this?" first. It asks "where should packets to this destination go?"

ARP / Neighbor Discovery Intuition

On local networks, IP still needs link-layer neighbor resolution.

IPv4: - ARP

IPv6: - Neighbor Discovery

This is how the host learns which L2 address corresponds to the next-hop IP.

MTU and MSS

MTU is the maximum frame payload size at the link layer context. MSS is the TCP payload size negotiated with path assumptions.

When MTU assumptions are wrong: - fragmentation - black holes - weird stalls - PMTU pain

This is one of those things admins forget until VPNs, tunnels, or overlays start being spiteful.

Flow Control vs Congestion Control

Flow control

Receiver says how much data it can currently accept. This protects the receiver.

Congestion control

Sender adapts to perceived network capacity and congestion. This protects the network path.

People mix these up constantly. They are not the same.

Retransmissions and Ordering

TCP retransmits missing data. Packets can arrive out of order. ACK behavior and loss recovery are central to performance.

So: - latency is not just bandwidth - packet loss hurts throughput badly - reordering can trigger weird behavior - buffering can hide or worsen problems

NAT and Conntrack Intuition

With NAT, addresses and/or ports are rewritten in transit. Linux commonly tracks this with conntrack state.

That means the firewall/NAT path often needs to remember flows, not just evaluate stateless rules.

Operational implication: conntrack exhaustion can wreck seemingly healthy systems.

Linux Packet Path Intuition

For an inbound packet on Linux:

NIC
 -> driver
 -> kernel receive path
 -> netfilter PREROUTING
 -> routing decision
 -> INPUT or FORWARD
 -> socket lookup
 -> userspace process

For outbound:

process
 -> socket
 -> OUTPUT
 -> routing
 -> POSTROUTING
 -> NIC

This is why packet captures, routing tables, and firewall state all matter together.

Common Failure Patterns

DNS blamed for everything

Sometimes correctly. Often lazily.

"Port open" but app broken

TCP reachability is not application correctness.

MTU mismatch

Classic on tunnels/VPNs/encapsulated paths.

Asymmetric routing

Packets return differently than they arrived, breaking assumptions/firewalls.

Conntrack exhaustion

New flows fail or behave erratically.

SYN backlog/listen queue issues

Looks like random connection flakiness under load.

TIME_WAIT misunderstanding

Normal TCP state gets blamed as if it were malware.

Useful Commands

ip addr
ip route
ip rule
ss -tulpn
ss -tan

ping
tracepath
traceroute
tcpdump -ni any

conntrack -L
nft list ruleset
iptables -L -nv

Interview-Level Things to Explain

You should be able to explain:

  • difference between IP and TCP
  • what the three-way handshake does
  • why TCP is a byte stream
  • how routing decisions are made
  • what MTU/MSS problems look like
  • difference between flow control and congestion control
  • what conntrack does
  • why a port is not the same thing as a process

Fast Mental Model

TCP/IP turns application bytes into routed packets and back again, with IP handling delivery attempts across networks and TCP adding connection state, ordering, retransmission, and rate control.

Wiki Navigation

Prerequisites

Related Content