The TCP/IP Model — What's Actually Running

Networking Fundamentals

Chapter 3 · The TCP/IP Model — What's Actually Running

net1-2 covered OSI, the conceptual seven-layer reference model. This chapter is the model actually running underneath every network you've ever used — leaner, four layers instead of seven, and, unlike OSI, genuinely implemented rather than just referenced.

Why TCP/IP Won

OSI was designed as an actual protocol suite by an international standards committee, meant to be deployed, not just referenced. TCP/IP came out of DARPA-funded ARPANET research and was deployed and battle-tested in the real world starting in the 1970s and 80s. By the time OSI's own protocol suite was anywhere near finished, TCP/IP was already running the growing internet — a real-world deployment winning out over a more theoretically complete design that arrived too late to matter.

The Four (or Five) TCP/IP Layers

The classic model (RFC 1122) has four layers: Link, Internet, Transport, Application. Some material splits Link into separate Physical and Data Link layers, giving five — matching OSI's own bottom two directly. Both conventions are genuinely in use; neither is more "correct" than the other.

Mapped onto OSI: TCP/IP's Application layer absorbs OSI's Application, Presentation, and Session (layers 5–7). Transport matches OSI's Transport (layer 4) directly. Internet matches OSI's Network (layer 3) directly. Link absorbs OSI's Data Link and Physical (layers 1–2).

What Actually Runs at Each Layer

Link — Ethernet, Wi-Fi (802.11): framing and physical transmission.
Internet — IP (IPv4/IPv6): addressing and routing; ICMP (what ping uses) lives here too.
Transport — TCP and UDP, net1-7's own subject.
Application — HTTP, HTTPS, DNS, SSH, SMTP: every protocol a user-facing application actually speaks.

Revisiting the File Download Through TCP/IP's Lens

Same download from net1-2, now through TCP/IP's four layers instead of OSI's seven: Link (the Wi-Fi signal and frame addressing, collapsing OSI's layers 1–2), Internet (the destination IP address — unchanged from OSI's own layer 3), Transport (the TCP connection on port 443 — unchanged from OSI's own layer 4), Application (the HTTP GET request, with TLS handled inside this same layer rather than as a separate one).

That last point is the concrete resolution of net1-2's own warn-box: TCP/IP doesn't have separate homes for "session" and "presentation" concerns the way OSI describes them — protocols like TLS and HTTP simply handle those responsibilities themselves, folded into one Application layer.

Encapsulation — How Data Actually Gets Wrapped

A genuinely new mechanism this chapter adds: as data moves down the stack, each layer encapsulates the data from the layer above by wrapping it in its own header. An HTTP request becomes a TCP segment (a header carrying port information gets added), which becomes an IP packet (a header carrying address information gets added), which becomes an Ethernet frame (a header carrying MAC address information gets added). At the receiving end, this happens in reverse — each layer strips off its own header and passes the remaining payload up to the layer above.

HTTP request
  → wrapped in a TCP segment  (adds: source/destination port)
    → wrapped in an IP packet   (adds: source/destination IP address)
      → wrapped in an Ethernet frame (adds: source/destination MAC address)

This is the actual technical mechanism behind layering — not just a conceptual convenience, but literally how the bytes on the wire are structured.

TCP/IP layer	Matching OSI layer(s)	Real protocol example
Application	7, 6, 5 (Application, Presentation, Session)	HTTP, DNS, SSH
Transport	4 (Transport)	TCP, UDP
Internet	3 (Network)	IP, ICMP
Link	2, 1 (Data Link, Physical)	Ethernet, Wi-Fi

Layers 1-4 numbering is used interchangeably in practice

When someone in a firewall or security context says "Layer 3 and Layer 4 information," they mean IP addresses (layer 3) and ports (layer 4) — TCP/IP-flavored shorthand borrowing OSI's own numbering, since those four layers genuinely map cleanly between the two models.

You won't find a "session layer header" in a real packet

TCP/IP's own encapsulation only really produces four distinct header types — link, internet, transport, and application. Looking for a separate "session layer" header while examining a captured packet (net1-10's own tcpdump chapter) will come up empty — that concern, where it exists at all, is handled inside the application-layer data itself.

Hands-On Exercises

Exercise 1

Explain, in terms of real-world deployment rather than technical superiority, why TCP/IP became the internet's actual protocol suite instead of OSI's own.

📄 View solution

Exercise 2

Using this chapter's own encapsulation example, list the four headers that would exist around an HTTP request by the time it's actually transmitted, and name what information each one adds.

📄 View solution

Exercise 3

A colleague examining a packet capture asks where the "session layer header" is, expecting to find one distinct from the application data. Using this chapter's own warn-box, explain why they won't find one.

📄 View solution

Chapter 3 Quick Reference

TCP/IP: four layers — Link, Internet, Transport, Application (sometimes five, splitting Link)
TCP/IP's Application layer absorbs OSI's Application, Presentation, and Session (layers 5-7)
TCP/IP's Internet and Transport layers map directly onto OSI's Network (3) and Transport (4)
TCP/IP won out through real-world deployment, not because OSI was technically inferior
Encapsulation — each layer wraps the layer above's data in its own header on the way down, strips it on the way up
Only four real header types exist on the wire: link, internet, transport, application