Packets and layers
Your data never travels as itself. It travels wrapped in four headers, and the size of those wrappers decides whether large uploads work.
- You can list the four wrappers around a web request and say what address each one carries.
- You can explain why a 1,500-byte limit causes a file upload to hang while a ping succeeds.
You drag a photo into a browser and let go. Somewhere between the click and the server, your 4 MB image becomes about 2,700 separate chunks, each with four layers of header, each travelling independently, and most of them arriving out of order.
Nothing about that is incidental. Each layer exists because a different question has to be answered, and each layer adds a header that answers exactly one of them.
2.1The wrappers, and what each one adds
| Layer | Unit | Header adds | Answers the question |
|---|---|---|---|
| Application | data | HTTP verbs, paths, headers | What am I asking for? |
| Transport | segment | Source and destination port | Which conversation is this? |
| Network | packet | Source and destination IP | Which machine, anywhere? |
| Link | frame | Source and destination MAC | Which device on this wire, right now? |
| Physical | bits | — | What voltage, light or radio? |
The rule that prevents most confusion: IP addresses stay the same from end to end; MAC addresses are rewritten at every hop. A router receives a frame, throws the frame header away, looks at the IP address, chooses a next hop, and builds a brand-new frame for that hop. The packet is the same packet. The envelope it travels in is not.
An HTTP request: a method, a path, a host header, cookies, and maybe a body. At this point it is just bytes with a meaning agreed by two programs. Nothing here knows about addresses.
TCP adds source and destination ports. The destination port names the service (443). The source port names this conversation, so your browser can hold six connections open to the same server and the replies sort themselves out.
IP adds source and destination addresses, a protocol number (TCP is 6), and a TTL — a hop counter that stops packets circulating forever. Twenty bytes, minimum. These are the addresses that survive to the far end.
Ethernet adds the MAC address of the next device — your router, not the server — plus the type of payload and a checksum. Fourteen bytes. This header is discarded at the next hop and replaced with a new one.
The frame becomes electrical, optical or radio signals. The receiving device recomputes the checksum; a mismatch means the frame is dropped silently, with no retransmission by Ethernet. Recovery, if it happens at all, is TCP's job.
2.2The number that breaks things: 1,500
A standard Ethernet frame carries at most 1,500 bytes of payload. Subtract 20 bytes of IP header and 20 of TCP header and you get 1,460 bytes of application data per segment — the maximum segment size, or MSS. Everything above that is split, and everything split has to be reassembled.
That limit is why tunnelling is dangerous. A tunnel wraps your packet inside another packet, and the outer headers eat into the 1,500 before your data gets a turn.
| Path | Overhead | Usable payload |
|---|---|---|
| Plain Ethernet, IPv4, TCP | 54 bytes | 1,460 |
| + 802.1Q VLAN tag | 58 bytes | 1,456 |
| + VXLAN overlay | 108 bytes | 1,406 |
| + IPsec in tunnel mode | up to 181 bytes | ~1,330 |
| Consumer fiber with PPPoE | 62 bytes | 1,452 |
If the path cannot carry a packet, the correct behavior is for a router to send back an ICMP message saying "fragmentation needed, and here is the size I can take". Your machine then lowers its packet size and carries on. This is called path MTU discovery, and it depends entirely on that ICMP message being allowed through.
Filter ICMP "for security" and path MTU discovery stops working. The symptom is distinctive and infuriating: ping succeeds, DNS resolves, the TLS handshake completes, then the first large response hangs forever. Small packets fit under the limit; large ones vanish without an error. If you meet a connection that establishes and then freezes on the first big download, suspect MTU before you suspect the application.
2.3Decapsulation, and why order matters
The receiving host reverses the process. The network card validates the frame, the kernel strips the Ethernet header, checks the destination IP, strips the IP header, notices the protocol is TCP, matches the source and destination ports to a socket, strips the TCP header, and hands the bytes to the process that owns that socket.
Because each layer only reads its own header, a problem at one layer is invisible to the others. That is the useful part of layers: they tell you where to look. It is also the trap: a failure at layer 2 presents as a failure at layer 4, because all the upper layer ever sees is "no reply".
A packet crosses four routers. Which address is the same in the capture taken at the first router and the last?
60-second recap
- Four wrappers, one question each. Port is which conversation, IP is which machine, MAC is which device on this wire.
- 1,500 bytes, then tunnelling tax. Every tunnel reduces the payload, and something has to tell the sender.
- Layers locate failures. They do not prevent them, and a lower-layer fault always looks like an upper-layer silence.