Free lesson · Computer Networking
Why Do We Need Network Models
The Problem Before Models
Imagine you work at a company that builds laptops. Your laptops need to talk to servers built by a different company, over cables manufactured by a third company, using software written by a fourth. Every one of these companies makes their own decisions about how data should be formatted, how errors should be handled, and how connections should be established.
Without some shared agreement - some common blueprint that everyone follows - none of these pieces work together. Your laptop sends data in a format the server does not understand. The cable carries signals the laptop was not designed to produce. The software speaks a language the hardware has never heard.
This was the actual state of computer networking in the 1970s. Companies like IBM, DEC, and Honeywell each built their own networking systems. An IBM mainframe could talk to another IBM mainframe. A DEC machine could talk to another DEC machine. But an IBM machine talking to a DEC machine? That required expensive custom translation, if it worked at all.
The networking industry had a compatibility crisis, and the solution was a network model - a shared blueprint that divides the enormous problem of "how do two computers communicate" into smaller, manageable layers, where each layer has a clear job and a clear interface to the layers above and below it.
What Is a Network Model?
A network model is a conceptual framework that breaks network communication into a stack of layers. Each layer is responsible for one specific aspect of communication, and each layer only needs to know how to talk to the layer directly above it and the layer directly below it.
Think of it like sending a letter through the postal system. You do not need to understand how the postal truck's engine works in order to write a letter. You do not need to know the sorting rules at the distribution center. You write the letter, put it in an envelope with an address, and hand it to the postal system. The postal system handles everything else - sorting, routing, transporting, delivering - in a series of steps that you never see.
graph TD
A["You Write the Letter"] --> B["Put Letter in Envelope<br/>Write Address"]
B --> C["Drop at Post Office"]
C --> D["Sorting Center<br/>Routes by Zip Code"]
D --> E["Transportation<br/>Truck, Plane, or Train"]
E --> F["Local Post Office<br/>Sorts for Carrier"]
F --> G["Mail Carrier<br/>Delivers to Door"]
G --> H["Recipient Opens<br/>and Reads Letter"]
style A fill:#4f46e5,stroke:#4338ca,color:#fff
style H fill:#4f46e5,stroke:#4338ca,color:#fff
style D fill:#7c3aed,stroke:#6d28d9,color:#fff
style E fill:#7c3aed,stroke:#6d28d9,color:#fff
This diagram shows the postal system as a layered process. At the top, you write a letter. Then you put it in an envelope with an address. You drop it at the post office. It goes to a sorting center that routes by zip code. Transportation carries it via truck, plane, or train. The local post office sorts it for a carrier. The mail carrier delivers it to the door. The recipient opens and reads the letter. Each step handles one responsibility without knowing the details of the other steps.
Network models work the same way. Each layer handles one piece of the communication puzzle:
- One layer deals with the physical transmission of raw electrical or optical signals
- Another layer deals with making sure data arrives without errors
- Another layer deals with finding a path across the network from source to destination
- Another layer deals with making sure the right application on the right computer gets the right data
No single layer needs to understand how all the other layers work. It only needs to know how to pass data down to the layer below it (when sending) or up to the layer above it (when receiving). This separation is what makes modern networking possible - it is what allows your browser (application software) to work over Wi-Fi (wireless hardware) or Ethernet (wired hardware) without knowing or caring which one is being used.
Why Layers Matter - The Power of Abstraction
The layered approach solves three critical problems that would otherwise make networking impossibly complex.
Problem 1 - Complexity Management
Network communication involves dozens of interrelated tasks: converting data to electrical signals, detecting and correcting errors, finding routes across the internet, managing connections, encrypting data, formatting it for applications, and more. Trying to solve all of these in one monolithic system would produce code and hardware so intertwined that changing any single part would risk breaking everything else.
Layers break this into manageable pieces. The team that builds network cables does not need to understand HTTP. The team that builds web browsers does not need to understand voltage levels on copper wire. Each team works on their layer, follows the interface contract with adjacent layers, and the system works.
Problem 2 - Interchangeability
Because layers communicate through defined interfaces, you can swap out one layer's implementation without touching the others. This is not theoretical - it is something you experience every day.
When you move your laptop from a wired Ethernet connection to Wi-Fi, the physical layer changes completely. Different hardware, different signals, different transmission medium. But your web browser does not notice. Your email client keeps working. Your SSH session stays connected (assuming the network lets it). The application layer is completely insulated from the physical layer change because the layers in between handle the translation.
Example: Scenario: You are on a video call at your desk, connected via Ethernet cable. You unplug the cable and walk to a conference room, and your laptop switches to Wi-Fi.
What changed: The physical layer (copper wire → radio waves), the data link layer (Ethernet framing → Wi-Fi framing), and possibly the network layer (new IP address via DHCP).
What did NOT change: The transport layer (TCP connection may need to re-establish, but the protocol is the same), the application layer (your video call app uses the same API, same data format, same logic).
The insight: Layers make this seamless. Without them, the video call app would need separate code paths for Ethernet, Wi-Fi, cellular, and every other connection type.
Problem 3 - Standardization Across Vendors
The real power of network models is that they are shared standards. When the International Organization for Standardization (ISO) published the OSI model in 1984, it gave every hardware manufacturer, software developer, and network engineer a shared vocabulary and a shared architecture.
Before the model, asking "does your product work with ours?" required deep technical investigation. After the model, you could ask a more precise question: "Does your product implement Layer 3 using IP?" If yes, it works with every other Layer 3 IP implementation, regardless of who built it.
This is why your phone (built by Apple or Samsung) can access a website (hosted on an Amazon server) over a network (operated by your ISP) using cables (manufactured by Corning) - four companies, four different products, all working together because they all follow the same layered model.
The Two Models That Matter
There are two network models that every engineer should know. They serve different purposes and are used in different contexts.
The OSI Model (Open Systems Interconnection)
Published by the International Organization for Standardization (ISO) in 1984. Seven layers. Designed as a comprehensive theoretical framework for understanding network communication. The OSI model is the one most commonly referenced in textbooks, certifications, and interview discussions. It provides a precise vocabulary for talking about which part of the network stack you mean.
The TCP/IP Model (Internet Protocol Suite)
Developed by the US Department of Defense through the ARPANET project in the 1970s. Four layers (sometimes described as five). This is the model the actual internet is built on. While the OSI model was being designed by committee, TCP/IP was being deployed in production. It won not by being theoretically superior, but by being practically implemented.
graph LR
subgraph OSI["OSI Model (7 Layers)"]
direction TB
O7["Layer 7: Application"]
O6["Layer 6: Presentation"]
O5["Layer 5: Session"]
O4["Layer 4: Transport"]
O3["Layer 3: Network"]
O2["Layer 2: Data Link"]
O1["Layer 1: Physical"]
end
subgraph TCPIP["TCP/IP Model (4 Layers)"]
direction TB
T4["Application"]
T3["Transport"]
T2["Internet"]
T1["Network Access<br/>(Link)"]
end
O7 -.-> T4
O6 -.-> T4
O5 -.-> T4
O4 -.-> T3
O3 -.-> T2
O2 -.-> T1
O1 -.-> T1
style O7 fill:#4f46e5,stroke:#4338ca,color:#fff
style O6 fill:#6366f1,stroke:#4f46e5,color:#fff
style O5 fill:#818cf8,stroke:#6366f1,color:#fff
style O4 fill:#7c3aed,stroke:#6d28d9,color:#fff
style O3 fill:#8b5cf6,stroke:#7c3aed,color:#fff
style O2 fill:#a78bfa,stroke:#8b5cf6,color:#fff
style O1 fill:#c4b5fd,stroke:#a78bfa,color:#000
style T4 fill:#4f46e5,stroke:#4338ca,color:#fff
style T3 fill:#7c3aed,stroke:#6d28d9,color:#fff
style T2 fill:#8b5cf6,stroke:#7c3aed,color:#fff
style T1 fill:#a78bfa,stroke:#8b5cf6,color:#fff
This diagram shows the OSI model with seven layers on the left and the TCP/IP model with four layers on the right, with dotted lines showing how they map to each other. OSI Layers 7, 6, and 5 (Application, Presentation, Session) all map to the TCP/IP Application layer. OSI Layer 4 (Transport) maps to TCP/IP Transport. OSI Layer 3 (Network) maps to TCP/IP Internet. OSI Layers 2 and 1 (Data Link and Physical) map to TCP/IP Network Access or Link layer.
The next two topics in this module will walk through each model in detail. For now, the key takeaway is that these are two different ways of slicing the same reality. The OSI model slices it into seven thinner pieces for precise discussion. The TCP/IP model slices it into four thicker pieces that match how the internet actually works.
Tip: You do not need to choose one model over the other. In practice, engineers use OSI vocabulary (especially "Layer 4" and "Layer 7") while thinking in TCP/IP architecture. The two coexist, and this course will teach you both.
How Layers Communicate - The Vertical Contract
Each layer has a clear relationship with the layers directly above and below it. This relationship is governed by two concepts that work together to make the entire system flexible and maintainable.
Services: Each layer provides a service to the layer above it. The transport layer provides reliable data delivery as a service to the application layer. The network layer provides routing as a service to the transport layer. The lower layer does the work; the upper layer consumes the result without needing to understand how that work gets done.
For example, when your web browser wants to send an HTTP request, it hands the request data to the transport layer and says "deliver this reliably to the server." The browser does not know or care whether the transport layer uses retransmission, checksums, or acknowledgment packets to achieve reliability. It simply trusts that the service will be provided.
Interfaces: The boundary between two layers is called an interface. It defines exactly how the upper layer requests service from the lower layer and exactly how the lower layer delivers results back. As long as the interface stays the same, you can change everything inside a layer without affecting anything outside it.
This vertical contract - "I provide this service through this interface" - is what makes layers independently replaceable. The transport layer does not care whether the network layer is using IPv4 or IPv6, as long as the interface contract is honored. The application layer does not care whether the transport layer is using TCP or UDP, as long as the service contract (deliver my data to the other side) is fulfilled.
There is also an important distinction between vertical communication (between layers on the same machine) and horizontal communication (between the same layer on two different machines). When your browser's application layer sends data, it conceptually communicates with the server's application layer - HTTP request on one side, HTTP response on the other. But the actual data travels vertically down through your machine's layers, across the physical network, and vertically up through the server's layers. The horizontal conversation is logical; the vertical journey is physical. Understanding this distinction prevents a common source of confusion when you encounter terms like "peer-to-peer layer communication" later in the course.
Important: The concept of layers communicating through service interfaces is not unique to networking. It is the same principle behind APIs in software development. When you call a REST API, you do not care whether the server is running Python or Java. The interface (HTTP request/response) is the contract. Network layers work identically.
Where This Fits in System Design
If you are preparing for System Design interviews, you might wonder whether any of this theoretical layering matters. The answer is yes - but not in the way a textbook would emphasize.
You will never be asked to list the seven OSI layers in a System Design interview. But you will routinely make decisions that depend on understanding which layer does what:
-
"Should we use a Layer 4 or Layer 7 load balancer?" - This question only makes sense if you understand that Layer 4 operates on TCP connections (fast but blind to content) while Layer 7 operates on HTTP requests (slower but can route based on URL, headers, or cookies).
-
"How does the client discover the server's IP address?" - This is a Layer 7 (DNS) question that resolves to a Layer 3 (IP) answer.
-
"Should we use TCP or UDP for this?" - This is a Layer 4 decision that depends on whether reliability or latency matters more for your use case.
The layered model gives you the vocabulary to make these decisions precisely and to explain your reasoning to an interviewer.
Interview: In System Design interviews, you will rarely be asked to explain network models directly. But the vocabulary of layers shows up constantly. When an interviewer says "Layer 7 load balancer," they expect you to know that means HTTP-aware routing. When they ask about "transport-layer decisions," they mean TCP vs UDP. Understanding the model means understanding the language of the interview.
The pragmatic approach: Know what each layer does and which protocols operate at each layer. You do not need to recite the full OSI stack. You need to know that DNS is application-layer, TCP is transport-layer, IP is network-layer, and that load balancers can operate at Layer 4 or Layer 7. Those four facts will cover 90% of what you need.
What Comes Next
The next topic walks through all seven layers of the OSI model - one by one, with real-world analogies and concrete examples of protocols at each layer. After that, we cover the TCP/IP model and compare the two. By the end of this module, you will have the mental scaffolding to organize everything else in this course.
Exercise: Starter: Think about the apps you use daily (browser, email, messaging). For each one, list what you think happens between you clicking "send" and the recipient seeing your message. Do not worry about being technically correct - the goal is to surface your existing mental model so you can refine it as you learn.
Intermediate: Research one real-world example of layer interchangeability. For instance, how does a VPN change certain layers while leaving others untouched? Which layers does the VPN modify, and which ones remain the same?
Advanced: Consider a large-scale system like Google Search. When you type a query and press Enter, your request crosses multiple network layers, potentially multiple data centers, and multiple application services. Try to sketch out - even roughly - which layers are involved at each hop from your browser to Google's servers and back.