ioob.dev
Go back

Networking Fundamentals Part 1 — OSI and TCP/IP Models

· 9 min read
Network Series (1/7)
  1. Networking Fundamentals Part 1 — OSI and TCP/IP Models
  2. Networking Fundamentals Part 2 — IP Addresses and Subnets
  3. Networking Fundamentals Part 3 — TCP and UDP
  4. Networking Fundamentals Part 4 — DNS
  5. Networking Fundamentals Part 5 — HTTP and HTTPS
  6. Networking Fundamentals Part 6 — TLS/SSL
  7. Networking Fundamentals Part 7 — Load Balancers and Proxies
Table of contents

Table of contents

A Packet Doesn’t Travel Alone

Type https://example.com into a browser and hit Enter — a web page appears on screen. What actually happens behind the scenes is far from simple. The domain must be resolved to an IP address, a route to the destination must be found, an encrypted connection must be established, data must be split into pieces, and lost segments must be retransmitted. If a single monolithic program had to handle all of this, nobody would ever be able to build network software.

Networking solved this problem with the idea of layers. Each layer only uses the services of the layer directly below it and provides services only to the layer directly above. The browser only worries about HTTP, HTTP only worries about TCP, and TCP only worries about IP. Without this division of labor, the internet as we know it couldn’t function.

In this post, we’ll place the two models that describe this division of labor — the OSI 7-layer model and the TCP/IP 4-layer model — side by side. The goal isn’t to memorize them like exam questions, but to develop an intuitive sense of the path a single packet takes from the moment it leaves a computer to the moment it reaches the application on the destination server.

Why Divide Into Layers?

The reason network designers introduced layers boils down to one thing: separation of concerns. It’s the same logic as splitting work into functions and modules in software engineering.

Without layers, building a single browser would require writing everything from Ethernet drivers to TLS encryption from scratch. Early networks were indeed built that way, and it was out of that chaos that the need for standards arose.

OSI 7 Layers — The Theoretical Textbook

The OSI (Open Systems Interconnection) model is a 7-layer architecture standardized by ISO in 1984. It was an attempt to bring order to a fragmented landscape where each vendor had its own proprietary networking specification. Few networks were ever implemented exactly to this model, but it has survived to this day as “the common language for talking about networks.”

flowchart TB
    L7["7. Application<br/>HTTP, FTP, SMTP, DNS"]
    L6["6. Presentation<br/>TLS, character encoding, compression"]
    L5["5. Session<br/>session setup/maintenance/teardown"]
    L4["4. Transport<br/>TCP, UDP"]
    L3["3. Network<br/>IP, ICMP, routing"]
    L2["2. Data Link<br/>Ethernet, MAC, switches"]
    L1["1. Physical<br/>electrical signals, optical signals, cables"]

    L7 --> L6 --> L5 --> L4 --> L3 --> L2 --> L1

Here’s a one-line summary of what each layer does.

In practice, the abbreviations L4 and L7 come up frequently. An L4 load balancer distributes traffic based on TCP/UDP ports, while an L7 load balancer examines application-level information like HTTP headers or URL paths. This distinction appears throughout network device and cloud infrastructure design.

TCP/IP 4 Layers — The Real-World Standard

If OSI is the textbook, the TCP/IP model is how the actual internet works. It originated from the US Department of Defense’s ARPANET project in the 1970s and was proven in practice before OSI even existed. A detailed history is well documented at Wikipedia: Internet protocol suite.

TCP/IP is condensed into 4 layers. The top three OSI layers (5, 6, 7) are merged into a single Application layer, and the bottom two layers (1, 2) are merged into a single Network Access layer.

flowchart LR
    subgraph OSI["OSI 7 Layers"]
        O7["Application"]
        O6["Presentation"]
        O5["Session"]
        O4["Transport"]
        O3["Network"]
        O2["Data Link"]
        O1["Physical"]
    end

    subgraph TCPIP["TCP/IP 4 Layers"]
        T4["Application"]
        T3["Transport"]
        T2["Internet"]
        T1["Network Access"]
    end

    O7 --> T4
    O6 --> T4
    O5 --> T4
    O4 --> T3
    O3 --> T2
    O2 --> T1
    O1 --> T1

Here’s each TCP/IP layer with its representative protocols.

Why do both models coexist? OSI is great for theory and education, while TCP/IP better reflects reality. Most documentation and exam questions use OSI 7-layer terminology, but what the actual Linux kernel implements is the TCP/IP 4-layer model. You need to know both to move fluidly between documentation and reality.

Following a Packet Down the Layers — Encapsulation

Let’s trace what happens when data is sent. Suppose a browser requests GET /index.html from a server. This request passes through each layer, getting a new header wrapped around it at each step. This is called encapsulation.

flowchart TB
    APP["Application<br/>HTTP: GET /index.html"]
    T["Transport<br/>+ TCP header<br/>(source/destination port, sequence number)"]
    N["Network<br/>+ IP header<br/>(source/destination IP)"]
    L["Link<br/>+ Ethernet header<br/>(source/destination MAC)"]
    P["Physical<br/>transmitted as bit stream"]

    APP --> T --> N --> L --> P

Let’s unpack each step.

  1. Application: The browser creates an HTTP message — text like GET /index.html HTTP/1.1
  2. Transport: When this message is written to a TCP socket, TCP splits it into segments and attaches a header. The header contains the source port (an ephemeral port used by the browser, e.g., 54321) and destination port (typically 443), along with the sequence number, checksum, and other information
  3. Network (IP): The TCP segment is wrapped in an IP packet. The IP header carries the source IP (my computer) and destination IP (the server). Routers look only at this IP address to determine the next hop
  4. Link (Ethernet): The IP packet is placed inside an Ethernet frame. The frame header carries the source MAC and destination MAC. Notably, the destination MAC here is not the MAC of the final destination server — it’s the MAC of the very next hop (usually the default gateway). This is a common point of confusion. Every time a router is crossed, the destination MAC changes. The IP stays the same end-to-end, but the MAC is swapped at each segment
  5. Physical: The frame is converted into electrical or optical signals and physically transmitted

On the receiving side, headers are stripped in exactly the reverse order (decapsulation). The Ethernet header is removed and the MAC address is verified, the IP header is removed and the destination IP is confirmed, the TCP header is removed and the process listening on that port is found, and finally the HTTP message is delivered to the application. Each layer only looks at its own header. This is the essence of layering.

Actual Flow Between Two Hosts

Looking only at the downward journey within a single host gives an oversimplified picture. In reality, multiple routers and switches sit between two hosts. Each intermediate device unpacks the packet only up to the layer it needs to do its job.

sequenceDiagram
    participant A as Client
    participant S as L2 Switch
    participant R1 as Router 1
    participant R2 as Router 2
    participant B as Server

    A->>S: Ethernet frame (destination MAC = R1)
    Note over S: Looks at L2 only. MAC-based forwarding
    S->>R1: Frame forwarded
    Note over R1: Looks up to L3. Determines route by IP<br/>Wraps in new Ethernet header for next hop
    R1->>R2: New frame (destination MAC = R2)
    Note over R2: Same process. Determines route by IP
    R2->>B: New frame (destination MAC = B)
    Note over B: Decapsulates L2→L3→L4→L7<br/>Delivers HTTP message to application

In practice, when you encounter terms like “L4 load balancer” or “L7 proxy,” they’re telling you which layer the device inspects up to. Having this intuition makes choosing cloud load balancers or designing Kubernetes Service/Ingress much easier.

Seeing the Layers on Linux

This abstract discussion can be verified with Linux commands. There’s a tool corresponding to each layer.

# L2 — Check MAC addresses and interfaces
ip link show

# L3 — IP addresses and routing table
ip addr show
ip route show

# L4 — Open ports and connection states
ss -tulnp

# L7 — See HTTP requests
curl -v https://example.com

Understanding which layer each command touches helps you decide which tool to reach for first when facing a network issue. You can systematically diagnose by checking L3 connectivity with ping, then verifying L4-L7 with curl or telnet.

# Example: To use the 5th floor, the 1st floor entrance must be open first
ping 93.184.216.34      # Is L3 alive?
nc -zv example.com 443  # Is the L4 port open?
curl -v https://example.com   # Does L7 return an HTTP response?

Following this order makes it immediately clear which layer is blocked. About half the time, the reason an upper layer fails lies in a lower layer.

Common Points of Confusion

Here are some easily confused points when first learning the layer model.

The Road Ahead in This Series

This post covered the backbone that supports networks — the layered architecture. Over the next three posts, we’ll dive deep into the core protocols at each layer.

As each post builds on the last, the entire journey from the moment you type a URL in the browser to the server’s response will connect in your mind.

In the next post, we’ll dissect the label called the IP address. We’ll examine why a single 32-bit number is written in four chunks, how private and public networks are distinguished, and what CIDR notation means.

→ Part 2: IP Addresses and Subnets

Related Posts

Share this post on:
Share this post via WhatsApp Share this post on Facebook Share this post on X Share this post via Telegram Share this post on Pinterest Share this post via email

Comments

Loading comments...

Previous Post
Linux Basics Part 8 — Bash Scripting Basics
Next Post
Networking Fundamentals Part 2 — IP Addresses and Subnets