Free lesson · Computer Networking

The Tcpip Model What The Internet Actually Uses

Easy11 min readnetworkingcomputer-networkstcp-ip

A Model Born in Practice, Not in Committee

The OSI model was designed by an international standards committee to be a comprehensive theoretical framework. The TCP/IP model took the opposite path - it was built by researchers who needed to make computers talk to each other right now and figured out the theory later.

In the late 1960s, the US Department of Defense funded ARPANET, a project to build a computer network that could survive partial failures - if one node went down, the rest of the network should keep working. The researchers working on ARPANET - Vint Cerf and Bob Kahn among them - developed the protocols that would eventually become TCP and IP. By 1983, ARPANET fully adopted TCP/IP as its standard protocol suite. By the early 1990s, the commercial internet was built on it.

The TCP/IP model was not published as a formal standard in the way the OSI model was. It emerged from working code, from RFCs (Request for Comments documents), and from the practical experience of building the largest network in human history. When networking professionals say "the internet runs on TCP/IP," they mean that every device connected to the internet - your phone, your laptop, Google's servers, Netflix's CDN - uses the TCP/IP protocol suite to communicate.

The Four Layers of TCP/IP

Where the OSI model has seven layers, the TCP/IP model has four. This is not because TCP/IP is less capable - it is because the TCP/IP designers made different choices about where to draw the boundaries between layers. The functions covered by all seven OSI layers are still present; they are just grouped differently.

graph TD
    T4["Layer 4: Application Layer<br/>HTTP, DNS, SMTP, FTP, SSH<br/>Combines OSI Layers 5, 6, 7"]
    T3["Layer 3: Transport Layer<br/>TCP, UDP, QUIC<br/>Same as OSI Layer 4"]
    T2["Layer 2: Internet Layer<br/>IP, ICMP, ARP<br/>Same as OSI Layer 3"]
    T1["Layer 1: Network Access Layer<br/>Ethernet, Wi-Fi<br/>Combines OSI Layers 1, 2"]

    T4 --> T3
    T3 --> T2
    T2 --> T1

    style T4 fill:#4f46e5,stroke:#4338ca,color:#fff
    style T3 fill:#7c3aed,stroke:#6d28d9,color:#fff
    style T2 fill:#8b5cf6,stroke:#7c3aed,color:#fff
    style T1 fill:#a78bfa,stroke:#8b5cf6,color:#fff

This diagram shows the four layers of the TCP/IP model stacked vertically. Layer 4 at the top is the Application Layer, handling protocols like HTTP, DNS, SMTP, FTP, and SSH, and it combines OSI layers 5, 6, and 7. Layer 3 is the Transport Layer, handling TCP, UDP, and QUIC, matching OSI layer 4. Layer 2 is the Internet Layer, handling IP, ICMP, and ARP, matching OSI layer 3. Layer 1 at the bottom is the Network Access Layer, handling Ethernet and Wi-Fi, combining OSI layers 1 and 2.

Layer 1 - Network Access (Link) Layer

The Network Access layer combines what the OSI model splits into the Physical layer (Layer 1) and the Data Link layer (Layer 2). It handles everything from converting data into physical signals to organizing those signals into frames with MAC addresses for local delivery.

The TCP/IP designers treated the physical transmission and local network delivery as a single concern: "get the data from this device to the next device on the same network." Whether that happens over copper wire, fiber optic cable, or radio waves is an implementation detail that the upper layers should not need to care about.

In practical terms, this layer includes Ethernet, Wi-Fi, and any other technology that handles the "last mile" delivery from one device to the next adjacent device. The protocols and hardware at this layer are diverse - there is no single standard the way IP dominates the Internet layer - because different physical environments require different solutions. A data center uses 10-gigabit Ethernet. A coffee shop uses Wi-Fi. A cellular phone uses LTE or 5G. All of these are different Network Access layer implementations, and the TCP/IP model treats them all as interchangeable.

Layer 2 - Internet Layer

The Internet layer is the heart of the TCP/IP model. Its job is a single, enormously important function: routing packets from source to destination across multiple networks.

This layer is dominated by one protocol: the Internet Protocol (IP). Every device on the internet has an IP address, and every packet that crosses the internet carries a source IP and a destination IP in its header. Routers at every intermediate hop examine the destination IP and use their routing tables to decide where to send the packet next.

The Internet layer also includes ICMP (Internet Control Message Protocol), which provides error reporting and diagnostic tools - ping and traceroute are both ICMP-based. Some descriptions of the TCP/IP model also place ARP (Address Resolution Protocol) at this layer, though ARP arguably sits between the Internet and Network Access layers because it translates Internet-layer addresses (IPs) into Network Access-layer addresses (MACs).

The key architectural decision at this layer is that IP is a best-effort protocol. It makes no guarantees about delivery. Packets can arrive out of order, arrive duplicated, or be lost entirely. IP's job is to get packets from source to destination as efficiently as possible and leave reliability to the Transport layer.

Important: The Internet layer being "best-effort" is a deliberate design choice, not a flaw. By keeping IP simple and unreliable, the TCP/IP architects ensured that the network itself stays fast and lightweight. Applications that need reliability get it from TCP at the Transport layer. Applications that prefer speed over reliability use UDP and handle packet loss in their own way. This separation of concerns - fast network, optional reliability - is one of the most important architectural decisions in the history of computing.

Layer 3 - Transport Layer

The Transport layer provides end-to-end communication between processes running on different machines. It is functionally identical to OSI Layer 4, and the two major protocols are the same ones you saw in the OSI discussion: TCP and UDP.

The Transport layer solves a problem the Internet layer ignores: which application on the destination machine should receive this data? A server might be running a web server, a database, an SSH daemon, and a monitoring agent all at the same time, all sharing the same IP address. Port numbers - assigned at the Transport layer - distinguish between them. TCP port 80 or 443 for web traffic. Port 22 for SSH. Port 5432 for PostgreSQL. The combination of IP address and port number uniquely identifies a specific application on a specific machine anywhere on the internet.

TCP adds reliability on top of IP's best-effort delivery: connection setup (three-way handshake), ordered delivery (sequence numbers), error detection (checksums), retransmission of lost packets, and flow control (preventing the sender from overwhelming the receiver). UDP strips all of this away, providing only port-based multiplexing and an optional checksum, in exchange for lower latency and less overhead.

A newer protocol, QUIC, has emerged as a third option. Developed by Google and now standardized as the transport protocol for HTTP/3, QUIC is built on UDP but adds reliability, encryption, and multiplexed streams - essentially taking the best features of TCP and TLS and implementing them in a way that avoids TCP's head-of-line blocking problem. QUIC represents the ongoing evolution of the Transport layer.

Layer 4 - Application Layer

The TCP/IP Application layer combines three OSI layers (Session, Presentation, Application) into a single layer. The TCP/IP designers saw session management, data formatting, and application protocols as closely related concerns that did not benefit from being separated into distinct layers.

This consolidation is where the TCP/IP model's pragmatism shows most clearly. In the OSI model, TLS encryption is a Presentation layer function, HTTP session cookies are a Session layer function, and the HTTP protocol itself is an Application layer function. In the TCP/IP model, all three are just "Application layer." The TCP/IP approach argues: the application knows best how to manage its sessions, format its data, and communicate - so let it handle all of that without imposing artificial boundaries.

The Application layer is where developers spend most of their time. HTTP for web communication. DNS for name resolution. SMTP for email. FTP for file transfer. SSH for secure remote access. MQTT for IoT messaging. gRPC for service-to-service calls. Each protocol defines the format and rules for a specific type of communication, and each sits on top of either TCP or UDP at the Transport layer.

sequenceDiagram
    participant App as Application Layer<br/>(HTTP Request)
    participant Trans as Transport Layer<br/>(TCP Segment)
    participant Net as Internet Layer<br/>(IP Packet)
    participant Link as Network Access Layer<br/>(Ethernet Frame)

    App->>Trans: HTTP GET /index.html
    Note over Trans: Adds source port, dest port 80<br/>Creates TCP segment
    Trans->>Net: TCP segment
    Note over Net: Adds source IP, dest IP<br/>Creates IP packet
    Net->>Link: IP packet
    Note over Link: Adds source MAC, dest MAC<br/>Creates Ethernet frame
    Link->>Link: Transmit as electrical signals

This sequence diagram shows how data flows down through the four TCP/IP layers when sending an HTTP request. The Application Layer creates an HTTP GET request. The Transport Layer adds source and destination port numbers to create a TCP segment. The Internet Layer adds source and destination IP addresses to create an IP packet. The Network Access Layer adds source and destination MAC addresses to create an Ethernet frame, which is then transmitted as electrical signals.

The Five-Layer Hybrid Model

In many networking textbooks and university courses, you will encounter a five-layer model that is neither pure OSI nor pure TCP/IP. This hybrid splits the TCP/IP Network Access layer back into separate Physical and Data Link layers while keeping the TCP/IP's simplified upper layers. The result is:

This five-layer model is a teaching tool, not an official standard. It exists because the distinction between physical signal transmission and data link framing is genuinely important enough to warrant separate discussion, but the OSI model's three upper layers (Session, Presentation, Application) do not add enough practical value to justify keeping them separate.

You may encounter this model in Kurose and Ross's popular textbook Computer Networking: A Top-Down Approach or in university lecture notes. If someone references "the five-layer model," this is what they mean.

Why TCP/IP Won

The OSI model was technically elegant. The TCP/IP model was practically deployed. By the time the OSI model was finalized in 1984, TCP/IP was already running on thousands of machines. There are several reasons TCP/IP won the adoption war:

Simplicity: Four layers are easier to implement, debug, and reason about than seven. The reduction from seven to four was not a loss of functionality - it was a recognition that some of the OSI distinctions did not provide enough practical value to justify the additional complexity.

Working code first: TCP/IP was developed alongside working implementations. The protocol and the code evolved together. The OSI model was designed as a specification first, with implementations expected to follow - but by the time conforming implementations appeared, TCP/IP was already the incumbent.

The ARPANET ecosystem: TCP/IP was adopted by ARPANET, which became the backbone of the early internet. Universities, research labs, and government agencies all used TCP/IP. When the internet opened to commercial traffic in the early 1990s, TCP/IP came with it.

Open, free standards: TCP/IP protocols were specified in openly available RFCs. Anyone could read them, implement them, and build products around them without paying licensing fees. Some OSI protocols had licensing and royalty requirements that slowed adoption.

Pros:
- Simpler with only four layers - easier to learn, implement, and debug
- Battle-tested - the actual internet has run on TCP/IP for over 40 years
- Open standards via RFCs - freely available to anyone
- Pragmatic design that merged layers with limited practical distinction
- Massive ecosystem of implementations, tools, and documentation

Cons:
- Less precise vocabulary - "Application layer" covers three different concerns (session, presentation, application)
- The Network Access layer is so broad it is sometimes hard to discuss physical vs data link issues precisely
- Historically weaker formal specification compared to OSI's detailed standards
- Some educators prefer the OSI model's finer granularity for teaching

Tip: In practice, the industry uses a mix: TCP/IP architecture with OSI vocabulary. You will hear engineers say "Layer 7 load balancer" (OSI numbering) while building systems on the TCP/IP stack. This is not contradictory - the OSI numbering system provides useful precision for referring to specific layers, even though the underlying architecture follows the TCP/IP model. Accept this pragmatic hybrid and you will never be confused by industry conversations.

How TCP/IP Maps to Real Network Traffic

To make this concrete, let us trace a real example. When you type https://www.google.com in your browser and press Enter, here is what the TCP/IP model looks like in action:

Application Layer: Your browser constructs an HTTP GET request for the page. Before that, it uses DNS (also application-layer) to resolve www.google.com to an IP address. TLS negotiation encrypts the connection.

Transport Layer: TCP establishes a connection to Google's server using a three-way handshake (SYN → SYN-ACK → ACK). The HTTP request is wrapped in a TCP segment with your machine's ephemeral source port and Google's destination port 443.

Internet Layer: IP wraps the TCP segment in a packet with your machine's source IP address and Google's server's destination IP address. Your computer's routing table determines that this packet should be sent to your default gateway (your home router).

Network Access Layer: An ARP lookup finds the MAC address of your home router. The IP packet is wrapped in an Ethernet frame addressed to your router's MAC. The frame is transmitted as electrical signals (wired) or radio waves (Wi-Fi) to your router.

Your router then repeats the Internet and Network Access layers for the next hop - repackaging the IP packet in a new frame addressed to the next router, and so on, until the packet reaches Google's data center. Each hop changes the Layer 2 addressing (MAC addresses) but preserves the Layer 3 addressing (IP addresses). This is the fundamental mechanism by which data crosses the internet.

Interview: When asked "what happens when you type a URL in the browser?" in a System Design interview, the TCP/IP model gives you a natural framework for structuring your answer. Walk through the layers: DNS resolution (Application), TCP connection and TLS handshake (Transport), IP routing (Internet), physical delivery (Network Access). This demonstrates networking depth without turning into a lecture - just mention each layer's role in one or two sentences and then move on to the server-side architecture, which is what the interviewer really wants to discuss.

Key insight: The interviewer is not testing whether you memorized the layers. They are testing whether you understand that a "simple" HTTP request involves DNS, TCP, IP, and physical delivery, and that you can mention these without getting lost in them.

What Comes Next

The next topic compares OSI and TCP/IP directly - when to use which model's vocabulary, what matters for interviews, and what you can safely ignore. After that, we explore encapsulation - the process by which each layer wraps data in its own header as it passes down the stack, which is how the layered architecture works at the byte level.

Exercise: Starter: Open a terminal and run curl -v https://www.google.com (on Mac/Linux) or use PowerShell's Invoke-WebRequest (on Windows). Look at the verbose output. Can you identify which parts correspond to each TCP/IP layer? The DNS resolution is which layer? The TCP handshake is which layer? The HTTP headers are which layer?

Intermediate: The TCP/IP model does not have a Session or Presentation layer. But the functions those layers provide (session management, encryption, data encoding) still happen. For each of these three functions, identify where in the TCP/IP model they are actually implemented. Which protocol handles each?

Advanced: Research the debate around whether the TCP/IP model should have a separate Security layer. Some proposals have suggested adding a dedicated layer between Transport and Application to handle TLS, IPsec, and other security protocols. What are the arguments for and against this? How does QUIC - which bundles transport and encryption together - affect this debate?

Back to Computer Networking