What is the OSI Model: A Complete Explanation of the Seven Layers and Their Role in Networking
Jump to Section:
The OSI (Open Systems Interconnection) model is a reference architecture that divides the data transmission process into seven layers. Each layer performs its own task and interacts only with its neighbors. This division is similar to a multi-story building: each floor has its own function, but together they form a unified system.
The OSI model is not a protocol, but a language for describing networks. It is designed to allow engineers, developers, and administrators to communicate clearly about TCP segments, Ethernet frames, or the HTTP protocol.
The model emerged in 1984 as the international standard ISO/IEC 7498. It didn’t become a true internet stack, as TCP/IP was already actively developing at that time. However, OSI has become established in IT as a benchmark: it’s used for training, architecture design, and network problem diagnostics.
Where is the OSI reference model used?
Today, the OSI model is found everywhere, even if the OSI protocols themselves are not used in real networks:
- Students and aspiring engineers are taught to think in layers. For example, in the first year, you might explain that Ethernet OSI is a Layer 2 layer, while in the senior year, you’ll learn how TCP manages segments at Layer 4.
- In technical specifications, it is more convenient to write that the problem is at the network level than to list details about IP address routing.
- When a data center admin says, “We’re seeing packet loss on L3,” colleagues immediately understand that the problem is with the router or IP routing, not the cable.
The OSI model has become a universal vocabulary for networking professionals.
Use in training, documentation, and debugging.
One of the main uses of OSI is to explain networks in simple terms. Teachers like to compare the model to sending a letter:
- On a physical level, it is an envelope delivered by a postman.
- On the channel, there is the address of the apartment.
- On the network – the route through the city.
- On transport – a guarantee that the letter arrived without loss.
- In a session, it is the establishment of a correspondence between two people.
- At the presentation level, the message is encrypted to prevent it from being accidentally read by third parties.
- In the applied version, there is the text of the letter itself, which is read by the recipient.
In textbooks, OSI helps show how the same action can be viewed at different levels of abstraction.
In OSI documentation, it is used for systematization: for example, to indicate that TLS belongs to the presentation layer, and DNS belongs to the application layer.
During debugging, the model becomes a step-by-step checklist. The engineer works from top to bottom or bottom to top to find the source of the error: from a missing signal in a cable to a failed HTTP request.
Diagnosing Network Problems Using the OSI Model
Every administrator has used OSI at least once to troubleshoot errors. Here’s how it works:
- L1 is the physical layer. They check the cable and signal. The network port on the switch may be disabled.
- L2 — data link layer. They check to see if the device’s MAC address is visible. If it’s not in the switch’s table, the connection has failed.
- L3 is the network layer. It checks the IP address and routing. A device might receive an incorrect IP address, preventing packets from reaching the router.
- L4 is the transport layer. TCP may fail to establish a connection due to a firewall blocking it. UDP may lose segments during a video call.
- L5 is the session layer. Sometimes an SMB session is terminated due to authorization issues.
- L6 — Presentation Layer. TLS certificate errors cause the browser to block the site.
- L7 — Application Layer. The server may return an HTTP 500 error, or DNS may not resolve the hostname.
The OSI model makes troubleshooting systematic: instead of chaotic actions, the engineer goes through the layers, eliminating possible causes.
Seven layers of the OSI model
Although in practice it’s not always possible to strictly divide a model into layers, in theory everything is quite straightforward. Liberties are allowed, which we’ll discuss later, but for now, it’s worth examining each network layer separately.
1. Physical layer (L1)
The physical layer is the foundation of all networks. It describes how bits are converted into electrical impulses, light signals, or radio waves.
Examples of technologies: Ethernet cables (twisted pair), fiber optics, Wi-Fi, Bluetooth, NFC, DSL.
L1 functions:
- Determination of signal voltage.
- Transfer speed (for example, 1 Gbps in Ethernet or 300 Mbps in Wi-Fi).
- Cable and connector type.
- Synchronization of clocks between devices.
An L1 error manifests itself simply: there’s no internet because the cable is damaged or the connector isn’t fully seated. Sometimes, replacing the cable is enough to restore the connection.
An interesting nuance: it is at the physical level that they decide whether the network can be overclocked beyond its stated specifications.
For example, Category 5e cable is officially rated for 1 Gbps (1000BASE-T), but over short distances it is sometimes used for 2.5GBASE-T or even 5GBASE-T speeds, although the standard no longer guarantees such operation.
2. Data Link Layer (L2)
The data link layer handles frames and ensures data delivery between two adjacent devices. This is where the concept of a MAC address—a unique identifier for a network adapter—comes into play.
Examples of technologies: Ethernet, Wi-Fi (802.11), Bluetooth, PPP, Frame Relay.
L2 functions:
- Encapsulation of packets into frames.
- Error checking (CRC).
- Media Access Control (CSMA/CD in Ethernet, CSMA/CA in Wi-Fi).
MAC (Media Access Control) sublayer
Determines which device is currently authorized to transmit a signal. Wi-Fi, for example, uses a backoff mechanism to reduce the likelihood of collisions.
LLC (Logical Link Control) sublayer
It facilitates interaction between upper-layer protocols and the physical network. It signs the frame so that the network layer understands that it contains an IP packet.
L2 errors are often related to misconfigured VLANs or duplicate MAC addresses.
3. Network layer (L3)
The network layer is responsible for routing packets between devices on different networks. IP addresses are used here.
L3 protocols: IPv4, IPv6, ICMP, OSPF, BGP.
When a user enters a website address, the network layer decides which routers the packets will travel through. For example, a packet from Moscow reaches a server in the US after passing through dozens of nodes.
L3 errors manifest as “server can’t be pinged.” If the router is configured incorrectly, packets are simply lost.
IPv6 solves the IPv4 address shortage and enables direct connection of billions of IoT devices.
4. Transport layer (L4)
The transport layer ensures that the data arrives in the correct sequence and without loss.
L4 Protocols:
- TCP (Transmission Control Protocol). Establishes a connection (three-way handshake), manages the flow, and recovers lost segments. TCP makes it possible to download websites, files, and email.
- UDP (User Datagram Protocol). Faster, but no guarantees. Used for calls, games, and video streaming. If a single packet is lost, the user will simply see an artifact in the image or a freeze for a split second.
L4 errors manifest as connection drops or delays. Administrators analyze them using tools like Wireshark.
5. Session layer (L5)
The session layer manages the connection between applications. It establishes the session, maintains it, and terminates it when the data is transferred.
Examples: SMB (file access), NetBIOS.
For example, a user opens a shared network drive. The session layer is responsible for maintaining the connection to the server even if the transport layer briefly loses a segment.
Errors here appear as “session interrupted” or “unable to connect to share”.
6. Presentation level (L6)
This layer is responsible for converting data formats.
L6 functions:
- Encryption (SSL).
- Compression (JPEG, MP3, ZIP).
- Conversion of encodings (UTF-8, ASCII).
Without L6, applications wouldn’t be able to agree on how to read information. For example, a browser receives data in JSON format and understands its structure.
L6 errors are often related to TLS certificates: the browser reports “connection is not secure.”
7. Application layer (L7)
The application layer is closest to the user. It’s where the protocols we encounter every day operate: HTTP, DNS, SMTP, FTP, and RPC.
Examples:
- HTTP — loading websites.
- DNS – converting domain names into IP addresses.
- SMTP — sending emails.
- FTP – file transfer.
L7 errors include “404 Not Found,” “502 Bad Gateway,” and DNS request failure. To the user, they appear as “the site won’t open.”
Correspondence between the OSI model and actual protocols or stacks
Although OSI is an abstraction, actual protocols can be mapped to layers:
- Ethernet → L2;
- IPv4/IPv6 → L3;
- TCP/UDP → L4;
- TLS → L6;
- HTTP, DNS, SMTP, FTP → L7.
Some protocols are difficult to categorize strictly into a single layer. For example, TLS operates at both L6 and L7.
Comparison of OSI and TCP/IP
The difference between the OSI model and the TCP/IP stack is like the difference between a blueprint of a building and a house that’s already been built and inhabited. The OSI model is a neat, detailed seven-layer diagram, while TCP/IP is the compact, practical stack upon which the Internet grew.
Below is a detailed comparison of important parameters and real-life examples.
Purpose and nature
OSI is a conceptual model and standard (ISO/IEC 7498). Its purpose is to provide abstraction: to divide data transmission into clear layers, each with its own function and interface. It is a teaching and design tool.
TCP/IP is a set of protocols developed for the practical needs of the ARPANET/Internet. It is the specific implementation upon which actual data transmission is based.
Number and grouping of levels
OSI: 7 layers (L1 – physical, L2 – data link, L3 – network, L4 – transport, L5 – session, L6 – presentation, L7 – application).
TCP/IP: 4 or 5 layers in various interpretations: link (network/channel), internet (IP), transport (TCP/UDP), application (HTTP, DNS). In practice, OSI L5–L7 in TCP/IP are combined into a single application layer.
History and speed of adoption
TCP/IP was implemented and used earlier, so it gained widespread adoption. OSI was born as a standard, formal model—many good ideas, but the slow standardization process and more complex implementation made it less viable for mass deployment.
Practicality versus idealism
TCP/IP is focused on “if it works, it’s right”: simple interfaces, easy implementation. OSI is focused on a clean architecture and strict decomposition of responsibilities. In practice, engineers appreciate the simplicity of TCP/IP, and educators appreciate the clarity of OSI.
In TCP/IP, as in OSI, data passes through layers of encapsulation and decapsulation, but layer boundaries are not always strictly observed. For example, a TCP segment is encapsulated within an IP packet, which in turn is encapsulated within an Ethernet frame.
Level matching
A handy comparison map for understanding:
OSI | TCP/IP |
| OSI L1 (Physical) | TCP/IP link (partially) |
| OSI L2 (Data Link) | TCP/IP link |
| OSI L3 (Network/IP) | TCP/IP Internet (IPv4/IPv6) |
| OSI L4 (Transport / TCP, UDP) | TCP/IP Transport (TCP/UDP) |
| OSI L5-L7 (Session/Presentation/Application) | TCP/IP Application (HTTP, DNS, SMTP) |
Practical difference in diagnosis
If you are diagnosing a problem with a website, on TCP/IP, you basically think of 4 layers (link → IP → TCP → HTTP).
OSI gives a more nuanced picture: you can consider L5 (if the connection to the server must support sessions), L6 (TLS certificate, encoding), and so on, separately.
In reality, a mixed approach is often used: a simplified TCP/IP model for quick searches and the OSI model for deep analysis.
Evolution and Layer Violators
A real network rarely maintains a perfect boundary between layers: MPLS places labels between Layer 2 and Layer 3. NAT changes addresses on Layer 3 and breaks the end-to-end concept. VPN encapsulates IP in IP/UDP/TCP.
New protocols are also breaking the mold: QUIC runs on top of UDP but implements functions traditionally found in TCP (network control, recovery). This is an example of how practical needs force a redefinition of boundaries.
OSI as a model remains useful for explanation, but its strict hierarchy can no longer always be applied literally.
Security and hosting of services
Where should encryption be placed—at the presentation layer (OSI L6) or as a service at the application/transport layer? In the real world, TLS is typically deployed over TCP (that is, between L4 and L7 in OSI terminology). So, architecturally, OSI offers a place for such services, but the TCP/IP reality makes them an application or add-on.
Approach to standards
OSI is a formal, bureaucratic standardization machine: detailed specifications, sets of interfaces, and services. TCP/IP is a practical RFC: simpler, faster, focused on implementation and interoperability. This explains why the industry chose TCP/IP: manufacturers and engineers value delivery speed and compatibility.
Why the OSI Model is Still Important for Teaching and Systems Thinking
Today, an engineer might work solely with the TCP/IP stack and never even open the ISO/IEC 7498 standard. But the OSI model helps build a picture in the mind: dividing the network into layers, understanding where the cable’s function ends, and the protocol begins.
This abstraction is not just a theory, but a thinking tool: when something breaks, the specialist mentally goes through the layers—from the physical signal to the application.
Moreover, the OSI model teaches a systems perspective. Modern IT has many specialized areas: some administer servers, others write application code, and still others manage routers. The OSI model shows how all of this is connected into a unified communications architecture.
For students and aspiring engineers, this is the best way to understand that the Internet is not magic, but a rigorous interaction of layers, where each protocol and each function has its place.
Summary of comparison
The comparison isn’t about the winner, but about the role: TCP/IP is the operating stack, OSI is the thinking model. It’s useful for an engineer to master both: TCP/IP provides a practical “what to do” map, and OSI provides the “why it works” methodology.
Criticism of the OSI model
The seven-layer OSI model became and remains the ISO/IEC 7498 standard, but that doesn’t mean it’s without its flaws. Let’s examine the community’s main complaints about it.
The model is too academic and abstract.
OSI is a great theory, but it’s far from the reality of networks. Rigid layer boundaries often don’t translate into practical solutions.
The TLS protocol is often referred to as the presentation layer, but in reality, TLS is deployed as a layer on top of TCP and managed as part of the application stack. As a result, it’s easier to think of it as an application or layer rather than pure Layer 6.
Beginning engineers who follow OSI head-on might expect strict modularity, where reality is flexible.
Redundancy of levels
The session (L5) and presentation (L6) layers are often not explicitly used in modern stack implementations. Their functions are implemented either in the application or in the transport and application layers.
Session management is often handled at the application level (JWT, HTTP cookies, WebSockets). Representation and encoding are also handled at the application level (JSON, Protobuf), rather than in a separate L6 standard.
These layers are left empty in the practical specifications, which creates the feeling that the model is redundant.
Complexity of implementation and slow standardization
OSI technologies (such as OSI network protocols like CLNP or X.400 messages) required extensive work and resource-intensive implementation. TCP/IP, on the other hand, was simpler to implement and deployed more quickly.
The industry chose what was already working and required less effort to implement.
Ambiguity of layer boundaries
In real life, real solutions often cross layer boundaries: MPLS, NAT, VPN, SDN.
However, OSI creates the illusion that this does not happen:
- MPLS inserts labels between the data link and network layers.
- NAT changes L3 IP addresses and damages the end-to-end principle inherent in the pure model.
- QUIC shows how new protocols implement transport functions on top of UDP, mixing responsibilities between layers.
The strict OSI rules do not account for engineering practices in which efficiency and scalability take precedence over architectural purity.
Failed or niche OSI protocols.
Many specifications developed within the OSI framework never gained widespread support. Meanwhile, TCP/IP had viable, tested implementations.
It turned out that a standard without successful implementations lost its meaning for many, and the industry chose working solutions.
The risk of misconceptions in learning
The model is useful for teaching, but taking it too literally can be misleading. Students may expect clean interfaces and independent layers, while real applications and protocols don’t work that way.
It is important to understand that OSI should be used as a mental model, but at the same time, a practical view should be instilled in TCP/IP and modern mixed architectures.
The model failed in the historical context.
Why the OSI stack has not become widely used:
- TCP/IP came earlier.
- The OSI stack was more difficult to implement.
- Equipment manufacturers have placed their bets on TCP/IP.
Since 1980, OSI has been accepted as the official standard, but TCP/IP has proven more convenient. The Internet grew on TCP/IP, and OSI has been relegated to the role of academic reference.
Although the OSI model has fallen into disuse in practice, it remains valuable and useful:
- Helps train engineers.
- Systematizes architecture.
- Facilitates diagnosis.
Conclusion
The OSI model is the foundation of networking theory. It explains how data travels from a signal in a cable to an application’s response on the screen.
Yes, the internet is built on TCP/IP, but the OSI model is still needed for learning, designing architecture, and troubleshooting. It’s a universal language that unites engineers, developers, and users in understanding how the network works.