TCP/IP and Encapsulation: How Data Actually Travels

TCP/IP and Encapsulation: How Data Actually Travels

What you'll learn

• Describe the four layers of the TCP/IP model and map them onto the OSI layers you know
• Trace a web request through encapsulation: data → segment → packet → frame → signals
• Read a header as a small database of fields, and explain what the Protocol field decides
• Place ICMP at its correct layer (a classic exam trap, corrected from the textbook)
• Capture your first real network traffic and recognize frames, packets and segments inside it

This lesson builds on Chapters 2 and 5 of Dr. Tahseen Al-Doori's Network Essentials: Chapter 2 supplies the encapsulation walk-through and the "headers are small field databases" idea; Chapter 5 supplies the TCP/IP model itself. The lab modernizes the book's own Chapter 2 exercise — installing a protocol analyzer and looking inside real headers.

The model that won: four layers

The OSI model is a reference — a way of talking. The software in your laptop, your phone and every router on the Internet follows a different, older, more compact design: the TCP/IP model, developed for the U.S. Department of Defense (you will still see it called the DoD model). The name is slightly cheeky: TCP and IP are just two protocols among dozens in the family — but they are the two stars the others orbit, so the suite took their names.

The classic TCP/IP model has four layers:

Read the right-hand column carefully and the previous lesson's "honest notes" click into place: TCP/IP simply refuses to pretend that session and presentation are separate software layers, folding them into the application layer, and it treats local delivery and signaling as one Network Access layer. Nothing you learned is wasted — the OSI numbers remain the industry's shared vocabulary ("a layer 3 problem"), while TCP/IP describes what is actually running.

One friendly warning: authors slice this cake differently. Some teach a five-layer version that splits Network Access back into Data Link and Physical. Same machinery, different slicing — you will meet a five-layer variant in this lesson's video, with a mapping note waiting for you there.

Encapsulation: the envelope story

A classic analogy from Dr. Al-Doori's course begins with a question: why can't you drop a bare letter into a mailbox? Because the postal service doesn't read letters — it reads envelopes. Without an envelope carrying a destination address, a return address and a stamp, your letter is just paper; no carrier knows where it should go, and no one can return it if delivery fails.

Data on a network works the same way. Raw data dumped onto a wire is worthless; it must be wrapped with delivery information the network can act on. That wrapping is called encapsulation: as your data descends the stack, each layer places it inside its own "envelope" by attaching a header — a block of delivery and handling information for that layer's counterpart on the far side. The receiving computer performs de-encapsulation: each layer opens its envelope, acts on the header, and passes the contents up.

Each wrapping stage has a name — these are the parcels (formally, protocol data units) from the previous lesson, now in action:

• The application produces data.
• The transport layer wraps it into a segment (TCP) or datagram (UDP), adding port numbers.
• The internet layer wraps the segment into a packet, adding IP addresses.
• The network access layer wraps the packet into a frame, adding MAC addresses (plus a trailer with an error check), and turns the whole thing into bits — signals on the medium.

Envelope inside envelope inside envelope: the frame carries the packet, the packet carries the segment, the segment carries your data. Local equipment reads only the outermost envelope; each deeper envelope is meant for a reader further along the journey.

A web request, layer by layer

Let's send something real. You type a web address and press Enter.

Application. Your browser composes an HTTP request — the actual message. (In the book's 2007 walk-through the request travels to server port 80, plain HTTP; today the web defaults to HTTPS, the TLS-encrypted version on port 443. The journey below is identical either way.)

Transport. TCP takes the request and prepares reliable delivery. It splits the data into segments and stamps each with a transport header carrying two port numbers: the destination port (443 — "this is for the web server program") and a source port, a temporary number identifying your browser's conversation, so the reply can find its way back to the right tab among everything your machine is doing. TCP also opens the connection with its three-way handshake — the layer-4 exchange you placed correctly last lesson.

Internet. IP wraps each segment into a packet whose header carries the source IP address (yours) and the destination IP address (the server's). Routers along the path read exactly this envelope — nothing deeper — to move the packet from network to network across the world.

Network Access. Your machine builds a frame around the packet, stamped with its own MAC address as source. And here is the detail that makes the two-address system click: the destination MAC is usually not the web server's — it is your default gateway's, the router that leads out of your local network. MAC addresses only ever deliver across one local hop; IP addresses span the journey end to end. At every hop along the path, the frame is stripped and rebuilt with fresh MAC addresses, while the IP packet inside rides on with its end-to-end addresses unchanged — only its TTL is decremented (and the header checksum recomputed) by each router. The frame's bits become signals, and your request is gone.

At the server, the film runs backward — up the stack: the NIC converts signals to bits and checks the frame's MAC ("for me?"), IP checks the destination address ("mine"), TCP reads the destination port and finds the web server program listening there, and the application finally reads your request. Notice the elegant symmetry: down the stack on the sender, across the wire, up the stack on the receiver.

One more idea, worth naming because you will see it everywhere: each layer communicates with two parties at once. It serves the layer above it on its own machine (adjacent-layer interaction), and it writes headers read by its counterpart on the other machine (same-layer interaction). Your TCP converses with the server's TCP; neither ever touches a wire — the layers below carry their conversation.

Headers are small field databases

Chapter 2 offers a picture worth keeping for life: a header is a small database of fields. Each header is divided into named fields; each field holds a value; the receiving stack looks up those values to decide exactly how to handle the payload. A simplified IPv4 header:

Dwell on Protocol for a moment — it is the field database at its best. The number 6 tells the receiving internet layer: "hand this payload to TCP." A 17 routes it to UDP instead. And a 1 means the payload is an ICMP message — the network's own error-and-diagnostics messenger, the protocol behind ping.

That last value settles a correction flagged in the previous lesson. A protocol table in the book's Chapter 5 lists ICMP beside TCP and UDP at the transport layer — a placement you will also meet in older exam-prep material. The definitive answer sits in that header field: ICMP messages ride directly inside IP packets as protocol 1. ICMP has no ports and delivers nothing to applications; it is IP's network-layer companion (defined in RFC 792), not a transport protocol. Interviewers love this trap. You are now immune.

From the textbook to 2026

The remarkable thing about this lesson's content is how little modernization it needs. Encapsulation works today exactly as the book taught in 2007 — this layer cake is the stable core of networking, which is precisely why it anchors the course. Three time-stamps for your mental model: the IPv4 header field the book calls Type of Service is today's DSCP field, still doing the same job of prioritizing delay-sensitive traffic; the example web request has moved from cleartext HTTP on port 80 to encrypted HTTPS on port 443 (current); and the ICMP placement above reflects the modern standard, corrected plainly. Everything else you just learned is 2026 practice, unchanged.

Watch: How the TCP/IP Model Actually Works

Why this video earns its place. "How the TCP/IP Model Actually Works" comes from Jeremy's IT Lab, the most widely recommended free networking video course in the industry's study communities. This particular lesson is a ground-up remake, published in late 2025, of his classic TCP/IP lecture — rebuilt, in the author's own words, to be more accurate, more practical and easier for beginners. Its animated encapsulation sequences add moving pictures to the walk-through you just read: you can watch the headers stack up and peel off. It runs about forty-three minutes.

As you watch, notice:

• The moment each layer adds its header on the way down and removes it on the way up — the same descent and climb as our web-request walk-through.
• The parcel names — segment, packet, frame — appearing exactly where this lesson placed them.
• The distinction he draws between adjacent-layer interaction (serving the layer above, on the same machine) and same-layer interaction (writing headers for your counterpart across the network) — the "two parties at once" idea from our walk-through.
• His comparison between the TCP/IP model and the OSI model, which ties this lesson back to the previous one.
• The exam-oriented framing: the video is built for Cisco CCNA preparation, so some emphasis (layer-numbering conventions, certification terminology) goes beyond what an introduction needs. Enjoy it as a preview of professional study, not as extra homework.

A mapping note before you press play. The video teaches a five-layer TCP/IP variant: Physical, "Local Network," Internet, Transport, Application. Our classic four-layer model simply merges his bottom two — Physical and Local Network — into the single Network Access layer, and his "Local Network" layer is what most other materials (and our OSI lesson) call the Data Link layer. Same machinery, different slicing, as promised earlier: whenever he says "Local Network layer," think "the frame-and-MAC part of Network Access." Nothing else differs.

The video reinforces visually what you just learned — the lesson is complete without it.

Lab: Your First Wireshark Capture (observe-only)

Time to see all of this for real. Wireshark is the industry's standard protocol analyzer — a free program that records the traffic reaching your network interface and dissects every captured frame, envelope by envelope. This lab is observe-only: you will change nothing on your network, just look. It is the book's own Chapter 2 exercise, modernized.

Objective. Capture about a minute of your own traffic and identify, inside a single captured unit, the frame (MAC addresses), the packet (IP addresses) and the segment (ports) — encapsulation, seen with your own eyes.

Setup.

• Any computer where you may install software, connected to a working network.
• Windows. Download the Wireshark installer from wireshark.org/download and run it. When the installer offers Npcap — the capture driver Wireshark depends on — accept it with its default options. Accept all other defaults.
• Linux. Install from your distribution's repositories: sudo apt install wireshark on Debian/Ubuntu (answer Yes when asked whether non-superusers should be able to capture), or sudo dnf install wireshark on Fedora. Then allow your account to capture: sudo usermod -aG wireshark $USER, and log out and back in so the group change takes effect.
• Close applications you don't need — a quieter machine makes a more readable capture.

Steps.

1. Open Wireshark. The welcome screen lists your network interfaces, each with a small live activity graph beside it.
2. Find your active interface — the one whose graph is visibly moving. On a laptop this is usually the Wi-Fi interface; on a desktop, Ethernet.
3. Make sure the capture-filter box above the interface list is empty.
4. Double-click the active interface. The capture begins: lines start scrolling, one per captured frame.
5. Generate some traffic. Open a browser and visit two or three websites. Then open a terminal (Command Prompt on Windows) and run ping example.com (on Linux, ping -c 4 example.com to limit it to four attempts). The ping plants ICMP traffic in your capture — the next lesson's activity will hunt for it.
6. After about a minute, return to Wireshark and click the red square (Stop) in the toolbar.
7. Click any line whose Protocol column reads TCP. Look at the middle pane — the packet details. You should see stacked, expandable bands, outermost envelope first — typically: Frame (capture metadata), Ethernet II (the real frame header), Internet Protocol Version 4, and Transmission Control Protocol.
8. Expand Ethernet II: source and destination MAC addresses — the local-hop envelope.
9. Expand Internet Protocol Version 4: source and destination IP addresses, TTL — and find the Protocol field showing 6 (TCP). That is the "small database" field from this lesson, live on your screen.
10. Expand Transmission Control Protocol: the source and destination ports steering this conversation to the right application.
11. Glance at the bottom pane: the raw bytes of the frame — the actual 1s and 0s that were signals on your medium moments ago.
12. Save your work: File → Save As, name it first-capture (Wireshark adds its own extension). The next lesson's activity reuses this file.

Expected result. Hundreds to thousands of lines, in columns (No., Time, Source, Destination, Protocol, Length, Info). A healthy capture mixes protocols — expect TCP, TLS, DNS, UDP, ICMP (your ping) and a few others such as ARP. The details pane of any TCP line shows the nested bands in encapsulation order, outermost first.

Verify. You can point, in one single captured unit, at: a MAC address pair (Ethernet II band), an IP address pair (IPv4 band) and a port pair (TCP band) — and you can say which envelope is whose. Your capture file is saved.

Questions.

1. Wireshark lists Ethernet II above IPv4 in the details pane, yet the previous lesson called IP the "higher" layer. Reconcile the two.
2. On packets leaving your machine for websites, whose MAC address appears as the destination — and why is it not the web server's?
3. Find one packet sent to your machine. How have the source and destination addresses changed compared with a packet you sent?
4. The IPv4 Protocol field of your ping traffic reads 1 rather than 6. What does that tell you about where ICMP lives in the stack?

(Answers: 1 — the details pane shows envelopes outermost-first, the order they exist on the wire, so the frame that wraps everything appears at the top; the "higher" layer is the inner envelope. 2 — your default gateway's, because MAC addresses deliver only across the local hop while IP addresses span end to end. 3 — both pairs are mirrored: the far side's addresses are now the source, yours the destination. 4 — ICMP rides directly inside IP as protocol 1, confirming it is a network-layer companion of IP, not a transport protocol.)

If it goes wrong.

• No interfaces listed, or "you don't have permission to capture." Windows: Npcap is missing or was declined — re-run the Wireshark installer and accept Npcap. Linux: the group change hasn't taken effect — confirm with groups that wireshark is listed, and log out and back in (a full reboot also works).
• The capture runs but shows zero packets. Almost always the wrong interface: stop, return to the welcome screen, and pick the one with the moving graph. Also check that no leftover text sits in the capture-filter box.
• You see only your own traffic and broadcasts. Normal, not a failure. Modern switches create point-to-point micro-segments, so your port receives only frames addressed to you or to everyone (broadcast frames, destination ff:ff:ff:ff:ff:ff).
• Wi-Fi capture shows nothing on Windows. Some wireless adapters and driver combinations restrict capture. Simplest fixes: use a wired connection for this lab if one is available, or re-run the installer to repair Npcap with default options.
• The scrolling is overwhelming. Stop the capture and scroll at your own pace — analysis happens on stopped captures. Module 8 teaches display filters that tame the flood professionally.

Reset/cleanup. Stop the capture and close Wireshark; nothing on your system or network was changed. Keep first-capture for the next lesson. One professional habit from day one: a capture file records your network activity — the sites you visited, your device addresses — so treat it like a private document. Don't share it, and delete it when Module 2 is done.

Check yourself

1. A capture line reads — Source 192.168.1.23, Destination 142.250.80.46, Protocol TCP, Info 51742 → 443 [SYN]. Which layer's envelope carries the two numbers in the Info column, and which layer's envelope carries the two dotted addresses?
2. In an IPv4 header the Protocol field reads 17. Which protocol receives the payload, and why does the receiving stack need this field at all?
3. Put these in the order they are wrapped when your machine sends data: frame, segment, application data, packet. Then give the order in which the receiver opens them.
4. Your capture shows a frame with destination ff:ff:ff:ff:ff:ff. What kind of delivery is this, and which layer's addressing is being used?
5. A study partner says: "Ping uses ICMP, and ICMP is listed with TCP and UDP in my old notes, so it's a transport protocol." Correct them using evidence you personally saw in this lesson's lab.
6. Why would the same IP packet be carried by several different frames during its journey from your laptop to a server three networks away?

Answers

1. The port numbers (source port, destination port 443) live in the transport-layer envelope — the TCP segment header. The dotted IP addresses live in the internet-layer envelope — the IP packet header.
2. UDP (17 = UDP, just as 6 = TCP and 1 = ICMP). Without the Protocol field, the internet layer would have no way of knowing which transport protocol's rules govern the payload — the header field is the dispatch instruction.
3. Sending (wrapping): application data → segment → packet → frame. Receiving (opening): frame first, then packet, then segment, then the data — each layer opens its own envelope and passes the contents up.
4. A broadcast — a frame addressed to every device on the local network. The all-ones destination is a MAC address, so this is network-access (data link) layer addressing.
5. In the lab, ping traffic showed IPv4's Protocol field carrying 1 with the ICMP message directly inside the IP packet — no TCP or UDP band, no ports anywhere. A protocol with no ports that rides directly in IP is a network-layer protocol; the transport-layer listing in older tables (including one in our textbook) is a known erratum.
6. Frames only cross one local hop: at every router, the arriving frame is stripped off and a new frame — with fresh source and destination MAC addresses for the next hop — is built around the same IP packet, whose end-to-end addresses never change.

Key terms

• TCP/IP (DoD) model — the four-layer model real networks run: Application, Transport, Internet, Network Access.
• Encapsulation / de-encapsulation — wrapping data with each layer's header on send; opening the envelopes in reverse on receive.
• Header — a layer's block of named fields ("a small database of fields") instructing its counterpart how to handle the payload.
• Trailer — the error-check block appended at the end of a frame.
• Segment / datagram — the transport layer's parcel (TCP / UDP respectively), carrying port numbers.
• Port — a transport-layer number identifying which application a conversation belongs to.
• Default gateway — the router leading out of your local network; the usual destination MAC for outbound frames.
• Protocol field — the IPv4 header field naming the payload's protocol: 6 = TCP, 17 = UDP, 1 = ICMP.
• DSCP — today's name for the IPv4 priority field the book's era called Type of Service.
• ICMP — IP's network-layer companion for errors and diagnostics; the protocol behind ping.
• Wireshark — the standard protocol analyzer; captures traffic and dissects every envelope.
• Broadcast frame — a frame addressed to all local devices (destination all-ones MAC).

Summary

• The TCP/IP model — Application, Transport, Internet, Network Access — is what networks actually run; OSI remains the vocabulary.
• Encapsulation wraps data down the stack: data → segment (ports) → packet (IP addresses) → frame (MAC addresses) → signals; de-encapsulation reverses it on arrival.
• IP addresses are end-to-end; MAC addresses are one-hop-only — so outbound frames usually target your default gateway, and frames are rebuilt at every router while the packet rides unchanged.
• Headers are small field databases: named fields whose values (like Protocol = 6) tell the receiving stack exactly what to do.
• ICMP rides inside IP as protocol 1 — a network-layer protocol, despite older tables placing it at transport.
• The book's Type of Service field is today's DSCP; the web's default moved from port 80 cleartext to port 443 TLS; the encapsulation machinery itself is unchanged since 2007.
• You captured live traffic and identified frame, packet and segment inside a single captured unit — the course's practical spine begins here.

Next lesson

You have watched the envelopes; now for the etiquette. The final lesson of this module asks what the rules themselves are made of — starting from a phone call you have made a thousand times — and sends you back into today's capture to identify three protocols by name.

Sources and further study

• Al-Doori, T., Network Essentials, Chapters 2 and 5 — encapsulation, headers-as-databases, and the TCP/IP model.
• RFC 791, "Internet Protocol" — https://www.rfc-editor.org/rfc/rfc791.html — the IPv4 packet and its header fields.
• RFC 792, "Internet Control Message Protocol" — https://datatracker.ietf.org/doc/html/rfc792 — ICMP as IP's network-layer companion.
• RFC 9293, "Transmission Control Protocol (TCP)" — https://www.rfc-editor.org/info/rfc9293/ — the current TCP specification.
• Wireshark Wiki, "CaptureSetup" — https://wiki.wireshark.org/CaptureSetup — official guidance for capture problems beyond this lab's fixes.
• Download: OSI and TCP/IP Model Reference — keep both models at your elbow for the rest of the course.