Skip to content
Menu

Networking8 min read

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

4 Application Data / Messages HTTP, DNS, SSH, SMTP, FTP, TLS, SNMP, DHCP, gRPC
3 Transport Segment / Datagram TCP, UDP, SCTP, QUIC
2 Internet Packet IPv4, IPv6, ICMP, ICMPv6, IGMP, IPsec
1 Link (Network Access) Frame Ethernet, Wi-Fi, ARP, PPP, VLAN, NDP

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 / TechnologyScopeDescription
Ethernet (802.3)LANDominant wired technology; frame-based with MAC addressing
Wi-Fi (802.11)WLANWireless frames with CSMA/CA media access
ARPLANMaps IPv4 addresses to MAC addresses via broadcast
NDP (ICMPv6)LANIPv6 equivalent of ARP — uses multicast instead of broadcast
PPPPoint-to-pointUsed on serial links, DSL, some VPN tunnels
802.1QLANVLAN 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.

ProtocolDescription
IPv432-bit addressing, header checksum, optional fragmentation
IPv6128-bit addressing, simplified header, no fragmentation by routers, flow labels
ICMP / ICMPv6Error reporting and diagnostics (ping, traceroute, destination unreachable)
IGMP / MLDMulticast group management (IPv4 / IPv6 respectively)
IPsecEncryption (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.

TCP
  • 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
UDP
  • 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.

ProtocolTransportPort(s)Description
HTTP/1.1TCP80Text-based request/response protocol for the web
HTTP/2TCP443Binary framing, multiplexing, server push, header compression
HTTP/3QUIC (UDP)443HTTP over QUIC — eliminates TCP head-of-line blocking
DNSUDP (TCP for zone transfers)53Domain name to IP resolution
SSHTCP22Secure remote shell, tunneling, file transfer
TLS 1.3TCP443Transport-layer encryption (OSI would call this L5/L6)
DHCPUDP67/68Dynamic IP configuration (DORA: Discover, Offer, Request, Ack)
SNMPUDP161/162Network device monitoring
gRPCHTTP/2 (TCP)variesGoogle's RPC framework using Protocol Buffers
BGPTCP179Border 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 Model (7 Layers)
7 Application
6 Presentation
5 Session
4 Transport
3 Network
2 Data Link
1 Physical
TCP/IP Model (4 Layers)
4 Application Merges OSI L5 + L6 + L7
3 Transport Same as OSI L4
2 Internet Same as OSI L3
1 Link Merges OSI L1 + L2
OSI Layer(s)TCP/IP LayerWhat Changed
7 + 6 + 5ApplicationSession and Presentation were rarely implemented as separate layers — merged into Application
4TransportDirect 1:1 mapping — both define TCP and UDP
3InternetDirect 1:1 mapping — both define IP
2 + 1LinkTCP/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.

HTTP   DNS   SSH   SMTP   gRPC   SNMP   DHCP   FTP   QUIC
TCP     UDP     SCTP
IP (v4 / v6)
Ethernet   Wi-Fi   LTE/5G   PPP   Fiber
Copper   Fiber Optic   Radio   Satellite   Coaxial   DSL

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

TCP/IP — The Winner
  • 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
OSI — The Loser
  • 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

RFCTitleWhy It Matters
RFC 791Internet Protocol (IPv4)The foundational protocol — defines the packet format and addressing
RFC 793Transmission Control Protocol (TCP)Defines reliable, ordered byte-stream delivery
RFC 768User Datagram Protocol (UDP)The simplest transport protocol — 1 page RFC
RFC 8200Internet Protocol Version 6 (IPv6)The eventual successor to IPv4
RFC 1122Requirements for Internet HostsDefines the TCP/IP model layers and host behavior
RFC 1958Architectural Principles of the InternetThe end-to-end principle and design philosophy
RFC 9000QUIC: A UDP-Based Multiplexed TransportThe 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.

Solidnines — solidnines.com