Core CS · Computer Networks

Thirty-eight bytes in, ninety-six bytes on the wire

Q: Does the destination host decrement the TTL?

No. Only a router that forwards a packet decrements it, because TTL is a hop counter that exists to kill packets going round a routing loop. The destination is receiving, not forwarding, so it verifies the header checksum and the destination address and hands the payload up with the TTL untouched. This is also why a packet delivered on the local LAN with no router in between arrives with exactly the TTL the sender set, typically 64 on Linux.

One tiny HTTP request walks down five layers and collects a header at three of them, plus a trailer at one. Follow the byte count all the way down and back up, and the layer model stops being a list of names you memorised.

Push one HTTP GET down the stack, then pull it back up →

Nothing rewrites your data on the way down. Each layer treats what it was handed as an opaque blob it must not read, puts its own header in front of it, and passes it on. That is why 38 bytes of HTTP leave the network card as 96 bytes, and why the receiving application still gets exactly 38.

01 The idea

Each layer wraps what it was handed and never opens it

Your browser produces a request. It does not produce a packet, and it does not know a single thing about IP addresses, ports or cables. It hands a block of bytes to the transport layer and the contract is one sentence long: get these bytes to the process at the other end. The transport layer honours that contract without ever reading the bytes. It puts a header of its own in front of them and hands the result down. So does the layer below it, and the layer below that.

This is encapsulation, and the important half of it is the part nobody says out loud: each layer treats everything it receives from above as opaque payload. TCP does not know it is carrying HTTP. IP does not care that the thing inside it is a TCP segment, beyond one number in one field that says who to hand it to on arrival. Ethernet is carrying an IP packet and has no opinion about it whatsoever. That indifference is what lets you run HTTP over TCP over IPv4 over Ethernet today and the same HTTP over TCP over IPv6 over Wi-Fi tomorrow with nothing rewritten anywhere.

The visible consequence is that the data grows as it descends. Every layer adds bytes and no layer removes any, so the block leaving the card is strictly bigger than the block the application wrote. The name of the block changes at each step too, and that name is shorthand for how much wrapping is currently on it: the same bytes are a segment when they have a TCP header, a packet once the IP header goes on, and a frame once Ethernet has been around it.

On the receiver everything runs backwards, and this is the half that gets skipped. Decapsulation is not merely unwrapping. At each layer the receiver reads its own header, checks what that header exists to let it check, throws the header away, and hands what is left to whichever layer above the header named. Three layers check, three hand the rest upward, and at the top the application reads bytes that are identical to the ones the sender wrote.

Going down, every layer puts its own header in front of whatever it was handed and never looks inside it. Coming up, every layer checks its own header, throws it away, and hands the rest to whoever that header said it was for.

EncapsulationWrapping the whole of the layer above inside a new header, and on Ethernet a trailer as well, so the layer below can carry it without reading it. The payload is never modified, only surrounded.

PDUProtocol data unit: the name for the bundle at one layer. Data at the application layer, a segment at TCP and a datagram at UDP, a packet at the network layer, a frame at the data link layer, and bits at the physical layer.

HeaderA block of fields at the front of a PDU, read only by the matching layer at the far end. IPv4 is 20 bytes without options, TCP 20 bytes without options, UDP a flat 8, and Ethernet II 14 bytes plus a 4-byte FCS trailer.

02 Worked example

One HTTP GET, five layers down, ninety-six bytes

This is the request for the whole lesson, including the console in section 04 and every number in the cheat sheet. It is deliberately the smallest shape a real HTTP/1.1 server will answer: a request line, the Host header that HTTP/1.1 makes mandatory, and the blank line that says the headers are finished.

GET /hi HTTP/1.1↵  16 characters + CR LF = 18 bytesHost: examate.in↵  16 characters + CR LF = 18 bytes↵   the blank line, CR LF only  =  2 bytes

18 + 18 + 2 = 38 bytes. That is the entire application payload, and it is the only part of what follows that a human wrote. Client and server sit on the same LAN, so there is no router in the path and the two cards below are talking to each other directly. Learn these six values now, because they reappear in every field list in section 04.

Role	IPv4	MAC address	TCP port
Client (your browser)	`10.0.0.1`	`00:1A:A0:00:00:0A`	`49152`, picked from the ephemeral range
Server (the web server)	`10.0.0.7`	`00:1A:A0:00:00:07`	`80`, the standard HTTP port

Now send it. Read left to right, and watch the running total in each node rather than the names.

7 · ApplicationThe 38 bytes above. No header of its own; the request text is the payload. 38 B

→

4 · TransportPrepend a 20-byte TCP header: src port 49152, dst port 80, sequence number. Now a segment. 58 B

→

3 · NetworkPrepend a 20-byte IPv4 header: src 10.0.0.1, dst 10.0.0.7, TTL 64. Now a packet. 78 B

→

2 · Data linkPrepend a 14-byte Ethernet header AND append a 4-byte FCS. Now a frame. 96 B

→

1 · Physical96 × 8 = 768 bits, clocked onto the wire one at a time. No header of its own; the preamble in front is not part of the frame.

Add the wrapping up: 20 + 20 + 14 + 4 = 58 bytes of header and trailer around 38 bytes of request. The frame is 96 bytes, and 58 of those 96 are not the request, which is 60.4% overhead. Six out of every ten bytes on the wire exist only to get the other four there.

That number is alarming and it is also completely misleading, which is exactly why it is worth computing. Those 58 bytes are a fixed cost per PDU, not a percentage. Send a full-size segment instead, 1460 bytes of payload, and the same 58 bytes wrap it into a 1518-byte frame: 3.8% overhead for identical headers. Nothing changed except the size of the cargo. This is why a protocol that sends one keystroke per packet is wasteful and a protocol that sends a file is not, and why every serious transport tries hard to fill a frame before sending it.

The highlighted node is the odd one out, and it is the one that produces two exam questions. It is the only layer here that adds something at both ends rather than only at the front. Section 03 says why it has no choice.

03 Mechanics

One row per layer, the bytes it adds, and what it checks coming back

Same request, same 38 bytes. Read the table downward for encapsulation and upward for decapsulation. The last column is the one candidates skip and interviewers push on: coming up, a layer does not merely strip its header, it verifies the one thing that header exists for and then reads a field that names who to hand the rest to.

Notice that the walk runs 7, 4, 3, 2, 1 and that layers 6 and 5 are missing. That is not an oversight. OSI’s presentation layer and session layer have no protocols of their own in a TCP/IP stack: the work they describe, such as agreeing a character encoding or holding a login session together, is done inside the application protocol itself, so HTTP hands straight to TCP. The same fact is why you will meet the stack counted two different ways. RFC 1122 defines four layers, folding data link and physical into one link layer, while most textbooks and most interviewers teach five by splitting that link layer back apart. Both describe the same bytes on the same wire; only the naming differs, and neither one has a session or presentation layer of its own.

Layer	PDU	What it adds going down	Bytes	Running total	What it checks coming up
7 · Application	`data`	Nothing of its own. The HTTP request text is the payload everything else wraps.	`38 payload`	`38`	Nothing left to strip. It reads the 38 bytes, byte for byte what the sender wrote.
4 · Transport (TCP)	`segment`	TCP header: source port 49152, destination port 80, sequence number, checksum, data offset.	`+20`	`58`	Recomputes the TCP checksum over the header, the payload and a pseudo-header pulled from the IP addresses. Then destination port 80 picks the process.
3 · Network (IPv4)	`packet, also called a datagram`	IP header: source 10.0.0.1, destination 10.0.0.7, TTL 64, protocol 6, header checksum.	`+20`	`78`	Verifies the header checksum, then that the destination IP is its own. Protocol 6 says hand the 58 bytes to TCP.
2 · Data link (Ethernet II)	`frame`	14-byte header in front (6-byte destination MAC, 6-byte source MAC, 2-byte EtherType) and a 4-byte FCS behind.	`+14 and +4`	`96`	Recomputes a CRC-32 over bytes 1 to 92 and compares it with the FCS, then that the destination MAC is its own. EtherType 0x0800 says hand the 78 bytes to IPv4.
1 · Physical	`bits`	No header. Encoding, a preamble to lock the receiver’s clock, and the timing of 768 bits on the medium.	`+0`	`96`	Nothing. It recovers 768 bits and hands 96 bytes up. It cannot tell a good frame from a corrupt one.

Why the FCS is a trailer and not a header. The FCS is a CRC-32 computed over everything before it — here bytes 1 to 92, from the first byte of the destination MAC to the last byte of the request. A value computed over a block cannot be stored in front of that block, because at the moment the front is written the rest does not exist yet. The sending card streams the frame out bit by bit and folds the CRC as it goes, then puts the finished four bytes on the end; the receiving card folds the same CRC over the arriving bits and compares. Both ends work in a single pass with no buffering. TCP and IP put their checksums in their headers because those layers assemble a whole PDU in memory before sending anything, so they can go back and fill the field in. The physical constraint decides the position, not a design preference.

MTU is the ceiling the frame imposes on the packet. The maximum transmission unit of a link is the largest payload one frame may carry, and it is measured as the IP packet, not the frame. On Ethernet it is 1500 bytes, so the largest standard frame is 14 + 1500 + 4 = 1518 bytes. Why 1500 and not something rounder? Two reasons that both still hold. The two bytes after the MAC addresses are a length field in the original 802.3 framing when the value is 1500 or below and an EtherType when it is 1536 (0x0600) or above, so 1500 is precisely where the length reading has to stop. And a frame holds the medium for its whole duration, so a very large frame is a long block on everybody else’s latency, while a very small one drowns in the fixed 58 bytes. Jumbo frames of around 9000 bytes exist on links where the operator controls both ends — an AWS VPC carries 9001 bytes inside a region — but they are not part of 802.3, so nothing on the public internet may assume them.

Fragmentation is what happens when the packet does not fit. If IPv4 has a packet larger than the outgoing link’s MTU, it splits it into fragments, each carrying its own full 20-byte IP header, tagged with the same Identification value, a More Fragments flag, and a Fragment Offset. Work one: a 4000-byte packet onto a 1500-byte MTU. Data is 4000 − 20 = 3980 bytes. Each fragment may carry 1500 − 20 = 1480 bytes, and 1480 is usable because the offset field counts in 8-byte units and 1480 ÷ 8 = 185 exactly. So the fragments carry 1480, 1480 and 1020 bytes, at offsets 0, 185 and 370. Three headers instead of one turns 4000 bytes into 4040 on the wire. Reassembly happens only at the final destination, never at an intermediate router, so losing any one fragment loses the whole packet. Two real-world clauses worth naming: a sender that sets the Don’t Fragment bit is asking routers to drop the packet and report back with ICMP instead, which is how Path MTU Discovery finds the smallest link on the route, and IPv6 removed router fragmentation entirely so only the source may fragment.

A router does the whole cycle again at every hop. It decapsulates up to layer 3, decides, then re-encapsulates from layer 3 down into a brand new frame for the next link. Both MAC addresses are new, the TTL is one lower, the IP header checksum is recomputed because a field changed, and a fresh FCS is calculated over the new frame. Neither IP address moves. That is the sentence behind the whole of layer 3: MAC addresses are hop-local and IP addresses are end-to-end. It also explains the TTL rule that trips people up. Only a router that forwards a packet decrements the TTL; the destination host, which is receiving rather than forwarding, does not touch it. Our request never meets a router, so it arrives at 10.0.0.7 with TTL still 64.

05 Cheat sheet

The numbers they ask you to produce

Every row is something an interviewer can ask you to state or compute in under ten seconds. The right-hand column is the specific wrong answer that gets given, not a general warning.

What they ask	The answer	The trap
Layer numbers, OSI	`1 physical, 2 data link, 3 network, 4 transport, 5 session, 6 presentation, 7 application`	`counting from the top — physical is 1, application is 7`
PDU at each layer	`data, then segment at TCP and datagram at UDP, then packet, then frame, then bits`	Calling everything a packet. The word only belongs at layer 3.
Header sizes, no options	`IPv4 20 B, TCP 20 B, UDP 8 B, Ethernet II 14 B header + 4 B FCS trailer`	Quoting 22 or 26 for Ethernet by folding in the preamble and the start delimiter, which are not part of the frame.
Our 38-byte GET, down the stack	`38 → 58 segment → 78 packet → 96 frame`	Stopping at 92 by forgetting the FCS, because it is at the end rather than the front.
Overhead on that frame	`58 of 96 bytes = 60.4%`	Treating that percentage as a property of the protocol stack. It is 58 fixed bytes.
The same headers on a full segment	`1460 payload → 1518-byte frame = 3.8%`	Not being able to say why the two percentages differ when nothing about the headers changed.
Ethernet MTU and maximum frame	`MTU 1500 (the IP packet), maximum frame 1518`	`saying the MTU is 1518 — MTU measures the payload, not the frame`
MSS on a 1500-byte MTU link	`1500 − 20 IP − 20 TCP = 1460 bytes`	Subtracting the Ethernet header and FCS too. MSS is measured inside the IP packet.
Minimum Ethernet frame	`64 bytes including the FCS, so a payload under 46 bytes is padded`	Our 96-byte frame is comfortably over it, so it is easy to forget the floor exists at all.
Why the FCS is a trailer	`it is a CRC over every byte before it, so it cannot exist until they do`	Answering “because the standard says so”, which invites the follow-up you cannot answer.
What a router changes per hop	`both MAC addresses, the TTL, the IP header checksum, and the FCS`	`saying it forwards the frame — it builds a new one`

Overhead is bytes, not a percentage58 bytes of header and trailer ride on every TCP-over-IPv4-over-Ethernet frame whatever the payload. On our 38-byte request that is 60.4% of the wire; on a 1460-byte segment it is 3.8%. The toll is identical, the cargo is not.

Every header names the layer aboveEtherType 0x0800 means IPv4, IP protocol 6 means TCP, TCP destination port 80 means the web server process. Decapsulation is never guesswork, and each of those three fields is what stops it being guesswork.

Only layer 2 adds a trailerEverything above it writes a pure prefix. Ethernet appends the FCS because a checksum computed over the whole frame cannot be written before the whole frame exists, which also makes it the last thing written and the first thing verified.

06 Where & why

Where these byte counts are numbers you can read off a screen

None of this is a diagram invented for exams. The layout in section 04 is a pane in a tool you can install in a minute, and the MTU is a live per-interface integer on the machine in front of you.

Wireshark

Section 04 is literally the packet details pane

Click one HTTP request and Wireshark lists Frame, Ethernet II, Internet Protocol Version 4, Transmission Control Protocol, Hypertext Transfer Protocol from top to bottom, which is outermost to innermost. Expand any one and it reports its own header length and highlights exactly those bytes in the hex pane. The first line gives you the frame total to compare against your arithmetic.

Linux · ip link

MTU is a number you can print and change

ip link show eth0 prints mtu 1500 on any ordinary Ethernet interface, and ip link set eth0 mtu 1400 changes it. Getting it wrong does not fail cleanly: a mismatched MTU lets small packets through and hangs on large ones, which looks like a routing or application fault right up to the moment somebody runs a capture.

PPPoE · RFC 2516

Why home DSL links run at 1492

PPPoE wraps every IP packet in 6 bytes of PPPoE header plus a 2-byte PPP protocol field before Ethernet sees it. Eight bytes of the 1500 are gone, so the usable MTU is 1492, and RFC 2516 says so explicitly. A router that keeps announcing 1500 on such a line produces exactly the symptom above, and it is the single most common cause of it in the field.

IEEE 802.1Q · VLAN trunk

Four bytes inserted into the header, not the payload

A VLAN tag is 4 bytes pushed into the Ethernet header between the source MAC and the EtherType, making the header 18 bytes and the maximum frame 1522 rather than 1518. The MTU stays at 1500 because the tag is header, not payload. It is the cleanest demonstration that MTU and frame size are two different measurements.

Two sentences to be able to defend on the spot. The data is never modified on the way down, only surrounded, which is why the receiving application gets byte-for-byte what the sending one wrote. And the FCS sits at the end because it is a checksum over everything before it, so it cannot be written until everything before it exists.

07 Interview questions

What they actually ask

Encapsulation is the first thing asked in almost every networking round, because it is one question that reveals whether the layer model is understood or recited. Expect to be told a payload size and asked for the frame size out loud, with no paper.

Walk me through what happens to an HTTP request as it goes down the stack.

The application writes the request text and hands it down. Transport prepends a TCP header carrying the source and destination ports and a sequence number, making a segment. Network prepends an IP header carrying the source and destination IP addresses and a TTL, making a packet. Data link prepends an Ethernet header with the two MAC addresses and appends a 4-byte FCS, making a frame, and physical clocks it out as bits. Give the numbers if you have them: a 38-byte request becomes 58, then 78, then 96 bytes.

Name the PDU at each layer.

Data at the application layer, segment at transport when the protocol is TCP and datagram when it is UDP, packet at the network layer, frame at the data link layer, and bits at the physical layer. The IPv4 unit is also called a datagram, which is why the word appears twice, so say "packet, sometimes called an IP datagram" and the ambiguity is handled. The commonest mistake is calling everything a packet; the word belongs at layer 3.

You keep saying an IPv4 header is 20 bytes, but the header can be longer. Why 20?

20 bytes is the minimum, which is what a header with no options is, and that is what almost every packet actually carries. The length lives in the IHL field, which is 4 bits counting 32-bit words, so it runs from 5 to 15 and the header runs from 20 to 60 bytes. TCP is built the same way: its data offset field is also 4 bits of 32-bit words, so a TCP header is also 20 bytes minimum and 60 maximum. UDP has no such field because its header is a flat 8 bytes with nothing optional in it.

Why is the Ethernet FCS a trailer when TCP and IP put their checksums in the header?

Because the FCS is computed over every byte before it. You cannot store a value in front of a block when the block does not exist yet at the moment you write the front. Ethernet cards stream a frame out bit by bit and fold the CRC as they go, then append the finished four bytes, and the receiver folds the same CRC over the arriving bits and compares. TCP and IP assemble a complete PDU in memory before sending it, so they can leave the checksum field blank and fill it in afterwards. It is a streaming constraint, not a style choice.

What is MTU, and what exactly does it measure?

The maximum transmission unit is the largest payload one frame of that link may carry, and it measures the IP packet, not the frame. Ethernet is 1500 bytes, so the largest ordinary Ethernet frame is 1500 plus a 14-byte header plus a 4-byte FCS = 1518 bytes. Saying "the MTU is 1518" is the standard wrong answer and it gets caught immediately, because the whole point of the number is that it is the ceiling on what you hand to the link, not the size of what the link puts on the wire.

What is MSS, and how does it relate to MTU?

The maximum segment size is the largest amount of application data one TCP segment may carry, and it is the MTU minus both the IP and the TCP header. On a 1500-byte Ethernet MTU with no options that is 1500 − 20 − 20 = 1460 bytes. Note which bytes it is measured inside: the Ethernet header and FCS are not subtracted, because MSS sits inside the IP packet and the MTU already stops at the packet boundary. Each end announces its MSS in the SYN of the handshake and neither may exceed what the other announced.

What happens if a packet is bigger than the link’s MTU?

IPv4 fragments it: the packet is split, each fragment gets its own full 20-byte IP header, and they share an Identification value with a More Fragments flag and a Fragment Offset that counts in 8-byte units. Reassembly happens only at the final destination, never at an intermediate router, so losing one fragment loses the whole original packet. If the sender set the Don’t Fragment bit the router drops the packet instead and returns an ICMP message, which is what Path MTU Discovery relies on. IPv6 dropped router fragmentation entirely, so only the source may fragment there.

On the way up, how does a layer know which layer above to hand the payload to?

A field in its own header names the next protocol, so it is never guesswork. Ethernet reads its EtherType: 0x0800 means IPv4. IPv4 reads its Protocol field: 6 means TCP and 17 means UDP. TCP reads the destination port to pick the receiving process, which is why the same machine can run a web server and a mail server on one IP address. Those three fields are the entire demultiplexing chain, and they are set on the way down by the layer that will read them on the way up.

What does a router change in a packet, and what does it leave alone?

It changes both MAC addresses, decrements the TTL, recomputes the IP header checksum because a field changed, and calculates a fresh FCS. It leaves both IP addresses alone. That is because it never forwards the frame that arrived: it decapsulates to layer 3, decides, and re-encapsulates the same packet in a brand new layer 2 frame for the next link. MAC addresses are hop-local and IP addresses are end-to-end, and that one sentence is what the whole question is testing.

Does the destination host decrement the TTL?

Hard

A client fetches a large file from a server. The TCP connection opens, small requests work perfectly, and every large response hangs and eventually times out. Somewhere on the path a tunnel reduces the MTU to 1400 bytes. The tunnel router drops oversized packets that have the Don’t Fragment bit set, and a firewall silently discards the ICMP messages it sends back. Explain why the small requests succeed, give the segment size the server chose and the one it should have chosen, explain why the server never finds out it is wrong, and give one fix at the transport layer and one at the network layer.

Follow-up

Nothing here is broken and nothing is misconfigured by accident: the server, the tunnel router and the firewall are each doing exactly what they were told. The failure is produced by three correct devices, so no single one of them can be blamed and the fix is not a bug fix.

Show the hint

Work out the largest IP packet each end believes it is allowed to send, then ask which single message that would have corrected the difference is the one being thrown away.