The TCP/IP stack and encapsulation

Four layers, because that is what shipped

While OSI was being standardized, working code was already running on a simpler four layer model, now called the TCP/IP stack or the internet protocol suite. It is what your operating system actually implements.

Two naming notes that trip people up. TCP/IP calls layer 3 the internet layer, not the network layer, and the two words mean the same thing here. And the model is named after two protocols, TCP and IP, which is a fair summary of where the important decisions live.

Encapsulation, header by header

Encapsulation is the act of wrapping the layer above's data as the payload of the layer below, and adding a header for the peer. Follow a small HTTP request down the stack of a machine sending it.

Start with the application data, 74 bytes of text:

GET /index.html HTTP/1.1
Host: example.com
User-Agent: curl/8.4.0

The transport layer takes those 74 bytes as its payload and prepends a 20 byte TCP header holding the source port, destination port, sequence number, and flags. The result is a segment of 94 bytes.

The internet layer takes the 94 byte segment as its payload and prepends a 20 byte IPv4 header holding source IP, destination IP, TTL, and protocol number 6 for TCP. The result is a packet of 114 bytes.

The link layer takes the 114 byte packet as its payload, prepends a 14 byte Ethernet header holding destination MAC, source MAC, and EtherType 0x0800 for IPv4, and appends a 4 byte checksum trailer. The result is a frame of 132 bytes, and that is what leaves the NIC as bits.

[ Ethernet 14 ][ IP 20 ][ TCP 20 ][ HTTP 74 ][ FCS 4 ]  = 132 bytes

Nothing was rewritten. Each layer only added a label on the front.

Decapsulation and the demultiplexing keys

The receiver runs the same steps backwards, and at each step it must decide which protocol handles the payload. Each header carries a field that answers exactly that, and those fields are the demultiplexing keys.

So decapsulation of our frame reads: strip Ethernet, EtherType says IPv4, hand up. Strip IP, protocol says 6, hand to TCP. Strip TCP, destination port says 80, hand to whichever process holds that port. Deliver 74 bytes of HTTP.

This chain is why a wrong single field breaks everything above it silently. A packet with protocol 17 and a TCP payload gets handed to UDP, which finds garbage and drops it, and nothing logs a useful error.

Reading the layers in real output

tcpdump prints one line per frame, and that line is the header stack in order. Unit 9 reads a capture in detail, but you can already decode this.

sudo tcpdump -n -i eth0 'tcp port 80' -c 1

14:22:07.114322 IP 192.168.1.42.51514 > 93.184.216.34.80:
  Flags [P.], seq 1:75, ack 1, win 502, length 74

Piece by piece: IP is the internet layer, 192.168.1.42 and 93.184.216.34 are its addresses, .51514 and .80 are transport ports, Flags [P.] and seq, ack, win are TCP header fields, and length 74 is the application payload we started with. Four layers, one line.

The overhead arithmetic

Headers cost bytes, and it is worth knowing how much. On Ethernet with a 1500 byte MTU, a full TCP packet carries 1500 − 20 − 20 = 1460 bytes of application data inside a 1518 byte frame.

efficiency = 1460 ÷ 1518 = 0.962, about 96 percent useful

Now do it for a 1 byte keystroke over SSH. The frame is still 14 + 20 + 20 + 1 + 4 = 59 bytes for 1 useful byte, under 2 percent efficiency. This is why chatty protocols feel slow on constrained links, and why Unit 7 talks about batching small writes instead of sending each one immediately.