The TCP/IP Model
The 4-layer model that actually runs the internet
What Is the TCP/IP Model?
The TCP/IP model (also called the Internet Protocol Suite) is the practical, implementation-driven networking model that powers the actual internet. Unlike the OSI model, which was designed by committee as a theoretical framework, TCP/IP was developed by DARPA researchers (Vint Cerf and Bob Kahn) in the 1970s by building working software first and describing the model after.
The Core Philosophy
TCP/IP follows the end-to-end principle: keep the network core simple (just forward packets) and push complexity to the endpoints. The network doesn't need to understand what's inside your packets — it just delivers them. This is the opposite of the telephone network (circuit-switched), where the network manages the entire call state.
Note
Naming: "TCP/IP" refers to the two most important protocols in the suite (TCP at the transport layer, IP at the internet layer), but the model encompasses hundreds of protocols. The more precise name is the "Internet Protocol Suite."
The 4 Layers
Warning
Layer numbering: Some references number TCP/IP layers 1-4 (as above). Others skip numbering and just use names. There is no official numbering standard for TCP/IP layers — unlike OSI where "Layer 3" always means Network. When people say "Layer 4 load balancer," they mean OSI Layer 4 (Transport), not TCP/IP layer 4 (Application). Industry always uses OSI numbering.
Layer-by-Layer Deep Dive
Layer 1 — Link (Network Access)
What It Does
Combines OSI Layers 1 and 2 into a single layer that handles everything required to send a frame across a single physical link. The TCP/IP model deliberately treats this as opaque — the upper layers don't care whether you're running on Ethernet, Wi-Fi, cellular, or carrier pigeon.
- Frames packets for the specific physical medium
- Handles hardware (MAC) addressing for local delivery
- Manages media access, error detection, and physical signaling
- Provides ARP (IPv4) or NDP (IPv6) for address resolution
Tip
Why combine L1 and L2? The TCP/IP architects didn't think the distinction between "signaling voltages on a wire" and "framing bits into Ethernet frames" was important for the model. To IP, a link is a link — it either delivers a frame to the next hop or it doesn't.
| Protocol / Technology | Scope | Description |
|---|---|---|
Ethernet (802.3) | LAN | Dominant wired technology; frame-based with MAC addressing |
Wi-Fi (802.11) | WLAN | Wireless frames with CSMA/CA media access |
ARP | LAN | Maps IPv4 addresses to MAC addresses via broadcast |
NDP (ICMPv6) | LAN | IPv6 equivalent of ARP — uses multicast instead of broadcast |
PPP | Point-to-point | Used on serial links, DSL, some VPN tunnels |
802.1Q | LAN | VLAN tagging for logical network segmentation |
Layer 2 — Internet
What It Does
The heart of the model. Responsible for addressing, routing, and forwarding packets across network boundaries. IP is the single protocol at this layer, and everything above and below must interface with it. This is the "narrow waist" of the hourglass.
- Logical addressing: IP addresses provide globally unique, hierarchical identifiers
- Routing: Each router independently makes a forwarding decision based on the destination IP
- Best-effort delivery: IP makes no guarantees — packets can be dropped, duplicated, or reordered
- Fragmentation: Breaks oversized packets (though Path MTU Discovery avoids this in practice)
Note
Best-effort: IP intentionally provides no reliability, no ordering, and no delivery guarantees. This is a feature, not a bug. It keeps the network layer simple and pushes reliability to the endpoints (TCP) — exactly per the end-to-end principle.
| Protocol | Description |
|---|---|
IPv4 | 32-bit addressing, header checksum, optional fragmentation |
IPv6 | 128-bit addressing, simplified header, no fragmentation by routers, flow labels |
ICMP / ICMPv6 | Error reporting and diagnostics (ping, traceroute, destination unreachable) |
IGMP / MLD | Multicast group management (IPv4 / IPv6 respectively) |
IPsec | Encryption (ESP) and authentication (AH) at the network layer |
Layer 3 — Transport
What It Does
Provides end-to-end communication between processes. Uses port numbers (16-bit, 0-65535) to demultiplex traffic to the correct application on a host. The two dominant protocols offer very different trade-offs.
- Connection-oriented: 3-way handshake (SYN, SYN-ACK, ACK)
- Reliable: Sequence numbers, ACKs, retransmission
- Ordered: Data delivered in sequence
- Flow control: Receiver advertises window size
- Congestion control: CUBIC (Linux default), BBR (Google)
- Byte-stream: No message boundaries
- 20-byte minimum header
- Connectionless: No handshake, no state
- Unreliable: No ACKs, no retransmission
- Unordered: Packets may arrive out of order
- No flow control: Sender can blast at any rate
- No congestion control: Unless the app implements it
- Message-oriented: Preserves datagram boundaries
- 8-byte header (minimal overhead)
QUIC — The Modern Hybrid
QUIC (used by HTTP/3) is a transport protocol built on top of UDP that provides TCP-like reliability with significant improvements:
- Encrypted by default (TLS 1.3 integrated into the transport)
- 0-RTT connection establishment (vs TCP's 1-RTT + TLS 1-2 RTT)
- Multiplexed streams without head-of-line blocking
- Connection migration (change IPs without dropping the connection — useful for mobile)
- Implemented in userspace, not the kernel — faster iteration
Layer 4 — Application
What It Does
Absorbs OSI Layers 5, 6, and 7 into a single layer. Any protocol that sits on top of TCP or UDP lives here. This layer handles session management, data encoding, encryption, and application semantics — all combined.
| Protocol | Transport | Port(s) | Description |
|---|---|---|---|
HTTP/1.1 | TCP | 80 | Text-based request/response protocol for the web |
HTTP/2 | TCP | 443 | Binary framing, multiplexing, server push, header compression |
HTTP/3 | QUIC (UDP) | 443 | HTTP over QUIC — eliminates TCP head-of-line blocking |
DNS | UDP (TCP for zone transfers) | 53 | Domain name to IP resolution |
SSH | TCP | 22 | Secure remote shell, tunneling, file transfer |
TLS 1.3 | TCP | 443 | Transport-layer encryption (OSI would call this L5/L6) |
DHCP | UDP | 67/68 | Dynamic IP configuration (DORA: Discover, Offer, Request, Ack) |
SNMP | UDP | 161/162 | Network device monitoring |
gRPC | HTTP/2 (TCP) | varies | Google's RPC framework using Protocol Buffers |
BGP | TCP | 179 | Border Gateway Protocol — inter-AS routing (often considered L3 in OSI) |
Note
Note: In TCP/IP, there's no distinction between "application protocol" and "presentation/session protocol." TLS, which OSI would split across L5-L6, is just another application-layer protocol in TCP/IP that sits between the transport and the higher application protocols (HTTPS = HTTP + TLS).
OSI vs. TCP/IP — Side by Side
| OSI Layer(s) | TCP/IP Layer | What Changed |
|---|---|---|
| 7 + 6 + 5 | Application | Session and Presentation were rarely implemented as separate layers — merged into Application |
| 4 | Transport | Direct 1:1 mapping — both define TCP and UDP |
| 3 | Internet | Direct 1:1 mapping — both define IP |
| 2 + 1 | Link | TCP/IP treats everything below IP as a single "link" — doesn't care about physical vs data link distinction |
The Hourglass Model — IP as the Narrow Waist
The TCP/IP architecture has a distinctive hourglass shape. There are many application protocols on top, many link technologies on the bottom, but only one protocol in the middle: IP.
Why the Narrow Waist Matters
- Universal interoperability: Any application that speaks IP can run over any link technology. HTTP doesn't care if you're on Ethernet, Wi-Fi, or 5G.
- Innovation at the edges: New application protocols (HTTP/3, gRPC) and new link technologies (5G, Starlink) can be added without changing IP.
- The cost: Changing IP itself is extraordinarily hard — IPv6 adoption has taken decades precisely because IP is the narrow waist everything depends on.
Tip
DevOps context: The hourglass model explains why container networking "just works" across different environments. Containers speak IP. Whether the underlying link is a VXLAN overlay, a cloud VPC, or bare-metal Ethernet — IP abstracts it all away. This is also why Kubernetes networking mandates that every pod gets a routable IP address.
Why TCP/IP Won Over OSI
- Built by implementors: Designed by engineers building ARPANET, refined through working code
- Running code first: "Rough consensus and running code" (IETF motto)
- Free and open: RFCs are free, implementations in BSD Unix were open source
- Simple: 4 layers, minimal assumptions, pragmatic design
- BSD sockets API: Shipped with 4.2BSD Unix (1983) — immediate adoption by every Unix system
- Funded by DARPA: Government funding kickstarted adoption in universities
- Built by committee: ISO standardization process — slow, political, bureaucratic
- Spec first, then implement: Massive specifications before working code existed
- Expensive: Standards documents cost money, implementations were proprietary
- Complex: 7 layers with multiple protocol options at each layer
- Late to market: By the time OSI protocols were ready, TCP/IP had already won
- Feature creep: Tried to be everything to everyone, ended up pleasing no one
Note
Historical irony: The U.S. government initially mandated OSI protocol adoption (GOSIP — Government OSI Profile, 1990). By 1995 they dropped the mandate because TCP/IP had already won the market. The internet's explosive growth in the early 1990s sealed OSI's fate as a protocol suite.
The Takeaway
OSI survives as a teaching tool and shared vocabulary. TCP/IP survives as the actual implementation. In practice, you'll use OSI layer numbers (L2, L3, L4, L7) to talk about TCP/IP concepts. Nobody says "TCP/IP Layer 2" — they say "Layer 3" (meaning OSI Layer 3 = IP = TCP/IP Internet layer).
Key RFCs to Know
| RFC | Title | Why It Matters |
|---|---|---|
RFC 791 | Internet Protocol (IPv4) | The foundational protocol — defines the packet format and addressing |
RFC 793 | Transmission Control Protocol (TCP) | Defines reliable, ordered byte-stream delivery |
RFC 768 | User Datagram Protocol (UDP) | The simplest transport protocol — 1 page RFC |
RFC 8200 | Internet Protocol Version 6 (IPv6) | The eventual successor to IPv4 |
RFC 1122 | Requirements for Internet Hosts | Defines the TCP/IP model layers and host behavior |
RFC 1958 | Architectural Principles of the Internet | The end-to-end principle and design philosophy |
RFC 9000 | QUIC: A UDP-Based Multiplexed Transport | The modern transport protocol powering HTTP/3 |
Tip
Useful skill: When debugging or learning protocols, read the RFC. They're surprisingly readable. curl https://www.rfc-editor.org/rfc/rfc793.txt gives you the complete TCP specification in plain text.