OSI vs TCP/IP

Somebody on the incident call just said “that’s a layer 4 problem” and somebody else disagreed. One of the two models being argued from describes what is running on the wire; the other never did. Those are different questions with different right models. OSI was written as a teaching reference, after the fact, for describing network communication in general. TCP/IP is what the protocols on the machine in front of you actually do. Knowing which one you are reaching for is most of the question.

Where the seven collapse into four#

Two of the four mappings above are exact: OSI’s transport layer is TCP/IP’s transport layer, and OSI’s network layer is TCP/IP’s internet layer — same job, same box, nothing funnels. TCP/IP’s network access layer absorbing OSI’s data link and physical layers is almost as clean: putting a frame together and putting bits on a wire really are one concern at the level of a NIC and its driver, so folding two OSI layers into one TCP/IP layer costs nothing real.

The application-layer collapse is the one worth being careful about. OSI’s application, presentation and session layers all become a single TCP/IP application box — not because that work stopped existing, but because presentation and session are the two OSI layers with no distinct implementation anywhere in the TCP/IP stack. Encoding negotiation, encryption and session state are all real work real software does. There is just no protocol that owns “presentation” or “session” the way TCP owns transport; that work happens inside whatever sits at the application layer, or beside it, instead of at a layer built to hold it. HTTP, DNS and SMTP all sit in that one box regardless of how different their jobs are, which is exactly why “layer 7” ends up describing so much more ground than “layer 4” does.

Why the seven-layer model survived anyway#

If nothing ships an OSI stack, the honest question is why anyone still teaches seven layers. The answer is that OSI was never trying to describe an implementation — it gives a room of engineers a shared way to say where a fault sits. “That’s a layer 2 problem” means switching and MAC addresses, not routing, not a socket, not application code, in three words. TCP/IP’s four layers cannot make that same claim as precisely, because its one network-access layer covers both the wire and the frame that OSI keeps separate.

Vendors and exams lean on the same numbers for the same reason. A “layer 3 switch” is marketing shorthand for a switch that also routes — the number is doing the work a sentence would otherwise have to do. Certification tracks that ask for OSI by number are testing a vocabulary you will need regardless of what you actually run, because incident channels and vendor spec sheets assume you already know what “layer 2” means.

Picking one on purpose#

The trade is not accuracy against inaccuracy — it is precision against vocabulary. TCP/IP describes what is actually running, so read it when you need to know what a socket, a router or a NIC driver is doing. OSI describes nothing that ships, so reach for it only when you are naming which part of a system a problem belongs to, out loud, to someone else. Mixing the two up costs nothing when you are alone at a whiteboard. It costs real minutes on a call, where one person means “the packet never left the box” and another means “the request got a 502,” and both are saying “layer 7” while pointing at different failures.

The clearest place this goes wrong is a “layer 7 load balancer.” The phrase is industry shorthand, not a precise claim about which OSI layer the box occupies — it is really terminating TLS and routing the request on an HTTP header, both of which sit above a plain “handles application data” description. Underneath all of that is still an ordinary TCP socket with its own timeout, a layer 4 concern, and that socket timeout is very often the thing that actually bites: the load balancer gives up on the backend at thirty seconds while the backend needed one more second to finish. An API on the other end of that kind of timeout has to treat the retry that follows as a routine case, not an edge case. On an incident call, a room arguing about which numbered layer the load balancer belongs to is a room not asking which component is holding the connection and what it does when that connection times out — and that argument is how a call that should take ten minutes stays stuck for an hour.

Neither the count nor the names are settled, and the specification is the place that shows it. RFC 1122, which is where the four layers are actually written down, calls the bottom one the link layer — not “network access,” the name the boxes above use because it is the one most courses and diagrams teach. Other texts split that same layer into link and physical and call the model five, closer to OSI’s own bottom pair. So the label in the box is a teaching convention and the count is a matter of where someone chose to draw a line; the mapping between the boxes is what does the actual work of saying which components exist. The distributed-systems path is taking shape around the layer failures that show up once more than one machine has to agree on anything.