How a Message Actually Travels

By the end of this session you will be able to:

• Name what each layer adds to a message on the way out, and what each layer strips on the way in
• Map the four TCP/IP layers onto the seven OSI layers, and say which OSI layers never show up as bytes in a capture
• Open a real capture and account for every single byte of a frame, header by header

Nothing is ever sent, it is wrapped

When a browser asks for a page, it hands the operating system 479 bytes of text. What actually leaves the network card is 533 bytes. Those extra 54 bytes are not waste that nobody got around to optimising away. They are four separate addressing decisions, made by four different pieces of software, each of which will be read by a different piece of equipment along the path.

That is encapsulation. Each layer treats whatever came from above as an opaque blob it must not touch, prepends its own header, and hands the result down. On the receiving side the same thing runs backwards: each layer reads its own header, removes it, and passes the rest up. The unit has a different name at each step, and the names matter because error messages and show command output use them: data at the application layer, a segment at transport, a packet at the internet layer, a frame at the link layer, and bits on the physical medium.

The useful part is that each header answers exactly one question:

• The Ethernet header answers which box on this cable. It is rewritten at every hop and never survives a router.
• The IP header answers which machine, anywhere. It survives end to end.
• The TCP header answers which program on that machine, and which byte of the conversation.
• HTTP answers what you actually wanted.

Get this wrong and you troubleshoot the wrong layer for an hour. Someone reports a site is down, you ping it, the ping succeeds, and you call the network fine. A ping only exercises layers 1 through 3. A working ping next to a dead page is not a contradiction, it is the normal signature of a transport or application problem.

Two models, and only one of them is running

The TCP/IP model has four layers and it is the one that exists as code in your operating system: Link, Internet, Transport, Application. OSI has seven: Physical, Data Link, Network, Transport, Session, Presentation, Application. Both get taught because the industry uses both, in different sentences.

The mapping is not complicated:

OSI                     TCP/IP          Example header on the wire
7 Application
6 Presentation   -->    Application     HTTP, DNS, DHCP
5 Session
4 Transport      -->    Transport       TCP, UDP
3 Network        -->    Internet        IPv4, IPv6
2 Data Link
1 Physical       -->    Link            Ethernet II, 802.11

Here is the part textbooks tend to mumble. OSI layers 5 and 6 do not exist as bytes. There is no session header and no presentation header to point at in a capture. They describe jobs that real protocols do inside their application-layer payload, or do not do at all. Do not go hunting for them in Wireshark.

So why keep OSI? Because the numbers are the working vocabulary of the field. "That is a layer 2 problem" means the frame is not reaching the next box. A "layer 3 switch" reads the IP header. A "layer 7 firewall" reads the HTTP request itself, not just the port. The number is shorthand for which header does this device read, and you will hear it on every incident call you ever join.

Reading the layers off a real frame

Install Wireshark (the current stable release is 4.6.7) and get a small, well known capture that has one HTTP request in it:

curl -L -o http.cap https://wiki.wireshark.org/uploads/27707187aeb30df68e70c8fb9d614981/http.cap

Open it with File > Open in the GUI, or use tshark, the command line version in the same package. Every command here reads the file with -r and touches nothing live:

tshark -r http.cap -c 5

That prints a one line summary of the first five frames. Frame 4 is the browser's GET. Now ask for the full decode of just that frame, restricted to the four protocols you care about:

tshark -r http.cap -Y "frame.number == 4" -O eth,ip,tcp,http

The output is the whole onion, outermost first. Stripped to the essentials it is this:

Frame 4: 533 bytes on the wire
  Ethernet II   14 bytes   src 00:00:01:00:00:00   dst fe:ff:20:00:01:00
  IPv4          20 bytes   src 145.254.160.237     dst 65.208.228.223
  TCP           20 bytes   src port 3372           dst port 80
  HTTP         479 bytes   GET /download.html HTTP/1.1
                ---------
                533 bytes

14 plus 20 plus 20 plus 479 is 533. Every byte on that wire is accounted for, and each row is one layer of the model you just read about. You can pull those same values out as plain fields, which is how you build a habit of naming a layer by the field that identifies it:

tshark -r http.cap -Y "frame.number == 4" -T fields -e frame.len -e eth.src -e ip.src -e tcp.srcport -e http.request.uri

Notice the prefixes: eth., ip., tcp., http.. Wireshark's field naming is itself a layer map. If you know which prefix a fact lives under, you know which layer owns the problem.

Two more frames sharpen the point. Frame 3 is only 54 bytes: same three headers, zero payload. It carries no data at all, just transport bookkeeping. Frame 1 is 62 bytes, because its TCP header is 28 bytes rather than 20: TCP headers carry optional fields, and this one uses eight bytes of them. Header sizes are floors, not constants.

Finally, get the shape of the whole file:

tshark -r http.cap -q -z io,phs

io,phs is the protocol hierarchy: it counts frames and bytes per protocol, nested exactly the way the layers nest. This capture holds 43 frames, 41 of them TCP and 2 UDP.

Try it

Work on http.cap and answer these four questions in writing, one line each.

1. For frame 6 (the start of the server's HTTP response), give the byte count of the Ethernet, IPv4 and TCP headers and of the payload, and show that they sum to the frame length.
2. The string www.ethereal.com appears in frame 4. Which layer holds it, and which layer holds 65.208.228.223?
3. Frame 4 goes out and frame 6 comes back. Which two header fields swap values between them, and which one field stays identical in both?
4. Run the protocol hierarchy command. Which layer accounts for the two UDP frames, and which application protocol is riding on them?

Success condition: your byte counts for question 1 add up exactly to the number tshark reports as the frame length, with no leftover bytes and nothing rounded. If you are off by 14, you forgot Ethernet. If you are off by 4, you counted an Ethernet FCS that the capture does not include.

Common mistakes

• Assuming header sizes are fixed. IPv4 headers are 20 bytes minimum and TCP headers are 20 bytes minimum. Frame 1 of this capture has a 28 byte TCP header. Read the length field, do not assume.
• Looking for OSI layers 5 and 6 in a capture. They have no headers. If an exercise asks you to identify the presentation layer in a frame, the honest answer is that it is a description of work done inside the application payload.
• Treating a successful ping as proof the network works. Ping is layer 3. It says nothing about whether a port is open or a service is answering. Say which layer your test actually covered.
• Confusing the two source addresses. A frame has a source MAC and a source IP and they answer different questions. The MAC changes at every router; the IP does not. Mixing them up is the single most common wrong answer in this phase.

Where this goes next

The next session, Ethernet, MAC, and ARP, drops to the bottom of the stack you just mapped and stays there: how a switch learns which MAC lives on which port, what a broadcast domain actually contains, and what question ARP is really asking when a host has an IP address but no frame it can send.