The OSI model, useful even though it's mostly wrong
The OSI model, useful even though it's mostly wrong
You'll hear networking people talk about "Layer 4" and "Layer 7" constantly. They're referring to the OSI model: a seven-layer abstraction of networking that was designed in the late 1970s by ISO (International Organization for Standardization) and ITU.
The model is genuinely useful as a vocabulary. It's also, in important ways, wrong about how the actual internet works. This article explains both.
The seven layers
7. Application (HTTP, FTP, SMTP, your game's protocol)
6. Presentation (data format, encoding)
5. Session (session management)
4. Transport (TCP, UDP)
3. Network (IP)
2. Data Link (Ethernet)
1. Physical (cables, radio)
A mnemonic from the bottom up: "Please Do Not Throw Sausage Pizza Away" (Physical, Data link, Network, Transport, Session, Presentation, Application).
The idea: each layer provides services to the layer above and uses services from the layer below. Different technologies can be combined at different layers. Theoretically pure.
What the layers actually do (in theory)
Layer 1: Physical. The wires, the radio waves, the optical signals. Bits become physical phenomena.
Layer 2: Data Link. Frames on a local network. Ethernet, Wi-Fi. MAC addresses live here.
Layer 3: Network. Packets that can cross networks. IP lives here. Routing happens here.
Layer 4: Transport. End-to-end communication. TCP and UDP. Reliability, ordering, ports.
Layer 5: Session. Managing conversations between applications.
Layer 6: Presentation. Data format, encryption, compression.
Layer 7: Application. The actual application protocols. HTTP, SMTP, your game's protocol.
When you send a packet, conceptually it traverses down through these layers, becomes physical signals, travels, and traverses back up at the destination.
Why it's "mostly wrong"
The OSI model was specified in detail (the actual OSI protocol suite, called X.200) and never won. The internet uses TCP/IP, which the IETF developed in parallel.
TCP/IP has fewer layers (typically described as 4 or 5):
4. Application (HTTP, etc., often collapsing presentation and session in)
3. Transport (TCP, UDP)
2. Internet (IP)
1. Link (Ethernet, Wi-Fi)
(0. Physical, sometimes treated separately)
So in practice:
- Layers 5 and 6 of OSI (Session and Presentation) don't really exist as distinct layers in TCP/IP. Their functions are folded into applications.
- Layer 4 (Transport) maps cleanly between models.
- Layers 3, 2, 1 also map cleanly.
The "7 layers" mental model is approximate. The actual stack is simpler.
Why we still use the terminology
Despite the mismatch, the OSI vocabulary persists because:
The numbers are convenient labels. "Layer 4 load balancer" is shorter and more universal than "TCP/UDP-level load balancer."
The conceptual layers are real, even if the model isn't precise. The distinction between routing (Layer 3), transport (Layer 4), and application (Layer 7) is genuine and important.
Documentation and tools use the terms. AWS NLB is "Layer 4." AWS ALB is "Layer 7." HAProxy has "TCP mode" (L4) and "HTTP mode" (L7).
Networking certifications drilled it into a generation of engineers. It's the lingua franca.
What people mean by "Layer X"
In practice, when networking people say "Layer X," they usually mean:
Layer 1: Physical media. Cables, radios. Layer 2: Ethernet, Wi-Fi, MAC addresses. Layer 3: IP. Routing. Layer 4: TCP, UDP. Ports. Layer 7: HTTP, application protocols.
Layers 5 and 6 are rarely referenced because they don't have clean correspondences in real systems.
If someone says "this is a Layer 7 attack," they mean an HTTP-level attack. If someone says "Layer 4 protection," they mean TCP/UDP-level filtering.
Encapsulation, in the OSI model
When data flows down through layers, each layer adds its own header (encapsulation). When it flows back up, each layer strips its header (decapsulation).
In practice on the modern internet, layers 5 and 6 mostly don't map cleanly. People often skip them in conversation. The useful split is "app (L7), transport (L4), network (L3), link (L2)". Hence "the OSI model is mostly wrong, but useful anyway". The receive side unwraps in reverse.
This is correct in real systems too. The TCP/IP stack does add headers as it goes down and strips them coming up. The vocabulary is just less granular than OSI's seven layers.
L4 vs L7 distinction
The most operational use of the layer concept: distinguishing between L4 (TCP/UDP-level) and L7 (application-level) tooling.
L4 tooling operates on the TCP/UDP layer:
- L4 load balancers (covered in the previous article).
- L4 firewalls (filter by source IP, port).
- TCP-level proxies.
- Many DDoS protection layers.
L7 tooling operates on the application protocol:
- L7 load balancers (HTTP-aware).
- WAFs (Web Application Firewalls).
- HTTP proxies.
- Application-aware analyzers.
The L4 vs L7 choice for any tool affects:
- What kinds of decisions it can make.
- How much CPU it uses.
- What protocols it supports.
- What encryption boundaries it has to handle.
Layer 2 and below, in modern networks
Layer 2 (Ethernet, Wi-Fi) is mostly invisible to applications. You don't usually think about MAC addresses unless you're doing low-level networking.
Layer 1 (physical) is mostly invisible too. You plug in the cable; the bits flow.
These layers matter for:
- Network hardware engineers.
- Data center networking.
- Wireless tuning.
- Some specific configurations (jumbo frames, VLAN tagging).
For most application developers and even most sysadmins, Layers 1-2 are someone else's problem.
The "OSI model is wrong" critique
A few specific reasons the model doesn't match reality:
No clean Layer 5 in TCP/IP. Sessions are managed by applications, not by a distinct layer.
Layer 6 (Presentation) doesn't exist as a layer. Data format (JSON, XML, binary) is just part of the application.
The "session" concept doesn't really fit TCP. A TCP connection is a transport-layer thing. Application sessions are usually overlaid on TCP connections.
TLS doesn't fit cleanly. It sits "between" transport and application. Sometimes called Layer 5.5 jokingly.
Modern protocols mix layers. QUIC, HTTP/3, WebSockets all blur lines that the OSI model assumes are distinct.
Despite all this, the layer numbers persist as useful shorthand.
What you actually need to know
For most networking work:
- Layer 2: local network, MAC addresses, Wi-Fi / Ethernet. Mostly for setup and troubleshooting.
- Layer 3: IP addresses, routing. For diagnosis (ping, traceroute) and configuration (firewalls).
- Layer 4: TCP and UDP. For port-level filtering and load balancing.
- Layer 7: HTTP and application protocols. For application-level routing, WAF rules, etc.
Layers 1 and 5-6 are rare in everyday vocabulary.
If you can recognize:
- "Layer 3 routing" = how IP packets get from network to network.
- "Layer 4 load balancing" = TCP-level distribution across backends.
- "Layer 7 attack" = HTTP-level exploitation.
You can follow most networking conversations.
A practical example
A DDoS attack might be described as:
Layer 3/4 attack: floods IP / TCP at the network/transport layer. Mitigation: filter packets at the LB, drop bad sources at the edge.
Layer 7 attack: well-formed HTTP requests that exploit application weaknesses. Slow POST, SQL injection, brute force. Mitigation: WAF rules, rate limiting, application hardening.
These attacks look different at different layers. The defenses differ. The vocabulary lets you talk about them precisely.
Conclusion
The OSI model is a 1970s vision of how networking should work. The internet didn't follow it precisely. But the vocabulary stuck because the layered concept is genuinely useful, and because "L4 load balancer" is shorter than "TCP/UDP-level traffic distribution device."
You don't need to memorize all 7 layers. You need to recognize the words and roughly know what they mean. L2 is local network. L3 is IP. L4 is TCP/UDP. L7 is application. Anything else, look up if you need it.
The model is a tool. Use it. Don't worship it.
End of Series B
Series B is complete. We've covered the operational and architectural concepts that networking professionals work with daily:
- Autonomous systems (ASNs).
- BGP.
- BGP hijacks and RPKI.
- Peering and transit.
- IXPs.
- Anycast.
- GRE tunnels.
- CGNAT.
- MTU and PMTUD.
- Reverse proxies.
- Load balancing.
- The OSI model.
Together with Series A's foundations, you now have a working knowledge of the internet's mechanics from the wire up through the application layer. The next series shifts perspective: instead of describing how it works, we'll tell the story of how it got built.
Hosting your game server with AndroHost means we handle most of what's in this post for you automatically: tier sizing, SRV records, off-site backups, DDoS protection.
Keep reading
What a DDoS actually looks like to a Minecraft server, and what protection means
"DDoS protection" is on every hosting marketing page. Most people who pay for it don't know what it does, how attacks actually work, or what level of protection is enough. This article explains, in honest terms, what to expect.
Cheating, anti-cheat, and the role of the network
Cheating in multiplayer games has existed since multiplayer games existed. The cat-and-mouse between cheaters and developers has produced an entire industry of anti-cheat technology, much of which has networking implications.
Why your server's IP being public is fine, and when it isn't
A game server has an IP address. Players connect to it. The IP is, by definition, reachable from the internet. Many server owners feel uneasy about their IP being known, often because they don't know what risk it actually represents.