The OSI Model: 7 Layers Explained
The OSI model splits network communication into seven layers, from the physical cable (layer 1) to the application (layer 7). Each layer has one job and talks only to the layers directly above and below it. The model is a teaching and troubleshooting tool; the real internet uses the simpler four-layer TCP/IP model.
The seven layers
Data is passed down the layers on the sending side, and each layer adds its own header. This is called encapsulation. The receiver removes the headers in the opposite order. The unit of data at each layer is called a PDU (protocol data unit).
| Layer | Name | PDU | Example protocols | Typical devices |
|---|---|---|---|---|
| 7 | Application | Data | HTTP, DNS, SMTP, SSH | Proxy, application firewall |
| 6 | Presentation | Data | TLS (partly), character encodings, MIME | - |
| 5 | Session | Data | RPC, NetBIOS session, TLS (partly) | - |
| 4 | Transport | Segment (TCP) or datagram (UDP) | TCP, UDP | Firewall, load balancer |
| 3 | Network | Packet | IP, ICMP, OSPF | Router, layer 3 switch |
| 2 | Data link | Frame | Ethernet, Wi-Fi (802.11), ARP | Switch, access point |
| 1 | Physical | Bit | Ethernet cabling, fiber, radio | Cable, hub, repeater |
OSI compared with TCP/IP
The TCP/IP model has four layers and matches how protocols were really built. The mapping is approximate:
| TCP/IP layer | OSI layers |
|---|---|
| Application | 7, 6, 5 |
| Transport | 4 |
| Internet | 3 |
| Link (network access) | 2, 1 |
Some books show TCP/IP with five layers, splitting the link layer into data link and physical. In daily work people still say "layer 2 switch" or "layer 7 firewall" using OSI numbers, so it is useful to know both.
What happens when you open a website
Imagine you type https://example.com in your browser.
- Layer 7: the browser needs an address, so it sends a DNS query for example.com. Later it sends an HTTP request.
- Layer 6/5: a TLS handshake negotiates encryption keys and checks the server certificate.
- Layer 4: TCP opens a connection to port 443 with a three-step handshake (SYN, SYN-ACK, ACK) and splits the data into segments.
- Layer 3: IP puts the source and destination addresses into packets. Routers forward them hop by hop.
- Layer 2: on each link, the packet is placed in a frame with MAC addresses. ARP finds the MAC address of the next hop on IPv4 networks.
- Layer 1: the frame becomes electrical signals, light pulses or radio waves.
On the server, the same steps run in reverse order, from layer 1 up to layer 7.
Which layer does each tool test?
Each network check proves that the layers up to a certain point work. The table shows where our tools fit.
| Tool | Layer | What it proves |
|---|---|---|
| Ping | 3 (ICMP) | The host is reachable at the IP level and how long a round trip takes |
| Traceroute | 3 | Which routers are on the path and where delay or loss starts |
| Port checker | 4 (TCP) | A TCP connection to a given port can be opened |
| SSL checker | 6/5, over 4 | The TLS handshake works and the certificate is valid |
| HTTP headers | 7 | The web server answers and which status and headers it sends |
| DNS checker | 7 | Name servers return the expected records |
Three details need care:
- TLS does not fit one layer. In the OSI model it is often placed at layer 6 (encryption and presentation), sometimes at layer 5 (session). In the TCP/IP model it is simply part of the application layer, running on top of TCP. For troubleshooting, it is enough to know that TLS works after TCP and before HTTP.
- Ping can fail on a working host. Many firewalls drop ICMP echo requests. A failed ping does not always mean the host is down, so check the port as well. Also, traceroute uses the TTL field in IP packets and ICMP time-exceeded replies, and some routers do not answer, which shows as a gap in the output.
- DNS runs on layer 7 even though it is needed before everything else. It normally uses UDP port 53, and TCP port 53 for large answers and zone transfers.
Troubleshooting bottom-up
A reliable method is to start at layer 1 and move upward. Each step removes a whole group of possible causes.
- Layer 1: Is the cable connected, the Wi-Fi on, the link light lit?
- Layer 2: Does the device have a link to the switch or access point? Is the VLAN right? Check for duplicate MAC addresses or a wrong Wi-Fi password.
- Layer 3: Does the device have a valid IP address, mask and gateway? Can it ping the gateway, then an outside address such as
192.0.2.1? Use traceroute if the path fails halfway. See what an IP address is and subnetting for common addressing mistakes. - Layer 4: Is the port open and not blocked by a firewall? See well-known ports.
- Layers 5-6: Does the TLS handshake succeed? Look for an expired certificate, a wrong name or an unsupported protocol version.
- Layer 7: Does the name resolve, and does the application return a correct response?
In practice, you can also work top-down or split the problem in the middle: if a port check works, layers 1 to 4 are fine, and you can focus on the application.