Skip to content

TCP/IP model

The OSI model is what gets drawn on whiteboards, but it's not what shipped. The internet you actually use runs on a different, simpler framework, developed by the U.S. Department of Defense's ARPANET project through the 1970s and formalized around the protocols that give it its name: TCP and IP. Understanding both models, and how they map onto each other, is what lets you read networking documentation written from either tradition without getting confused.

Why a second model exists

OSI was designed top-down, as a comprehensive standard, before most of its protocols were built or deployed. TCP/IP grew the opposite way: bottom-up, out of a working, already-running network — ARPANET — that needed a practical way to connect dissimilar computer networks together reliably, including tolerating network failures without dropping an entire conversation, a requirement that came directly from ARPANET's military-research origins. By the time OSI's own protocol suite was ready for wide deployment in the 1980s, TCP/IP was already running production traffic on a growing academic and research network, was simpler to implement, and had no licensing costs. Momentum won: TCP/IP became the de facto internet standard, and OSI's seven-layer breakdown survived mainly as the vocabulary the industry still uses to talk about any protocol stack, TCP/IP included.

The four layers

TCP/IP layer Job Example protocols Roughly maps to OSI
Application Protocols applications actually speak HTTP, DNS, SMTP, FTP Layers 5–7
Transport Process-to-process delivery, reliable or not TCP, UDP Layer 4
Internet Logical addressing and routing between networks IP (IPv4, IPv6) Layer 3
Link (Network Access) Delivery within one local network Ethernet, Wi-Fi Layers 1–2

Note the collapse: where OSI splits Session, Presentation, and Application into three separate layers, TCP/IP treats all of that as one Application layer, because in real protocol implementations those responsibilities usually live inside the same piece of software rather than as three distinct components. Similarly, TCP/IP doesn't formally distinguish Physical from Data Link — both fall under one Link layer, since in practice the hardware and its immediate framing protocol (like Ethernet) are designed and implemented together.

Equivalent to OSI Layers 1 and 2 combined: getting frames from one device to a directly connected neighbor on the same local network. Ethernet and Wi-Fi live here, using hardware addresses — see MAC address for how that addressing actually works.

Internet layer

This is where IP lives, and it's the layer that gives the whole suite half its name. IP's job is deceptively simple to state and genuinely hard to appreciate the first time: give every host a logical address, and figure out, hop by hop through however many routers stand between source and destination, how to get a packet from one to the other — even across networks that IP itself knows nothing about internally. The full mechanics of IP addressing are the subject of IP addressing (IPv4, IPv6).

Transport layer

Same job as OSI's Transport layer: deliver data to the correct process on the destination host, using port numbers, and decide whether that delivery needs to be reliable. TCP (Transmission Control Protocol) guarantees ordered, retransmitted, acknowledged delivery. UDP (User Datagram Protocol) sends data with no such guarantees, in exchange for lower overhead and lower latency. Picking the wrong one for a given application is a real and common design mistake, which is why the next module devotes several articles to the comparison rather than settling it in a paragraph here.

Application layer

Every protocol an application actually speaks to do its job: HTTP for the web, DNS for name resolution, SMTP for sending mail. TCP/IP doesn't separate out session management or data formatting as distinct layers — a browser negotiating a TLS session and formatting an HTTP request are both, from TCP/IP's point of view, just "the application layer doing its job."

Following one request through both models

Take a browser loading a web page over HTTPS. Reading top to bottom:

TCP/IP layer      What happens                                   OSI equivalent
------------      --------------------------------------------   ----------------
Application       Browser builds an HTTP request, TLS encrypts   Layers 7, 6, 5
                   it
Transport         TCP wraps it in a segment, adds source and     Layer 4
                   destination port numbers
Internet          IP wraps that in a packet, adds source and     Layer 3
                   destination IP addresses
Link              Ethernet or Wi-Fi wraps that in a frame, adds  Layers 2, 1
                   source and destination MAC addresses, and
                   transmits it as bits

flowchart LR
    subgraph OSI["OSI (7 layers)"]
        direction TB
        O7["7 Application"]
        O6["6 Presentation"]
        O5["5 Session"]
        O4["4 Transport"]
        O3["3 Network"]
        O2["2 Data Link"]
        O1["1 Physical"]
    end
    subgraph TCPIP["TCP/IP (4 layers)"]
        direction TB
        T4["Application"]
        T3["Transport"]
        T2["Internet"]
        T1["Link"]
    end
    O7 --- T4
    O6 --- T4
    O5 --- T4
    O4 --- T3
    O3 --- T2
    O2 --- T1
    O1 --- T1

The same encapsulation idea introduced in the OSI article applies here without any real change — TCP/IP just groups the same work into four buckets instead of seven. This is precisely why you'll see both models used interchangeably in documentation and interviews: OSI gives you finer-grained vocabulary for discussing a specific responsibility (say, distinguishing "this is a Presentation-layer concern" from "this is a Session-layer concern"), while TCP/IP describes what's actually implemented and running.

Why this distinction matters in practice

When you read a tool's documentation or a vendor's marketing material describing something as operating "at Layer 3" or "at Layer 4," they're almost always speaking OSI's numbering even while describing a TCP/IP-based system — a Layer 4 load balancer, for instance, makes routing decisions based on TCP/UDP ports and IP addresses, without inspecting the application data inside. A Layer 7 load balancer, by contrast, reads the actual HTTP request. Knowing both models fluently means you're not thrown by either convention.

Practical scenario: reading a failed request through the model

Suppose a deployment health check runs this command:

curl -v https://api.example.test/health

The TCP/IP model gives you a clean way to read the result:

Failure in output                         Layer to investigate
----------------------------------------  ----------------------------------
Could not resolve host                    Application layer name lookup
Connection timed out                      Internet or Transport layer path
Connection refused                        Transport reached host, no listener
TLS certificate error                     Application security negotiation
HTTP/1.1 503 Service Unavailable          Application responded with an error

Notice the important distinction: Connection refused is not the same as Connection timed out. A refusal usually means a host answered but no process accepted the connection on that port. A timeout often means packets never made the round trip, or a firewall silently dropped them. The TCP/IP layers do not solve the problem for you, but they keep you from treating every curl failure as the same kind of failure.

Practical scenario: the name fails, the address works fine

An application logs getaddrinfo failed for db.internal.example, and someone immediately assumes the network between the app server and the database is down. Test that assumption directly, at the layer it actually belongs to:

dig +short db.internal.example

;; connection timed out; no servers could be reached

dig never got an answer from any DNS server it tried — that's an Application-layer failure (name resolution is DNS's job, and DNS is an application protocol, however foundational it feels). It says nothing yet about whether the Internet or Transport layers underneath it are healthy. Confirm that by skipping the name entirely and going straight to the known IP address:

curl -v --connect-timeout 3 http://10.0.4.20:5432

*   Trying 10.0.4.20:5432...
* Connected to 10.0.4.20 (10.0.4.20) port 5432
* Empty reply from server

The TCP connection succeeded instantly — Internet-layer routing and Transport-layer port reachability are both fine. The "empty reply" is expected here too: curl is speaking HTTP to a PostgreSQL port that doesn't speak HTTP back, which is a mismatch, not a network fault. The actual incident is narrower than "the network is down": DNS resolution for this one name is failing, while IP connectivity to that same host is completely healthy.

dig db.internal.example   -> fails                (Application layer: name resolution)
curl http://10.0.4.20     -> connects fine         (Internet + Transport layers: healthy)

That gap is exactly why "the network is down" is rarely a useful sentence on its own. Four layers, four independent things that can fail, and this incident narrows it to one of them before anyone touches a router.

Where the two models get confused

  • Believing TCP/IP replaced OSI as a standard. OSI was never an implemented protocol suite in wide production use to begin with; TCP/IP won on adoption, not by formally superseding a competing standard.
  • Assuming the "Internet layer" and "the internet" mean the same scope. The Internet layer is just IP's job — routing packets between networks — whether that's your home LAN talking to your ISP or a packet crossing five continents.
  • Forgetting that OSI layer numbers (3, 4, 7) are still the common shorthand, even in tools and documentation that are otherwise entirely TCP/IP-based. Nobody markets a "TCP/IP Internet-layer firewall"; they call it a Layer 3 firewall.

A follow-up an interviewer may ask

If you explain the OSI-versus-TCP/IP mapping cleanly, expect a follow-up like: "if TCP/IP only has four layers, why does everyone still say 'Layer 7 firewall' instead of 'Application-layer firewall'?" The honest answer is habit plus precision — OSI's numbers are a finer-grained, universally understood shorthand that predates most of the tooling people use today, and switching to TCP/IP's own names would actually lose information, since TCP/IP's Application layer alone covers what OSI splits into three. Saying "Layer 7" instead of "Application layer" isn't wrong or old-fashioned; it's the more precise statement in a world where the two vocabularies are used interchangeably anyway.

Practice exercises

  1. Draw the four TCP/IP layers alongside the seven OSI layers and connect each TCP/IP layer to the OSI layers it covers, without looking back at the table above.
  2. A colleague describes a firewall rule as "Layer 4 filtering based on port 443." Explain, using this article's vocabulary, exactly what information that firewall is and isn't looking at.
  3. Trace the same web request example from this article, but for a ping command instead of an HTTPS request — which TCP/IP layers does ICMP (the protocol ping uses) touch, and which does it skip?

Exercise 3 exposes something the diagram above quietly hides. Every layer in that walkthrough had an address of its own: port numbers at Transport, IP addresses at Internet, MAC addresses at Link. ping skips the Transport layer entirely, so it has no port number at all — yet it still reaches exactly one host, because the Internet layer's addressing is enough on its own. That addressing scheme is the backbone of everything above it, and it's what IP addressing (IPv4, IPv6) takes apart in detail.

Sources