The TCP/IP Model: How the Internet Actually Works

Built to Survive a Nuclear Attack

In the late 1960s, the United States Defense Advanced Research Projects Agency (DARPA) faced a sobering problem. All military communication ran through centralized hubs. One nuclear strike on Washington D.C. could sever communication between commands. They needed a network that could survive partial destruction — one where data would automatically route around damaged nodes like water flowing around rocks.

The result was ARPANET and, later, TCP/IP. The design was radical: no central authority, no single point of failure. Every node is equal. Every packet finds its own path. Data does not travel as a single stream — it is broken into packets that independently navigate the network, potentially taking different routes, reassembled at the destination.

That same architecture runs the internet today. When a submarine accidentally cuts an undersea cable, traffic reroutes automatically. The internet does not go down — it works around the damage, exactly as designed in 1969.

TCP/IP vs OSI: Theory Meets Reality

The OSI model (introduced in 1984) is the textbook ideal — seven clean, well-separated layers. The TCP/IP model (standardized with RFC 791 and RFC 793 in 1981) is what actually runs the internet. It predates OSI and was designed for practical implementation, not theoretical perfection.

Why TCP/IP won:

• It was already implemented and working before OSI was finalized
• It is simpler — four layers instead of seven
• It is open and not tied to any vendor
• It proved itself in real-world deployments
• OSI remained largely academic; vendors built TCP/IP stacks

Today, when people say "the internet runs on TCP/IP," they mean the TCP/IP model. The OSI model is still taught because it provides better conceptual clarity and a shared vocabulary for troubleshooting.

The Four Layers of TCP/IP

Layer 4 — Application Layer

Combines OSI Layers 5, 6, and 7 (Session + Presentation + Application) into one practical layer. All user-facing protocols live here. The application is responsible for whatever the OSI model would have handled in those three upper layers.

Protocols: HTTP, HTTPS, FTP, SMTP, IMAP, POP3, DNS, SSH, Telnet, DHCP, SNMP

What happens here: Your browser constructs an HTTP GET request for www.google.com. This is the message that will be handed down to the layers below.

Layer 3 — Transport Layer

Directly maps to OSI Layer 4. Handles end-to-end communication between processes. Uses port numbers to identify which application should receive the data.

Protocols: TCP (reliable, ordered), UDP (fast, connectionless)

What happens here: TCP breaks the HTTP request into segments. Each segment gets a source port (random ephemeral port, e.g., 54231) and destination port (443 for HTTPS). TCP also adds sequence numbers so segments can be reassembled in order.

Layer 2 — Internet Layer

Maps to OSI Layer 3 (Network). Handles logical (IP) addressing and routing across multiple networks. This is where the "internet" in TCP/IP comes from.

Protocols: IPv4, IPv6, ICMP, ARP (debated), OSPF, BGP

What happens here: The IP layer wraps each TCP segment in a packet. It adds:

• Source IP address: your device's IP (e.g., 192.168.1.105)
• Destination IP address: Google's server IP (e.g., 142.250.80.46)
• TTL (Time To Live): decremented at each router hop, preventing infinite loops

Layer 1 — Network Access Layer (Link Layer)

Combines OSI Layers 1 and 2 (Physical + Data Link). Handles the physical transmission of data on a specific medium — Ethernet, Wi-Fi, fiber, etc.

Protocols: Ethernet, Wi-Fi (802.11), ARP, PPP

What happens here: The Ethernet layer wraps the IP packet in a frame. It adds:

• Source MAC address: your network card's hardware address
• Destination MAC address: your router's MAC address (the next hop)

The frame is then converted to electrical signals (Ethernet cable) or radio waves (Wi-Fi) and transmitted.

OSI to TCP/IP Mapping

The Journey of a Web Request

Let us trace what happens when you type https://www.google.com in your browser. Each layer adds its "wrapper":

Step 1 — Application Layer: HTTP Request Created

GET / HTTP/1.1
Host: www.google.com
User-Agent: Chrome/120.0
Accept: text/html

The browser constructs this HTTP request. DNS has already resolved www.google.com to an IP address (142.250.80.46) via a separate UDP/DNS request.

Step 2 — Transport Layer: TCP Segmentation

[ Source Port: 54231 | Dest Port: 443 | Seq: 1001 | Flags: PSH,ACK ]
[ HTTP request data... ]

TCP wraps the HTTP request in a segment. Port 443 tells the receiving server this is HTTPS traffic. The sequence number ensures ordered reassembly.

Step 3 — Internet Layer: IP Encapsulation

[ Version: 4 | TTL: 64 | Protocol: TCP ]
[ Source IP: 192.168.1.105 | Dest IP: 142.250.80.46 ]
[ TCP segment... ]

IP adds addressing information. The TTL starts at 64 and decrements by 1 at each router. If it reaches 0, the packet is discarded (preventing infinite loops).

Step 4 — Network Access Layer: Ethernet Framing

[ Dest MAC: AA:BB:CC:DD:EE:FF | Source MAC: 11:22:33:44:55:66 | EtherType: IPv4 ]
[ IP packet... ]
[ CRC checksum ]

Ethernet adds MAC addresses for the local hop (your machine to your router). Note: the MAC address changes at each hop, but the IP address stays the same across the entire journey.

On the wire: 10110110 01001101 11010010... — raw bits transmitted

Real Tools That Operate at Each Layer

Example: using ping

$ ping google.com
PING google.com (142.250.80.46): 56 data bytes
64 bytes from 142.250.80.46: icmp_seq=0 ttl=117 time=14.2 ms

The TTL of 117 tells you the packet took approximately 64 - 117 = well, Google sets initial TTL at 128, so 128 - 117 = 11 hops to reach you.

Example: using traceroute

$ traceroute google.com
 1  192.168.1.1     1.2 ms   (your router)
 2  10.0.0.1        8.4 ms   (ISP gateway)
 3  72.14.198.1    12.1 ms   (Google's edge)
 4  142.250.80.46  14.2 ms   (destination)

Each line is one router hop. The time shown is the round-trip latency to that point. Asterisks (*) mean a router did not respond to ICMP probes.

Key Takeaway

The TCP/IP model is not an academic exercise — it is the living architecture of the internet. Every packet you send, every video you stream, every message you send travels through these four layers. Understanding them means you can reason about why something fails, not just that it failed. When ping works but the website does not load, you know the problem is above Layer 3 — likely DNS (Layer 7) or the server itself. That diagnostic clarity is the real value of understanding the model.