The TCP/IP Model
Four layers (link, internet, transport, application) and the reason the Internet runs on them instead of OSI.
Summary#
The TCP/IP model is the four-layer architecture the Internet actually runs on: Link, Internet, Transport, Application. It evolved out of ARPANET research in the 1970s, was codified by RFC 1122 in 1989, and predates OSI’s seven-layer standardisation effort by a decade. It won because it shipped first, was simpler, and ran on real networks while OSI was still drafting documents.
Unlike OSI’s neat separation of session, presentation, and application, TCP/IP folds those three into one Application layer. The argument: real protocols (HTTP, SMTP, DNS, SSH) handle their own framing, encoding, and session semantics — there was never a market for standalone session or presentation protocols. The four layers map cleanly onto the headers a packet actually wears on the wire, which is what makes them durable.
Why it matters#
Every networking concept in production maps to one of four layers, and the layer tells you which tools to reach for. Link layer: ethtool, MAC tables, switch port counters. Internet layer: ip route, ping, traceroute, BGP tables. Transport layer: ss, netstat, tcpdump filters on flags. Application layer: curl, dig, application logs.
The model also clarifies who owns reliability. Link layer may add CRC and link-level retransmissions (Wi-Fi does, Ethernet doesn’t). Internet layer offers none — IP is best-effort. Transport layer chooses: TCP gives you reliable, in-order, congestion-controlled streams; UDP gives you bare multiplexing and a checksum. Application layer can layer on top of either (HTTP/3 builds reliability over UDP via QUIC, on purpose).
Finally, the four-layer model matches what you see on the wire. Each datagram carries an Ethernet (or Wi-Fi) frame, an IP packet, a TCP/UDP segment, and an application payload. There’s no “session frame” or “presentation frame” — those concepts live inside the application bytes when they live at all.
How it works#
The four layers, with what each contributes and the canonical protocols at each:
+-----------------------+----------------------------------------------+| Application | HTTP, DNS, SMTP, SSH, gRPC, BGP, DHCP || (end-to-end semantics)| |+-----------------------+----------------------------------------------+| Transport | TCP (reliable, ordered, congestion-controlled)|| (process-to-process) | UDP (datagram, unreliable) || | QUIC (UDP-based reliable streams) |+-----------------------+----------------------------------------------+| Internet | IPv4, IPv6, ICMP, IPsec || (host-to-host, global)| Routing: BGP between ASes, OSPF/IS-IS within |+-----------------------+----------------------------------------------+| Link | Ethernet, Wi-Fi (802.11), PPP, ARP || (one hop) | MAC addressing, framing, CRC |+-----------------------+----------------------------------------------+What each layer adds#
- Link — turns bits into frames on one physical segment. Adds source/destination MAC and a frame-check sequence. Cares only about reaching the next hop on the same broadcast domain.
- Internet (IP) — adds global addressing. Routers read the IP destination, look up the next hop in their forwarding table, decrement TTL, re-encapsulate at the next link layer. The header includes a protocol field so the receiving stack knows whether to hand the payload to TCP or UDP.
- Transport — adds process-level multiplexing via port numbers. TCP layers on a connection (3-way handshake), reliable in-order delivery (sequence numbers, ACKs, retransmits), and congestion control. UDP layers on essentially nothing beyond port numbers and a checksum.
- Application — whatever the app speaks. HTTP request/response, DNS query/answer, SMTP mail exchange, SSH bytes.
Encapsulation in the four-layer view#
[ App payload ] <- Application[ TCP hdr | App payload ] <- Transport[ IP hdr | TCP hdr | App payload ] <- Internet[ Eth hdr | IP hdr | TCP hdr | App payload | FCS ] <- LinkThe bytes you put on the wire are the bottom row. The receiver strips one header per layer on the way up, hands the payload to the next layer, and finally delivers the app payload to the listening process.
Peer-to-peer relationship#
Each layer talks to its peer on the other end, not to its neighbours. Your TCP stack talks to the server’s TCP stack; intermediate routers never read the TCP header (in theory). This is what makes the Internet’s “stupid network, smart endpoints” architecture work — routers stay simple and the smarts live in hosts.
Variants and trade-offs#
The reason TCP/IP won is partly historical and partly engineering. IETF’s “rough consensus and running code” let TCP/IP iterate on ARPANET while ISO’s committee process produced documents. By the time OSI’s protocol suite (TP4, CLNP, X.400) was implementable, TCP/IP had the academic and commercial deployments.
TCP/IP’s pragmatism also explains its longevity. It pushed reliability to the endpoints, kept the routers stateless, and embraced incremental change (CIDR replaced classful addressing, IPv6 was added alongside, QUIC added a new transport without changing IP). OSI’s tight specification would have made these much harder.
Other trade-offs worth knowing:
- Hourglass shape — many link technologies below, many application protocols above, but only IP in the middle. This narrow waist is the Internet’s most important design property. Anything that runs over IP can reach anything else that runs over IP.
- End-to-end principle — push function to the endpoints; keep the network simple. Codified by Saltzer, Reed, Clark in 1984. Explains why HTTPS terminates at endpoints, why retransmissions live in TCP not routers, why NAT was always controversial.
- Best-effort delivery — IP gives you no guarantees. Drop, reorder, duplicate are all allowed. Applications choosing TCP get reliability; applications choosing UDP accept the risk.
Where do MPLS, VPNs, and overlays fit?
MPLS sits below IP forwarding but above the physical link — sometimes called “Layer 2.5”. It does fast label-switched forwarding inside provider networks while still carrying IP packets. VPNs (IPsec, WireGuard, OpenVPN) tunnel IP inside IP (or IP inside UDP/TCP) — they show up as new “virtual link layers” from the perspective of the encapsulated traffic. Overlays like VXLAN do the same for datacenter L2 segments. The four-layer model handles these by recursion: tunnels add another encapsulation pass.
When this is asked in interviews#
A common warm-up: “name the layers of the TCP/IP model” or “compare TCP/IP and OSI”. The strong move is to give the four layers, give the canonical protocols at each, and explain why the model is four layers and not seven.
Follow-ups to expect:
- “Why didn’t the Internet use OSI?” — IETF shipped first, ISO was slow and complex, market converged on TCP/IP, OSI’s session/presentation didn’t justify standalone layers.
- “Where does TLS fit?” — between TCP and the application; OSI calls it L6 by convention. Honest answer: it doesn’t sit cleanly on any layer.
- “Which layer is responsible for retransmission?” — usually transport (TCP). Sometimes link (Wi-Fi link-level ARQ). Never internet — IP is best-effort by design.
- “Walk me from
curl example.comto bytes on the wire.” — DNS at app layer, TCP handshake at transport, IP routing across hops, Ethernet/Wi-Fi at link. Each adds its header.
Asked across most networking-flavoured loops. Less detail expected in product roles, more in infra/SRE.
Related concepts#