OSI, TCP/IP, and Why We Compressed Seven Into Four

Every network engineer ever has been taught two reference models: the seven-layer OSI model, and the four-layer TCP/IP model. Both describe the same act — getting a packet from your laptop to a server — at different levels of abstraction.

The OSI model has seven layers, from bottom to top:

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

The TCP/IP model has four layers, often described as:

1. Link (sometimes split into Physical + Data Link)
2. Internet (the IP layer)
3. Transport (TCP, UDP)
4. Application (HTTP, SMTP, DNS, your code)

Where did the missing three layers go? They were absorbed. The OSI Session, Presentation, and Application layers all live inside the TCP/IP "Application" layer. In practice, real applications mix session management, data encoding, and business logic together. The OSI model split them apart neatly for teaching purposes; the real internet collapsed them for engineering simplicity.

Why bother knowing both?

Because the OSI vocabulary still pervades the industry. When somebody says "this is a Layer 2 problem" or "this happens at Layer 7," they are speaking OSI. When somebody says "the TCP stack," they are speaking TCP/IP. You will hear both. You should be fluent in both.

The mental model that actually matters is the flow. A network call starts at the top, where your code says "fetch this URL." It is then encapsulated, layer by layer, on the way down:

• The application layer wraps the request in an HTTP envelope.
• The transport layer wraps that in a TCP segment with port numbers.
• The internet layer wraps that in an IP packet with source and destination IP addresses.
• The link layer wraps that in an Ethernet frame with source and destination MAC addresses.
• The physical layer turns the whole thing into electrical pulses, light pulses, or radio waves.

On the receiving end, the process runs in reverse. Each layer unwraps the layer above it and hands it up.

Every layer adds a small overhead. Every layer also adds a tremendous amount of value, because each layer solves a different problem and lets the others ignore it. This is the cleanest example of separation of concerns in all of computer science.

For the next four chapters we are going to walk up that ladder, one layer at a time, and look at what each one actually does.

Quick TCP vs. UDP refresh, before we get there.

You will be asked this in interviews until you die. Let's settle it.

TCP is a connection-oriented, reliable transport protocol. Before any data flows, two endpoints perform a three-way handshake: SYN, SYN-ACK, ACK. After that, every packet sent is acknowledged by the receiver. If a packet is lost, TCP retransmits it. Packets are reassembled in order at the receiver, even if the network delivers them out of order. TCP also performs congestion control, slowing down the sender when the network is loaded.

The cost of all that reliability is overhead. The three-way handshake adds a full round-trip before any real data moves. Acknowledgements consume bandwidth. Congestion control deliberately reduces throughput in some conditions. For most applications, this is a great trade — you do not want a missing byte in your bank transaction or your web page. You want correctness.

UDP is a connectionless, unreliable transport protocol. It just sends packets. No handshake, no acknowledgement, no retransmission, no ordering guarantee. If a packet is lost, it is lost. If it arrives out of order, the application has to deal with it.

This sounds worse — and for most things, it is. But for some applications, the latest data matters more than the missing data. Live video. Live audio. Multiplayer games. If a single video frame is lost, you do not want the codec to pause everything and ask for it back; you want it to drop the frame and move on with the next one. UDP gives you that freedom. It is fast, it is light, and it does not pretend to be reliable.

A quick correction to a common misconception: the three-way handshake is for session setup. It is not performed for every packet. Once the connection is established, TCP transfers data continuously across that connection, with acknowledgements interleaved but no new handshakes. People sometimes confuse "TCP acknowledges every packet" (true) with "TCP handshakes for every packet" (false). Notice the difference.

Push On It

1. Draw the OSI 7-layer model on paper. Next to each layer, write the name of one real protocol or technology that operates there.
2. Open Wireshark (or any packet capture tool). Capture traffic while you load a single web page. Identify the TCP handshake. Count how many packets it took to load the page.
3. Find one application on your machine that uses UDP rather than TCP. Hint: video calls, DNS, online games. Read about why the designers chose UDP. Could it have been built on TCP? What would have been worse?