TCP/IP Model Explained: The 4 Layers, OSI Mapping, and How Data Actually Moves

What the TCP/IP model actually is (and why it has 4 layers, not 7)

The TCP/IP model is not a design philosophy someone dreamed up on a whiteboard. It is a description of the protocol suite that was already running the early internet, written down by the IETF as RFC 1122, “Requirements for Internet Hosts — Communication Layers”, in October 1989. That ordering matters: RFC 1122 codifies the link, internet, and transport layers, with its companion RFC 1123 covering the application layer — four layers total, defined after the protocols already worked.

The OSI model ran the opposite direction. ISO/IEC 7498-1, first published in 1984, was a prescriptive standard: seven layers designed first, with the intent that real protocols would be built to fit them. Almost none were, at internet scale — TCP/IP won the market instead. That is the real reason the two models don't line up cleanly: one describes what shipped, the other prescribes what a committee thought should ship.

So when you see TCP/IP model explained guides that treat the two models as interchangeable synonyms for “network layers,” that's the first inaccuracy to unlearn. They're answering different questions — OSI: how should a network be layered; TCP/IP: how does the internet actually work.

The 4 TCP/IP layers explained: Link, Internet, Transport, Application

Each layer solves one problem and hands the result to the layer above it. Here's what each one owns, in RFC 1122's own terms, plus the header size you'll actually see on the wire — useful the moment you open a packet capture and need to know how many bytes to skip.

Link layer: framing and local delivery

The link layer moves frames across a single physical segment — it never sees an IP address. An Ethernet II frame is a fixed 14-byte header (6-byte destination MAC, 6-byte source MAC, 2-byte EtherType) followed by the payload and a 4-byte frame check sequence. This is also where the classic “switching vs. routing” mix-up starts: switching is link-layer forwarding inside one broadcast domain; routing is an internet-layer job between networks. If a device can't resolve a MAC address for a host on the same subnet, ARP — not IP — is where to look.

Internet layer: IP, addressing, and routing

The internet layer's entire job is getting a packet from any source to any destination across an arbitrary number of intermediate networks, without either endpoint knowing the topology in between. IPv4 and IPv6 provide the addressing; ICMP carries the control messages (unreachable, TTL exceeded) that make traceroute and ping possible. A minimum IPv4 header is 20 bytes; IPv6's fixed header is a flat 40 bytes with extension headers appended when needed, which is why IPv6 packet math looks different in a capture than IPv4.

Transport layer: TCP vs. UDP, in the numbers that matter

TCP and UDP solve the same problem — getting data to the right process via a port number — with opposite trade-offs.

Port numbers fall into three IANA-defined ranges: well-known (0–1023, e.g. 443 for HTTPS), registered (1024–49151), and dynamic/private (49152–65535) — the range your OS pulls ephemeral source ports from for outbound connections. When you see a capture with a source port like 54213 talking to destination port 443, that's a client's ephemeral port initiating an HTTPS connection.

Application layer: where the protocols you name every day live

HTTP/HTTPS, DNS, SMTP, and SSH all sit here, using the transport layer's ports to reach the right process. This is also the layer where a growing number of AI-crawler-facing conventions live: robots.txt for crawl permissions, and the newer llms.txt convention some sites publish so AI answer engines can find a clean, structured summary of their content — both are plain-text files served over HTTP, nothing more exotic than that. If you're setting one up, Netalith's free llms.txt generator builds a valid file in the format AI crawlers expect.

TCP/IP vs OSI model mapping: the full layer table

This is the table most people actually came here for. The honest version has to admit the mapping isn't perfectly clean — TCP/IP's Application layer absorbs three separate OSI layers, because in practice, presentation (data formatting, encryption) and session (dialog management) functions ended up living inside libraries and application code — TLS handles presentation-layer concerns, HTTP/2 and application protocols handle session state — rather than as protocols with their own headers.

Use it to translate between vendor docs and packet captures: a Wi‑Fi association failure is Link/Layer 1–2, a routing loop is Internet/Layer 3, and a stalled connection with no data flowing can be Transport (Layer 4) or Application (Layer 5–7) depending on which side stopped responding.

Why people still say “Layer 7 firewall” in a TCP/IP world

Here's the nuance most explainers skip: the internet runs on the 4-layer TCP/IP model, but the industry talks about it almost entirely in OSI's 7-layer numbers. A “Layer 4 load balancer” routes on IP and port — TCP/IP's transport layer. A “Layer 7 firewall” inspects application content — TCP/IP's application layer, but OSI's number 7. Nobody implements OSI's session or presentation layers as literal protocol layers; the numbering survives purely as shorthand because it gives finer granularity for describing where in the stack a device or rule operates, even in gear that only implements TCP/IP end to end.

A second point of genuine confusion: many certification courses (CompTIA Network+, some Cisco material) teach a “5-layer TCP/IP model” that splits Link into separate Physical and Data Link layers, producing something that looks like a hybrid of both models. That's a pedagogical simplification, not RFC 1122's architecture — the canonical IETF document defines four layers, with Link covering both framing and physical transmission. Neither version is “wrong” for its purpose, but if a source cites RFC 1122 and says five layers, that's the tell it's paraphrasing secondhand rather than the original spec.

Encapsulation in TCP/IP: how a browser request becomes bits on a wire

Encapsulation is each layer wrapping the layer above it's data with its own header, without needing to understand what's inside. Here's what happens, with real header sizes, when a browser loads a page over HTTPS:

1. Application: the browser builds an HTTP request, wrapped in TLS for HTTPS. No fixed header size — length depends on the request and the TLS record.
2. Transport: TCP wraps it in a segment with a 20-byte (minimum) header carrying source/destination ports, sequence and acknowledgment numbers, and flags.
3. Internet: IP adds a 20-byte (IPv4) or 40-byte (IPv6) header with source/destination addresses and a TTL/hop limit.
4. Link: Ethernet wraps the whole thing in a 14-byte frame header (destination MAC, source MAC, EtherType) plus a 4-byte trailer.

Link:        Ethernet Frame  [ dst MAC | src MAC | EtherType | ... | FCS ]
Internet:      IP Packet     [ src IP | dst IP | TTL | protocol | ... ]
Transport:       TCP Segment [ src port | dst port | seq | ack | flags ]
Application:       Data      [ TLS record + HTTP request ]

Each layer only reads its own header and passes the rest along unopened — a switch never looks at the IP header, and a router never looks at the TCP header. On receipt, the destination host decapsulates in the reverse order: Link → Internet → Transport → Application, stripping one header at a time until only the original HTTP request is left.

Reading TCP/IP layers in a real packet capture (tcpdump and Wireshark)

Theory sticks better once you've matched it against real bytes. tcpdump is the fast, scriptable option for servers; Wireshark gives you the same data with full protocol decoding.

sudo tcpdump -i eth0 -nn -s 0 'tcp port 80 or tcp port 443' -w capture.pcap

Open capture.pcap in Wireshark and click any packet — the pane on the left shows the four layers stacked exactly as encapsulation built them, outermost first:

• Frame / Ethernet II: source/destination MAC, EtherType, any VLAN tag
• Internet Protocol: source/destination IP, TTL, fragmentation flags
• TCP or UDP: ports, sequence numbers, flags (SYN/ACK/FIN/RST), retransmission markers
• Application protocol: decoded HTTP headers, DNS query/response, or TLS handshake details

A quick tell for where a connection is failing: if you see repeated SYN packets with no SYN-ACK reply, the problem is at or below Transport (firewall, routing, or the server not listening on that port) — it never reached Application at all.

Troubleshooting by layer: a faster way to isolate network problems

Working top-down from the visible symptom wastes time, because the symptom usually shows up at Application regardless of where the actual fault is. Working bottom-up through the layers isolates the fault faster:

• Link: is the interface up? Check link status, Wi‑Fi association, switch port state, and interface error/drop counters.
• Internet: confirm IP address, subnet mask, and default gateway; test reachability with ping and trace the path with traceroute.
• Transport: confirm the port is actually reachable — nc -vz host 443 — and check firewall/NAT state tables for drops.
• Application: validate DNS resolution (dig), check the service's own logs, and confirm certificates are valid for HTTPS.

If Link, Internet, and Transport all check out clean but the application still fails, you've correctly ruled out three-quarters of the stack — the fault is application logic, DNS, or a certificate, not the network.

Common misconceptions about the TCP/IP model

• “TCP/IP has 5 layers.” RFC 1122's canonical model has 4. The 5-layer version taught in some certifications splits Link into Physical and Data Link for teaching convenience — useful, but not the original spec.
• “OSI and TCP/IP are competing models you have to pick one of.” In practice the internet runs on TCP/IP end to end, while the industry uses OSI's layer numbers as shorthand for where a device or problem sits. Both live in the same conversation constantly.
• “Session and Presentation layers don't exist in the real world.” Their functions exist — TLS handles presentation-layer concerns like encryption and formatting, and session state is managed inside application protocols and libraries — they just never became separate protocol layers with their own headers on the internet.
• “The TCP/IP model is a protocol.” It's a description of how existing protocols (IP, TCP, Ethernet, and so on) relate to each other — not something you implement or install on its own.

Conclusion: what to practice next

The TCP/IP model is four layers — Link, Internet, Transport, Application — defined by RFC 1122 to describe protocols that already worked, which is why it maps only loosely onto OSI's seven prescriptive layers. The fastest way to make this stick is to capture a short browsing session with tcpdump, open it in Wireshark, and walk one connection from the Ethernet frame down to the decoded HTTP request — then deliberately break something (block a port, unplug the cable, misconfigure DNS) and use the layer table above to predict, before you look, which layer will show the failure.

Netalith is an engineering-led team that also builds the AI-visibility and agent-readiness layer on top of the networking fundamentals covered here — things like llms.txt, structured markup, and making a site's content legible to AI crawlers and answer engines. If that's relevant to what you're building, you can see the full picture on the Netalith homepage.