{"title":"OSI Model","description":null,"content":"Modern distributed systems rely on multiple layers of communication, from physical network transmission to high-level application protocols. Understanding how these layers interact is essential for designing scalable and reliable systems.\n\nThe **OSI (Open Systems Interconnection) Model** provides a conceptual framework that divides network communication into seven distinct layers. Each layer has a specific responsibility, from transmitting raw bits over a network to delivering structured data to applications.\n\nIn practice, most real-world systems use simplified models like **TCP/IP**, but the OSI model remains one of the best ways to understand how data moves through a network stack and where different technologies operate.\n\nIn this chapter, we will break down the **seven layers of the OSI model**, understand the role of each layer, and see how common protocols fit into this layered architecture.\n\n---\n\n# 1. Why Does the OSI Model Exist?\n\nIn the early days of networking, every vendor did things differently. IBM had its own networking architecture. So did Honeywell. So did DEC. If you bought hardware from one vendor, you were stuck with them. Their devices couldn't talk to anyone else's.\n\nIn 1984, the International Organization for Standardization (ISO) published the OSI model as a universal reference framework. The idea was straightforward: if everyone agrees on what each layer should do, different vendors can build products that actually work together.\n\nThe OSI model doesn't specify *how* to implement networking. It specifies *what responsibilities* each layer has. Think of it as a contract. Layer 3 promises to handle routing. Layer 4 promises to handle reliable delivery. As long as each layer keeps its promise, the whole system works, no matter who built the hardware or software.\n\n\n```mermaid\nflowchart TB\n subgraph OSI[\"The 7 Layers of the OSI Model\"]\n L7[\"Layer 7: Application
HTTP, DNS, FTP, SMTP\"]:::primary\n L6[\"Layer 6: Presentation
Encryption, Compression\"]:::orange\n L5[\"Layer 5: Session
Connection Management\"]:::orange\n L4[\"Layer 4: Transport
TCP, UDP\"]:::green\n L3[\"Layer 3: Network
IP, ICMP, Routing\"]:::teal\n L2[\"Layer 2: Data Link
Ethernet, MAC, Switches\"]:::primary\n L1[\"Layer 1: Physical
Cables, Signals, NICs\"]:::red\n end\n\n L7 --> L6 --> L5 --> L4 --> L3 --> L2 --> L1\n\n classDef primary fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n classDef teal fill:#38d9a9,stroke:#000,color:#000\n classDef red fill:#ff8787,stroke:#000,color:#000\n```\n\n\nA popular mnemonic to remember the layers from bottom to top: **P**lease **D**o **N**ot **T**hrow **S**ausage **P**izza **A**way (Physical, Data Link, Network, Transport, Session, Presentation, Application).\n\nLet's go through each layer, starting from the bottom.\n\n---\n\n# 2. The 7 Layers Explained\n\n## Layer 1: Physical\n\nThe Physical layer deals with raw bits traveling over a medium. Electrical signals on copper wire. Light pulses through fiber optic cables. Radio waves for WiFi. This layer has no idea what the bits mean. It just moves them from point A to point B.\n\nIt's responsible for transmitting binary data (0s and 1s), defining connector types and cable specs, and keeping sender and receiver in sync at the bit level.\n\nThe devices here are hubs, repeaters, cables, and Network Interface Cards (NICs). When you plug in an Ethernet cable and see the link light turn on, that's Layer 1 telling you a physical connection exists.\n\n\n```mermaid\nflowchart LR\n PC1[\"Computer A\"]:::primary\n NIC1[\"NIC\"]:::orange\n MEDIUM[\"Ethernet Cable /
Fiber Optic /
WiFi Signal\"]:::green\n NIC2[\"NIC\"]:::orange\n PC2[\"Computer B\"]:::primary\n\n PC1 --> NIC1 --> MEDIUM --> NIC2 --> PC2\n\n classDef primary fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n```\n\n\n\n| Medium | Speed | Max Distance | Typical Use |\n|--------|-------|-------------|-------------|\n| Cat5e Ethernet | 1 Gbps | 100m | Office networks |\n| Cat6a Ethernet | 10 Gbps | 100m | Data centers |\n| Single-mode Fiber | 100 Gbps | 40+ km | Long-distance links |\n| WiFi 6 (802.11ax) | 9.6 Gbps | ~50m | Wireless networks |\n\n\nIf the Physical layer isn't working, nothing else matters. No amount of software configuration fixes a broken cable.\n\n---\n\n## Layer 2: Data Link\n\nThe Physical layer can move bits, but it has no concept of structure or addressing. The Data Link layer fixes that by organizing bits into **frames** and introducing **MAC addresses**, unique hardware identifiers burned into every network interface.\n\nA MAC address looks like `00:1A:2B:3C:4D:5E`. It's 48 bits long and uniquely identifies a device on a local network.\n\nIts job is to package bits into frames, use MAC addresses to identify local devices, detect transmission errors using checksums (the Frame Check Sequence at the end of each frame), and control which device gets to use the shared medium at any given time.\n\n\n```mermaid\nflowchart LR\n PRE[\"Preamble
8 bytes\"]:::orange\n DST[\"Dest MAC
6 bytes\"]:::primary\n SRC[\"Source MAC
6 bytes\"]:::primary\n TYPE[\"Type
2 bytes\"]:::green\n PAYLOAD[\"Payload
46-1500 bytes\"]:::teal\n FCS[\"FCS
4 bytes\"]:::red\n\n PRE --> DST --> SRC --> TYPE --> PAYLOAD --> FCS\n\n classDef primary fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n classDef teal fill:#38d9a9,stroke:#000,color:#000\n classDef red fill:#ff8787,stroke:#000,color:#000\n```\n\n\nThe key device at this layer is the switch. A switch reads the destination MAC address in each frame, looks it up in its MAC address table, and forwards the frame only to the correct port. Compare that to a hub (Layer 1), which blindly broadcasts every signal to every port.\n\nThe Data Link layer is split into two sublayers:\n\n\n| Sublayer | Function |\n|----------|----------|\n| LLC (Logical Link Control) | Flow control, error checking |\n| MAC (Media Access Control) | Addressing, medium access |\n\n\nBut Layer 2 only works within a single network. To reach a device on a different network, you need Layer 3.\n\n---\n\n## Layer 3: Network\n\nThe Network layer is what lets your laptop in New York talk to a server in Tokyo. It handles routing: figuring out a path across multiple networks to reach the destination.\n\nIt assigns logical addresses (IP addresses), routes packets between networks, breaks up packets that are too large for a link (fragmentation), and figures out the best path to the destination.\n\nRouters live at Layer 3. They read the destination IP address in each packet and forward it toward its destination, one hop at a time.\n\n\n```mermaid\nflowchart LR\n subgraph NetA[\"Network A: 192.168.1.0/24\"]\n PC[\"Your Laptop
192.168.1.10\"]:::primary\n end\n\n R[\"Router
Routing Table\"]:::orange\n\n subgraph NetB[\"Network B: 10.0.0.0/24\"]\n SRV[\"Web Server
10.0.0.5\"]:::primary\n end\n\n PC -->|\"Packet to 10.0.0.5\"| R\n R -->|\"Forward to correct network\"| SRV\n\n classDef primary fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n```\n\n\nWorth noting the difference between MAC and IP addresses. MAC addresses are permanent, burned into hardware. IP addresses are logical and can change. You need both: MAC addresses handle local delivery within a network (Layer 2), while IP addresses handle routing across networks (Layer 3).\n\n\n| Protocol | Purpose |\n|----------|---------|\n| IP (IPv4/IPv6) | Addressing and routing |\n| ICMP | Error reporting, diagnostics (ping) |\n| ARP | Mapping IP addresses to MAC addresses |\n| OSPF, BGP | Routing protocols for finding best paths |\n\n\nBut Layer 3 only gets packets to the right machine. It doesn't know which application on that machine should receive the data.\n\n---\n\n## Layer 4: Transport\n\nThat's where the Transport layer comes in. It adds **ports**, numbers that identify which application should handle incoming data. A web server listens on port 443 (HTTPS). An SSH server listens on port 22. The combination of IP address + port is what we call a socket.\n\nBeyond addressing, it handles breaking large chunks of data into smaller segments, managing flow control so a fast sender doesn't overwhelm a slow receiver, and giving you a choice between reliability (TCP) or speed (UDP).\n\nTCP and UDP are the two protocols you'll see here, and choosing between them is one of the most common design decisions in system design.\n\n\n| Feature | TCP | UDP |\n|---------|-----|-----|\n| Connection | 3-way handshake required | Connectionless |\n| Reliability | Guaranteed delivery, retransmission | Best effort, no guarantees |\n| Ordering | Packets arrive in order | Order not guaranteed |\n| Overhead | Higher (headers, acknowledgments) | Minimal |\n| Use Cases | HTTP, email, file transfer | DNS lookups, video streaming, gaming |\n\n\nBefore any data flows, TCP establishes a connection using a three-way handshake:\n\n\n```mermaid\nsequenceDiagram\n participant C as Client\n participant S as Server\n\n C->>S: SYN (seq=x)\n S->>C: SYN-ACK (seq=y, ack=x+1)\n C->>S: ACK (seq=x+1, ack=y+1)\n Note over C,S: Connection Established\n```\n\n\nPort numbers are divided into ranges:\n\n\n| Range | Type | Examples |\n|-------|------|----------|\n| 0-1023 | Well-known | HTTP (80), HTTPS (443), SSH (22) |\n| 1024-49151 | Registered | MySQL (3306), PostgreSQL (5432) |\n| 49152-65535 | Dynamic/Ephemeral | Assigned to client-side connections |\n\n\n---\n\n## Layer 5: Session\n\nThe Session layer manages the lifecycle of connections between applications: setting them up, keeping them alive, and tearing them down.\n\nIn practice, most modern protocols fold this into the Application layer. But the concept still matters. When you download a large file and the connection drops, session management decides whether you restart from scratch or resume from where you left off. When you're on a video call and your WiFi hiccups for a second, the session layer is what keeps things going.\n\n\n```mermaid\nflowchart LR\n E[\"Establish
Session\"]:::green\n M[\"Maintain
Session\"]:::primary\n CP[\"Checkpoint /
Sync\"]:::orange\n T[\"Terminate
Session\"]:::red\n\n E --> M\n M --> CP\n CP -->|\"Resume if
interrupted\"| M\n M --> T\n\n classDef primary fill:#00ceff,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef red fill:#ff8787,stroke:#000,color:#000\n```\n\n\n\n| Protocol | Session Function |\n|----------|------------------|\n| NetBIOS | Name resolution and session management |\n| RPC | Remote procedure call sessions |\n| SIP | VoIP session setup and teardown |\n\n\n---\n\n## Layer 6: Presentation\n\nThe Presentation layer is the translator. It converts data between the format applications use and the format the network needs.\n\nThree things happen here. Encryption (TLS/SSL encrypts data before it hits the wire). Compression (gzip or Brotli shrink the data to save bandwidth). And encoding (converting between character sets like ASCII and UTF-8, or data formats like JPEG and JSON).\n\nLike the Session layer, Presentation is usually folded into the Application layer in real implementations. When your browser establishes an HTTPS connection, it's doing Layer 6 encryption as part of a Layer 7 protocol.\n\n\n```mermaid\nflowchart LR\n subgraph Input[\"Application Data\"]\n A1[\"Plain Text /
JSON / Image\"]:::primary\n end\n\n subgraph Presentation[\"Presentation Layer\"]\n P1[\"Encrypt
TLS/SSL\"]:::orange\n P2[\"Compress
gzip / Brotli\"]:::orange\n P3[\"Encode
UTF-8 / Base64\"]:::orange\n end\n\n subgraph Output[\"Network-Ready Data\"]\n N1[\"Formatted
Byte Stream\"]:::green\n end\n\n A1 --> P1 --> P2 --> P3 --> N1\n\n classDef primary fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n```\n\n\n\n| Function | Examples |\n|----------|----------|\n| Encryption | TLS/SSL, AES |\n| Compression | gzip, Brotli, deflate |\n| Encoding | ASCII, UTF-8, Base64 |\n| Data Formats | JPEG, PNG, MPEG, JSON |\n\n\n---\n\n## Layer 7: Application\n\nThis is the layer you interact with most directly. Every time your browser sends an HTTP request, every time you send an email, every time your code makes a DNS query, that's Layer 7 at work.\n\nIt's where all the high-level protocols live: HTTP, FTP, SMTP, DNS, SSH. It's also where application-level concerns like authentication happen.\n\n\n```mermaid\nflowchart LR\n subgraph Application[\"Application Layer Protocols\"]\n HTTP[\"HTTP/HTTPS
Web\"]:::primary\n DNS[\"DNS
Name Resolution\"]:::teal\n SMTP[\"SMTP / IMAP
Email\"]:::green\n FTP[\"FTP / SFTP
File Transfer\"]:::orange\n SSH[\"SSH
Remote Access\"]:::primary\n DHCP[\"DHCP
IP Assignment\"]:::orange\n end\n\n classDef primary fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n classDef teal fill:#38d9a9,stroke:#000,color:#000\n```\n\n\n\n| Protocol | Port | Purpose |\n|----------|------|---------|\n| HTTP | 80 | Web pages (unencrypted) |\n| HTTPS | 443 | Secure web pages |\n| FTP | 21 | File transfer |\n| SSH | 22 | Secure remote access |\n| SMTP | 25 | Sending email |\n| DNS | 53 | Domain name resolution |\n| DHCP | 67/68 | Dynamic IP assignment |\n\n\n---\n\n# 3. How Data Flows: Encapsulation and Decapsulation\n\nWhen you send data over a network, it doesn't teleport from your application to the wire. It passes down through each layer, and each layer wraps the data with its own header. This wrapping process is called **encapsulation**.\n\nThink of it like mailing a letter. You write the letter (your application data). You put it in an envelope and write the address (the Network layer adds an IP header). The postal service puts it in a mail bag with a barcode (the Data Link layer adds a frame header). The truck carries the bag physically (the Physical layer).\n\nStep by step:\n\n1. The **Application layer** generates the data, say an HTTP request\n2. The **Transport layer** wraps it with a TCP or UDP header (source port, destination port, sequence numbers), creating a **segment**\n3. The **Network layer** wraps that with an IP header (source IP, destination IP), creating a **packet**\n4. The **Data Link layer** wraps that with an Ethernet header and trailer (source MAC, destination MAC, checksum), creating a **frame**\n5. The **Physical layer** converts the frame into raw **bits** and sends them over the wire\n\n\n```mermaid\nflowchart TB\n subgraph L7[\"Layer 7: Application\"]\n D7[\"Data\"]:::primary\n end\n\n subgraph L4[\"Layer 4: Transport\"]\n\t\tdirection TB\n H4[\"TCP/UDP
Header\"]:::green\n D4[\"Data\"]:::primary\n end\n\n subgraph L3[\"Layer 3: Network\"]\n\t\tdirection TB\n H3[\"IP Header\"]:::orange\n H3a[\"TCP/UDP
Header\"]:::green\n D3[\"Data\"]:::primary\n end\n\n subgraph L2[\"Layer 2: Data Link\"]\n\t\tdirection TB\n H2[\"Ethernet
Header\"]:::teal\n H2a[\"IP Header\"]:::orange\n H2b[\"TCP/UDP
Header\"]:::green\n D2[\"Data\"]:::primary\n T2[\"FCS\"]:::red\n end\n\n D7 -->|\"Add TCP/UDP Header → Segment\"| L4\n L4 -->|\"Add IP Header → Packet\"| L3\n L3 -->|\"Add Ethernet Header + Trailer → Frame\"| L2\n L2 -->|\"Convert to bits → Physical transmission\"| BITS[\"⚡ Bits on the wire\"]:::red\n\n classDef primary fill:#00ceff,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef teal fill:#38d9a9,stroke:#000,color:#000\n classDef red fill:#ff8787,stroke:#000,color:#000\n```\n\n\nOn the receiving end, the reverse happens. This is **decapsulation**. Each layer strips off its header, reads what it needs, and passes the payload up. By the time data reaches Layer 7, all the networking headers are gone and the application gets clean data.\n\nEach layer gives its own name to the data unit it works with:\n\n\n| Layer | Data Unit Name |\n|-------|----------------|\n| Application (Layer 7) | Data |\n| Transport (Layer 4) | Segment (TCP) / Datagram (UDP) |\n| Network (Layer 3) | Packet |\n| Data Link (Layer 2) | Frame |\n| Physical (Layer 1) | Bits |\n\n\n---\n\n# 4. OSI vs TCP/IP Model\n\nWhile the OSI model is a powerful theoretical tool, the **TCP/IP model** is the one that's actually implemented and used by the Internet. It's a more pragmatic, consolidated model, and has only four layers.\n\n\n```mermaid\nflowchart LR\n subgraph OSI[\"OSI Model\"]\n direction TB\n O7[\"Application\"]:::primary\n O6[\"Presentation\"]:::orange\n O5[\"Session\"]:::orange\n O4[\"Transport\"]:::green\n O3[\"Network\"]:::teal\n O2[\"Data Link\"]:::primary\n O1[\"Physical\"]:::red\n\n O7 --- O6 --- O5 --- O4 --- O3 --- O2 --- O1\n end\n\n subgraph TCPIP[\"TCP/IP Model\"]\n direction TB\n T4[\"Application\"]:::primary\n T3[\"Transport\"]:::green\n T2[\"Internet\"]:::teal\n T1[\"Network Access\"]:::red\n\n T4 --- T3 --- T2 --- T1\n end\n\n O7 -.-> T4\n O6 -.-> T4\n O5 -.-> T4\n O4 -.-> T3\n O3 -.-> T2\n O2 -.-> T1\n O1 -.-> T1\n\n classDef primary fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n classDef teal fill:#38d9a9,stroke:#000,color:#000\n classDef red fill:#ff8787,stroke:#000,color:#000\n```\n\n\n\n| OSI Layers | TCP/IP Layer | Protocols |\n|------------|--------------|-----------|\n| Application + Presentation + Session | Application | HTTP, FTP, DNS, SSH, TLS |\n| Transport | Transport | TCP, UDP |\n| Network | Internet | IP, ICMP, ARP |\n| Data Link + Physical | Network Access | Ethernet, WiFi, PPP |\n\n\nSo why bother learning the OSI model at all?\n\nBecause it's a better mental model for reasoning about problems. With 7 layers, you can pinpoint where an issue lives. When someone says \"this is a Layer 4 issue,\" everyone knows they mean transport, ports, TCP/UDP. The TCP/IP model's \"Application\" layer lumps too many things together to be useful for that kind of precision.","pageType":"system-design"}

OSI Model

Ashish Pratap Singh

Get Premium