A network model is a conceptual framework that breaks the complex job of sending data between computers into a stack of smaller, more manageable layers. Each layer handles one piece of the puzzle, from the physical signals traveling through a cable to the web page loading in your browser. The two models you will encounter everywhere are the OSI model, which has seven layers, and the TCP/IP model, which has four. They tackle the same fundamental problem but slice it differently, and understanding both gives you a much clearer picture of how modern networking actually works.
Why Networks Are Built in Layers
Sending a message from one computer to another involves a dizzying number of tasks. Electrical or optical signals need to travel across a wire or through the air. Those raw signals have to be organized into chunks of data. Those chunks need addresses so they reach the right machine. The data needs to arrive in order, without errors. And at the end of all that plumbing, an application like your email client or web browser needs to make sense of what arrived. Trying to design one giant piece of software to handle all of that at once would be unmanageable.
Layering solves this by dividing the work into a hierarchy of protocols, where each protocol handles a well-defined task and hands its output to the layer above or below it. Network software is typically organized into what researchers call a “protocol graph,” where each node in the graph encapsulates complex functionality while keeping the overall structure relatively simple and stable.1ACM Transactions on Computer Systems. A dynamic network architecture The practical benefit is modularity: you can swap out or upgrade the technology at one layer without tearing apart everything else. When the networking world moved from copper Ethernet cables to fiber optics, for instance, the protocols running on top of that physical change barely noticed.
The OSI Model and Its Seven Layers
The Open Systems Interconnection model, usually just called OSI, was developed in the late 1970s and early 1980s by the International Organization for Standardization (ISO). It was designed to be a universal reference for how any networked system should communicate. It divides communication into seven layers, each with a distinct responsibility.
- Physical (Layer 1): This is the raw hardware layer. It deals with electrical voltages, light pulses, radio frequencies, pin layouts on connectors, and cable specifications. It answers the question: how do we physically move bits from point A to point B?
- Data Link (Layer 2): Once bits are moving, this layer organizes them into frames and handles communication between devices on the same local network. It manages things like MAC addresses, error detection for corrupted frames, and who gets to transmit on a shared medium.
- Network (Layer 3): This layer introduces logical addressing and routing. It figures out the path data should take across interconnected networks. IP addresses live here, and routers operate at this layer.
- Transport (Layer 4): The transport layer ensures data arrives reliably and in the right order. It breaks large messages into segments, manages flow control so a fast sender does not overwhelm a slow receiver, and can retransmit anything that gets lost.
- Session (Layer 5): This layer manages the opening, maintaining, and closing of sessions between applications. Think of it as handling the start and end of a conversation.
- Presentation (Layer 6): Data can be encoded, compressed, or encrypted in different formats. The presentation layer translates between those formats so the application above gets data it can understand, regardless of how the system on the other end chose to represent it.
- Application (Layer 7): This is the layer closest to the user. It provides the protocols that software applications use to communicate over a network, such as the protocols behind web browsing and email.
If that seems like a lot, you are not alone. The seven-layer breakdown is thorough, but in practice, the Session and Presentation layers are often the hardest to pin down because relatively few standalone protocols map neatly to them. That is one reason the competing TCP/IP model takes a different approach.
The TCP/IP Model and Its Four Layers
The TCP/IP model predates the OSI model as a practical implementation. It grew out of research funded by the U.S. Department of Defense in the 1970s and became the protocol suite that the internet actually runs on. Rather than seven layers, it uses four.
- Network Access (Link): This bottom layer combines what OSI splits into Physical and Data Link. It covers everything from the cables and wireless signals to the framing and local addressing that gets data across a single network segment. Ethernet, Wi-Fi, and similar technologies operate here.
- Internet: Equivalent to OSI’s Network layer. The Internet Protocol (IP) lives here, giving every device a logical address and allowing routers to forward packets across networks. This is the layer that makes it possible for data to travel across the globe, hopping from router to router.
- Transport: Same general role as OSI’s Layer 4. The two main protocols here are TCP (Transmission Control Protocol), which provides reliable, ordered delivery, and UDP (User Datagram Protocol), which is faster but does not guarantee delivery. Streaming video and online gaming often prefer UDP because speed matters more than perfection.
- Application: This layer absorbs what OSI spreads across Session, Presentation, and Application. It is where the user-facing protocols live: HTTP for web pages, SMTP for outgoing email, FTP for file transfers, DNS for translating domain names into IP addresses, and many others.2GSC Advanced Research and Reviews. Performance, privacy, and security issues of TCP/IP at the application layer: A comprehensive survey
The TCP/IP model is leaner. It does not bother separating layers that, in real-world software, are almost always handled together. Session management, encryption, and data formatting tend to be rolled into the application itself or into libraries that the application calls, so giving them their own layers felt like unnecessary overhead to the engineers who built the internet.
Where OSI and TCP/IP Actually Differ
At first glance, the two models look like they are just counting layers differently. And that is partly true: the TCP/IP Application layer covers OSI layers 5 through 7, and the TCP/IP Network Access layer covers OSI layers 1 and 2. The Internet and Transport layers line up almost one-to-one with OSI’s Network and Transport layers. But the differences go deeper than a numbering scheme.
The OSI model was designed as a prescriptive specification. It was meant to define how protocols should be built, with each layer cleanly separated from the others by formal interfaces. Protocols were supposed to be written to fit the model. The TCP/IP model, by contrast, was descriptive. It emerged after the key protocols (IP, TCP, UDP) had already been built and deployed, and the four-layer model was essentially a retrospective way to organize what already existed. This difference in philosophy shaped the outcome: OSI produced an elegant theoretical structure, while TCP/IP produced the protocols that run the actual internet.
Detailed comparisons between the two architectures have looked at how their corresponding protocols stack up in areas like electronic mail, directory services, network management, and routing.3ACM Digital Library. Open Systems Networking: TCP/IP and OSI In most cases, both architectures defined protocols to solve the same problem, like comparing OSI’s X.400 messaging system with SMTP-based internet mail, or OSI’s X.500 directory service with the Domain Name System. The internet protocols won out in nearly every contest, largely because they were already widely deployed and battle-tested by the time the OSI equivalents were ready.
Which Model Actually Runs the Internet
TCP/IP won. That outcome was clear by the mid-1990s, and nothing has changed since. Every device connected to the internet uses the IP protocol to address packets and relies on TCP or UDP to transport data between applications. When you load a web page, your browser uses HTTP (an application-layer protocol), which hands data to TCP (transport), which passes it to IP (internet), which sends it through whatever physical medium connects you to your router. The OSI equivalents to these protocols were either never widely deployed or were abandoned.
So if TCP/IP won, why does anyone still talk about OSI? Because the seven-layer model turns out to be an exceptionally useful teaching and troubleshooting tool. Engineers and network technicians routinely use OSI layer numbers as shorthand. When someone says “that’s a Layer 2 problem,” they mean the issue is with local addressing or switching, not routing. “Layer 7 firewall” means a firewall that inspects traffic at the application level. These references are to the OSI model, even though the protocols flowing through those devices are TCP/IP.
The OSI model survived as the industry’s shared vocabulary even though its actual protocol suite did not survive as the industry’s technology. This is a useful distinction: the model is a mental map, and the protocols are the roads. TCP/IP provides the roads, and OSI provides the map that most people use to talk about them.
How the Layers Map to Everyday Networking
Abstract layer diagrams click into place more quickly once you trace a real action through the stack. Consider what happens when you send an email from a laptop connected to Wi-Fi.
Your email client composes the message and uses SMTP to format it for transmission. That is the application layer at work. SMTP hands the message to TCP, which breaks it into segments, numbers them so the receiving end can reassemble them in order, and manages acknowledgments so any lost segment gets resent. TCP passes each segment to IP, which wraps it in a packet with the source and destination IP addresses, then figures out where to send it next, usually to your home router. The router sends the packet out to your internet service provider, and from there it hops through several more routers until it reaches the recipient’s mail server. At each hop, the lower layers handle the physical transmission: converting the packet into Wi-Fi radio signals on your end, into optical pulses through a fiber backbone in the middle, and into electrical signals on a copper cable at the other end.
At the receiving mail server, the whole process runs in reverse. Physical signals become bits, bits become IP packets, packets become TCP segments, and segments are reassembled into the original SMTP message, which the server stores for the recipient to retrieve later using a protocol like POP3 or IMAP.2GSC Advanced Research and Reviews. Performance, privacy, and security issues of TCP/IP at the application layer: A comprehensive survey Every step in that chain corresponds to a specific layer, and none of the layers needs to understand how the others do their job. Your email client does not care whether you are on Wi-Fi or Ethernet, and the fiber-optic cable in the backbone does not know or care that it is carrying an email rather than a video stream.
Common Misconceptions About the Models
One widespread misunderstanding is that the OSI model describes how the internet works. It does not. The internet is a TCP/IP network. The OSI model is a reference framework that helps people think about networking in general, and its layer numbers happen to be the most popular way to talk about where in the stack a given technology or problem lives. Treating OSI as a literal description of internet architecture will lead you astray, especially at the upper layers, where the Session and Presentation layers have no clear standalone equivalent in modern internet protocols.
Another common confusion involves equating a “layer” with a specific piece of hardware or software. In reality, a single device can operate across multiple layers. A modern home router, for instance, works at Layer 1 (it has physical ports), Layer 2 (it switches traffic between local devices), and Layer 3 (it routes traffic between your home network and the internet). Similarly, a web browser operates at the application layer but relies on TCP/IP libraries built into the operating system to handle everything below that.
People also sometimes assume the layers form a rigid pipeline where data always passes sequentially through every single layer in order. In practice, certain optimizations shortcut this. Network hardware can peek at higher-layer information to make faster decisions, and software can combine the work of multiple layers into a single operation. The layered model is an abstraction that makes the system easier to reason about. The actual implementation is messier, and that is perfectly fine.
TCP vs. UDP and Why the Transport Layer Gets So Much Attention
If you spend any time reading about networking, the transport layer comes up disproportionately often. That is because the choice between TCP and UDP affects what users actually experience.
TCP is designed for reliability. It establishes a connection before any data flows, numbers every segment, waits for the receiver to acknowledge each batch, and retransmits anything that goes missing. This makes it ideal for tasks where completeness matters: loading a web page, downloading a file, sending an email. If a single packet carrying part of an image goes missing, TCP will fetch it again so the image renders correctly.
UDP takes a different philosophy. It fires off packets without establishing a connection first, without numbering them, and without waiting for acknowledgments. If a packet gets lost, UDP shrugs and moves on. That sounds careless, but for applications like live video calls, online gaming, or streaming music, a tiny gap is far less annoying than the stutter caused by TCP pausing to retransmit a lost packet. By the time TCP recovered the missing data, the moment would have passed.
This trade-off between reliability and speed is why newer protocols like QUIC, which underpins HTTP/3, are built on top of UDP rather than TCP. QUIC adds its own reliability and encryption mechanisms at the application layer, borrowing the best ideas from TCP while avoiding some of its performance bottlenecks. It is a good example of how the boundaries between layers can blur in practice, even when the conceptual model draws neat lines.
Why Networking Courses Still Teach Both Models
Given that TCP/IP dominates the real world, it might seem odd that every networking textbook and certification program spends considerable time on the OSI model. Researchers who have studied how students learn these concepts note that abstract models like OSI can be genuinely challenging, and that hands-on or collaborative teaching methods help students develop a deeper understanding of how the layers relate to each other.4arXiv. Do Students Learn Better Together? Teaching Design Patterns and the OSI Model with the Aronson Method
The OSI model persists in education partly because its seven-layer breakdown forces you to think about aspects of networking that the TCP/IP model glosses over. The TCP/IP Application layer lumps together session management, data formatting, and actual application logic. If you only learn the four-layer model, you might never pause to think about how encryption, character encoding, or session persistence work, because they are all hiding under one umbrella. OSI pulls those concerns apart and makes you examine each one, which builds a more thorough mental model of what is happening even if you will never deploy an OSI protocol in production.
There is also a practical reason tied to industry certifications. Exams from Cisco, CompTIA, and others use OSI layer numbers extensively. A candidate studying for these certifications needs to know the seven layers by heart, understand what protocols and devices map to each one, and be able to diagnose problems by identifying which layer is affected. Whether or not the OSI protocol suite succeeded commercially, the OSI reference model succeeded educationally, and it is not going anywhere soon.
Encapsulation and How Data Changes Shape at Each Layer
One concept that ties both models together is encapsulation. As data moves down through the layers on the sending side, each layer wraps the data it receives from the layer above with its own header information, and sometimes a trailer as well. The application layer produces a message. The transport layer wraps that message in a segment (TCP) or datagram (UDP) with port numbers and sequencing information. The internet layer wraps that segment in a packet with IP addresses. The network access layer wraps that packet in a frame with MAC addresses and error-checking data. Finally, the physical layer converts the whole thing into signals on a wire or through the air.
On the receiving side, the process reverses. Each layer strips off its corresponding header, reads the information it needs, and passes the remaining payload up to the next layer. By the time the data reaches the application layer, all the networking headers have been peeled away, and the receiving application sees the original message exactly as the sending application created it.
Encapsulation is what makes the independence of layers real rather than theoretical. Each layer only reads and writes its own headers. A router inspecting a packet at the internet layer does not need to understand the TCP segment inside, and a network switch operating at the data link layer does not need to parse IP addresses. This separation is the reason you can run the same application-layer protocol over Wi-Fi, Ethernet, cellular data, or a satellite link, and the application never knows the difference. The lower layers handle the translation, and the upper layers remain blissfully unaware of the physical reality underneath them.