The OSI model splits network communication into seven layers: physical, data link, network, transport, session, presentation and application. Each layer serves the one above it. Engineers use it as a shared vocabulary for finding where a problem or an attack sits, even though real networks run on the simpler TCP/IP stack.
What are the seven layers?
The model comes from the ISO and IEC standard 7498-1, which we could not open for this review, so check the standard itself for its formal text. The common summary, from the bottom:
- Physical. Signals on a wire, fibre or radio link.
- Data link. Frames between neighbouring devices on one network, and hardware addresses. Ethernet and Wi-Fi live here.
- Network. Addressing and routing between networks. IP lives here.
- Transport. Delivery between programs on two hosts, with ports. TCP and UDP.
- Session. Setting up, managing and ending conversations.
- Presentation. Data representation, encoding and sometimes encryption.
- Application. The protocols programs speak, such as HTTP, DNS and SMTP.
How does it relate to TCP/IP?
The Internet protocol suite predates widespread use of OSI and groups things differently. RFC 1122, the host requirements standard, states that it covers the communication protocol layers: link layer, IP layer and transport layer. A companion document covers the application layer.
So TCP/IP has four layers, and the OSI session and presentation layers have no separate home in it. Those functions happen inside applications and libraries, for example TLS handling encoding and encryption. That is why arguments about which layer TLS belongs in never end. Use the model as a map, not a rulebook.
Where do attacks land?
Mapping attacks to layers tells you which control can stop them.
- Physical: cutting cables, jamming radio, plugging into an exposed port. Controls are locked rooms and port security.
- Data link: attacks on local networks, such as spoofing hardware addresses. Controls include port authentication and switch protections.
- Network: spoofed source addresses and routing abuse. RFC 2827 describes network ingress filtering to defeat attacks that use forged source addresses.
- Transport: SYN floods and port scans. RFC 4987 documents TCP SYN flooding and its mitigations. RFC 9293 gives the connection rules scanners rely on.
- Session and presentation: hijacked sessions, downgraded encryption. TLS 1.3 in RFC 8446 adds downgrade protection.
- Application: injection, broken authorization and abuse of business logic. OWASP lists these for web and API software.
A constructed debugging walk
An office reports that a payroll site will not load. A technician works up the stack. Link lights are on, so layer 1 is fine. The laptop has an address and can ping the router, so layers 2 and 3 work. Pinging the payroll server's address succeeds, but connecting to port 443 hangs: a transport problem. A firewall rule change that morning dropped traffic to that port.
Five minutes, and the problem is found without reading a single web server log. Bottom up troubleshooting is the real value of the model.
Where does it mislead?
Real protocols rarely fit neatly. Some devices work across several layers: a modern firewall may inspect layer 3 and layer 7 together. Attacks chain across layers, so a phishing email at layer 7 can lead to a stolen session that gets used over a layer 4 tunnel. And many security failures sit above everything the model describes, in people and process.
Do not memorise the layers to pass a test and stop. Use them to ask what a given control can and cannot see.
How to check or apply this
- Draw your stack from the network edge to your application, and label each hop with its layer.
- For each control you run, note which layers it inspects.
- Find the layers where you have no control or no logging.
- Troubleshoot bottom up: link, address, route, port, protocol, application.
- When reading an attack report, tag each step with its layer and check you have a control there.
- Remember the TCP/IP four layer view when reading RFCs.
Quick check
Is the OSI model used on the internet?
The internet runs on TCP/IP. OSI survives as a teaching and troubleshooting model that gives layers common names.
Which layer is HTTPS?
HTTP is at the application layer. TLS sits between it and TCP, and where it belongs in OSI terms is debated.
Sources
- ISO/IEC 7498-1 (catalogue page; could not be opened for this review)
- RFC 1122, Requirements for Internet Hosts, Communication Layers
- RFC 9293, TCP
- RFC 4987, TCP SYN Flooding Attacks and Common Mitigations
- RFC 2827, Network Ingress Filtering
- RFC 8446, TLS 1.3
Last reviewed: 18 October 2026.
