The OSI and TCP/IP Models

Try, for a moment, to actually hold the whole journey of a single email in your head at once: the words you typed, encoded into bytes; those bytes broken into chunks and numbered so they can be reassembled in order; each chunk wrapped in an envelope carrying a destination address; that envelope handed to hardware that turns it into electrical pulses, or light, or radio waves; those pulses crossing wires, switches, routers, undersea cables, and satellite links you will never see; and, at the far end, every single one of those steps unwound in reverse until your friend's inbox shows a message that looks, to them, like it simply appeared. Nobody holds that entire journey in their head while writing an email client, and nobody needs to. That is not an accident. It is the result of one of the most quietly important ideas in the whole history of computing: layering.

Networks are staggeringly complex machines built out of staggeringly simple, narrow agreements. The engineer who designs a Wi-Fi radio chip does not need to understand HTTP. The developer building a web application does not need to understand how radio waves carry a bit through the air. Each of them only needs to know how to talk to the layer directly above and directly below their own — a discipline engineers call separation of concerns — and an entire global system holds together because everyone honored that one narrow agreement. This chapter is about the two attempts to write that agreement down formally: the OSI model and the TCP/IP model. They are not competing technologies you have to choose between. They are two different maps of the exact same territory, drawn for two different purposes, and you will use both vocabularies for the rest of your career without ever having to pick a favorite.

Layering is what lets millions of engineers build on top of each other's work without any one of them understanding the whole stack.

The OSI Model: A Seven-Layer Cake, Baked to Be a Reference

In 1984, an international standards body sat down and asked a genuinely ambitious question: could you describe any possible networking technology, present or future, wired or wireless, in one universal set of layers precise enough to be useful and general enough to never go obsolete? The answer they produced was the Open Systems Interconnection model, seven layers stacked like a cake, each one responsible for exactly one job and nothing else.

Read from the bottom, the way data actually leaves a machine, the layers are:

1. Physical — cables, switches, raw signals: voltage levels, light pulses, radio waves. The roads and wires themselves.
2. Data Link — frames and MAC addresses, responsible for getting data reliably across a single physical link or local segment. The traffic lights and intersections that keep one street usable.
3. Network — IP addresses and routers, responsible for finding a path across many interconnected networks at once. The GPS and the street names.
4. Transport — TCP and UDP, ports, responsible for reliability, ordering, and knowing which application on a device should receive the data. The delivery trucks and their tracking numbers.
5. Session — the management of starting, maintaining, and cleanly ending a dialogue between two applications. The conversation itself, as distinct from anything said within it.
6. Presentation — encryption, compression, and encoding, making sure both ends agree on the format the data is actually in. The translators and the gift wrap.
7. Application — email, the web, file transfer: the layer your own programs actually touch and the only one most users ever consciously notice.

+-------------------+
| 7. Application    |
+-------------------+
| 6. Presentation   |
+-------------------+
| 5. Session        |
+-------------------+
| 4. Transport      |
+-------------------+
| 3. Network        |
+-------------------+
| 2. Data Link      |
+-------------------+
| 1. Physical       |
+-------------------+

Think of mailing a package. You wrap the contents in something both you and the recipient will understand (Presentation), write an address on the outside (Network), and hand the whole thing to a courier who tracks it in transit (Transport) — and at every step, the courier never opens the box to see what is inside, the same way a router never inspects the contents of the packet it forwards, only the address on the front.

The TCP/IP Model: Built From Working Code, Not a Committee Room

Where OSI was designed top-down, on paper, before most of its subject matter existed in working form, the TCP/IP model grew the opposite way: bottom-up, out of protocols that were already running on real machines, later organized into four layers because four layers happened to describe what those protocols were already doing. It is the model the actual internet runs on, today, right now, underneath this very sentence reaching you.

1. Link — Physical and Data Link combined: wires, Wi-Fi, Ethernet.
2. Internet — IP and routing: addresses and the maps between them.
3. Transport — TCP and UDP: reliable delivery, or fast delivery, depending what you need.
4. Application — HTTP, FTP, SMTP, DNS: the web, email, and everything built on top.

+-------------------+
| 4. Application    |
+-------------------+
| 3. Transport      |
+-------------------+
| 2. Internet       |
+-------------------+
| 1. Link           |
+-------------------+

Four lanes on one highway, each with its own job, together getting your data where it needs to go. The Internet layer in particular was deliberately engineered for resilience under the assumption that parts of the underlying network might simply stop working — a link goes down, a router crashes, a cable gets sliced by a backhoe — and data should still be able to find some surviving path to its destination rather than simply failing.

Two Maps of the Same City

Lay the two models side by side and the relationship becomes almost effortless to see: everything OSI splits into Physical and Data Link, TCP/IP simply calls Link. Everything OSI calls Network, TCP/IP calls Internet. Transport keeps its name in both. And everything OSI spreads across Session, Presentation, and Application, TCP/IP folds into one broad Application layer, on the theory that whatever job Session or Presentation was doing, some real-world protocol at the top will simply absorb it.

Neither map is wrong, and neither one makes the other obsolete. OSI is the architect's exhaustive blueprint, precise enough to describe a technology that has not been invented yet. TCP/IP is the house people actually live in, built with a few rooms deliberately merged together because that is how it was practical to build it. When you hear an engineer casually call a switch "a Layer 2 device" and a router "a Layer 3 device," now you know exactly what they mean without translating: switches make their forwarding decisions using Data Link addresses (MAC addresses), and routers make theirs using Network addresses (IP addresses) — two different jobs, at two different altitudes of the same stack, regardless of which of the two models you happen to be thinking in at the moment.

Watching an Email Fall Through Every Layer

It is worth walking through one ordinary action, slowly, layer by layer, because doing so turns this whole chapter from an abstract diagram into something closer to a mechanism you can actually picture turning.

You write an email, and your mail client speaks a protocol called SMTP to hand it off — that is the Application layer doing its job. If your mail provider uses modern encryption, the message is encoded and encrypted before it travels, technically Presentation's responsibility even though in practice it is implemented right alongside Transport. A connection is opened and kept alive long enough for the whole exchange to finish, which is the Session layer's entire purpose. The message itself is broken into numbered segments and handed to TCP, which will notice if any segment goes missing in transit and demand it be resent — Transport, doing exactly what its name promises. Each of those segments is wrapped in a packet carrying a source and a destination IP address, which is the Network layer deciding where the packet needs to go. That packet is then framed with MAC addresses so it can cross the specific physical wire or radio link in front of it right now — Data Link, solving a much more local problem than the Network layer just solved. And finally, all of that structure is torn down into nothing more than raw electrical signals, light pulses, or radio waves — the Physical layer, indifferent to everything happening above it, faithfully carrying bits it has no concept of understanding.

On the real internet, TCP/IP handles all of this in four named layers instead of seven, but notice that every single job on that list still has to happen somewhere — OSI just insists on giving each one its own explicit shelf, which is precisely why it remains such a good teaching tool even after losing the race to become the internet's actual implementation.

OSI Model:    [Physical] -> [Data Link] -> [Network] ->
              [Transport] -> [Session] -> [Presentation] ->
              [Application]
TCP/IP Model: [Link] -> [Internet] -> [Transport] -> [Application]

Why This Chapter Is a Foundation, Not Trivia

It would be easy to read this chapter as a list of names to memorize for a quiz, and it would also be a genuine waste of what layering actually buys you. The reason HTTP, the protocol behind virtually every website on Earth, can be designed entirely without caring whether it is riding over Wi-Fi, fiber, or a satellite link underneath, is layering. The reason a company can swap its office internet provider without rewriting a single line of its web application is layering. The reason this book can teach you TCP in Part 2 without first making you understand how copper or glass physically carries a single bit is, again, layering — the exact same idea, working quietly in the book's own structure the way it works in every real network you will ever touch.

Keep this mental picture close as you move forward: every time you use an app, a stack of these layers is quietly assembling and disassembling your data, each layer trusting the ones above and below it to do their one job correctly and nothing more. Once you start writing real networked programs in Go, beginning in the Go Fundamentals part of this book, you will find yourself working almost entirely at the Transport and Application layers — opening connections, sending requests, reading responses — while everything below silently keeps its own promises without you ever having to ask it to.

Frequently Asked Questions

If the internet actually runs on TCP/IP, why do engineers still talk about OSI's seven layers at all? Because OSI never won the implementation race, but it did win the vocabulary war, and those are two separate contests. TCP/IP describes what is really running underneath this very sentence, while OSI survives as the shared language engineers reach for when they say something like "is this a Layer 2 or a Layer 3 problem" — a precision TCP/IP's folded-together Application layer simply cannot offer in the same way.

Was TCP/IP really designed to survive a nuclear war? That is the popular legend, but it oversimplifies the actual history. The genuine design goal was resilience against the mundane failures researchers pictured day to day — a router crashing, a cable severed by construction equipment, a link down for maintenance — and a network resilient enough to shrug those off happens to also survive catastrophic damage as a fortunate side effect, not because catastrophe was the design brief.

Where did Session and Presentation actually go in the model the internet runs on? They did not vanish, they just stopped getting their own dedicated shelf. TCP/IP folds both jobs into its single broad Application layer, on the theory that whatever real protocol sits at the top will simply absorb that responsibility itself — TLS, for instance, handles encryption, technically Presentation's job, while sitting logically between Transport and Application in essentially every real implementation.

Why does a router only look at the address on a packet and never peek inside it? Because that is precisely what letting each layer trust the ones around it is for — the courier in the mailing-a-package analogy never opens the box, the same way a router only ever reads the destination address a Network-layer packet carries. If routers had to understand the contents of every packet they forwarded, the entire benefit of layering — engineers building on top of each other's work without understanding the whole stack — would collapse.

Now that I understand the layers, which ones will I actually be writing code against? Almost entirely Transport and Application — opening connections, sending requests, reading responses — while everything below quietly keeps its own promises without you needing to ask. That is exactly where this book heads next: the Go Fundamentals part teaches you to write real networked programs sitting right at that boundary, without ever requiring you to understand how copper or glass physically carries a single bit first.

Fun Facts and Notes

• The OSI model is sometimes remembered with the mnemonic "Please Do Not Throw Sausage Pizza Away," one letter per layer from Physical up to Application — a genuinely silly sentence that has, by simple repetition, outlived several networking technologies it was coined to help people memorize.
• OSI was finished in 1984, a full decade after Vint Cerf and Bob Kahn began designing TCP/IP in 1974 — the "universal reference model" arrived after the internet's actual foundation had already been poured.
• Every time you load a web page, your browser is quietly performing the entire seven-step (or four-step) journey described in this chapter, from a line of text you typed down to raw light in a fiber and back up again, in well under a second, without ever once asking for your attention.