The four layers, one at a time
◈ 5 cardsEach layer's job and the unit of data it handles — message, segment, datagram, frame — plus encapsulation on the way down and de-encapsulation on the way up.
Every layer adds exactly one header
Data travelling down a stack is not translated; it is wrapped. Each layer takes whatever the layer above handed it, treats the whole thing as an opaque payload, prepends its own header, and passes the result down. That is encapsulation. On the receiving host the mirror runs: each layer strips its own header and hands the remainder up. The peer's transport layer reads the header your transport layer wrote, and neither application ever sees it.
That is why each layer has its own name for the thing it is carrying.
Host-to-network: frames
The bottom layer (also called the link layer or the network interface layer) defines how one particular interface — an Ethernet card, a Wi-Fi antenna — puts IP datagrams onto its physical connection. Its unit is a frame. It is the most complex layer of the four and Java hides all of it; the only reason you think about it is performance, because a fibre link and a metered mobile link deserve different protocol design.
Internet: datagrams
The internet layer organises bytes into datagrams and defines the addressing scheme by which machines find one another. The Internet Protocol is the only network-layer protocol Java understands, in two versions: IPv4 with 32-bit addresses and IPv6 with 128-bit addresses. An IPv4 datagram has a header of 20 to 60 bytes and a payload of up to 65,515 bytes, though in practice datagrams are far smaller because they must fit the link's MTU — the largest frame the medium accepts, classically 1,500 bytes on Ethernet. Datagrams too large for the next link get fragmented and reassembled at the far end.
The second job of this layer is translation between unlike links: a router speaks Wi-Fi on one side and Ethernet or fibre on the other, so heterogeneous networks join into one.
Transport: segments
Raw datagrams can be lost, duplicated, corrupted, or delivered out of order, because individual datagrams may follow different routes. The transport layer is where that is fixed — or deliberately not fixed. TCP's unit is a segment, and TCP adds sequence numbers so the receiver can restore order, checksums over the data, and retransmission requests for what never arrived. UDP is the other choice: it will tell you a datagram is corrupt but promises nothing about order or arrival.
Application: messages
The top layer decides what the bytes mean: that this response is a PNG and not a long number, that this line is a mail header. Its unit is whatever the protocol says — call it a message. HTTP, SMTP, POP3, IMAP, FTP and the protocol you design yourself in module 9 all live here, and so does most of your code.
Worked example — a 3,000-byte page, counted down the stack
A server returns a 3,000-byte HTML body with about 150 bytes of HTTP headers: one message, 3,150 bytes, handed to TCP.
On a path with a 1,500-byte MTU, TCP may send at most 1,460 bytes per segment (1,500 minus a 20-byte IP header minus a 20-byte TCP header). So 3,150 bytes becomes three segments: 1,460 + 1,460 + 230. Each grows a 20-byte TCP header. IP wraps each of the three in a datagram with a 20-byte header. Ethernet frames each datagram with its own header and trailer and puts it on the wire.
One message. Three segments. Three datagrams. Three frames. The browser is handed 3,150 contiguous bytes and never learns that the page arrived in three pieces — and, crucially, one read() in your client will not hand you the whole page either.