The OSI Model

The short answer

The Open Systems Interconnection (OSI) model describes computer networking as seven stacked layers. From bottom to top: Physical, Data Link, Network, Transport, Session, Presentation, Application.

Two practical realities are worth knowing straight away:

1. No real system implements all seven layers. The internet runs on TCP/IP, which has four layers. The OSI model was standardized in 1984 as a competing architecture, and it lost the protocol wars. What survived is the vocabulary.

2. The vocabulary is extraordinarily useful anyway. When an application fails in production, asking "is this a Layer 3 problem or a Layer 7 problem?" immediately tells you which diagnostic tool to reach for. That mental troubleshooting map is what the model is actually for, and it is worth far more than memorizing the textbook names.

The seven layers, and the four that run

TCP/IP collapses the academic seven layers into four working layers:

   OSI 7-LAYER MODEL           TCP/IP INTERNET MODEL
   ┌────────────────┐
   │ 7 Application  │ ┐
   ├────────────────┤ │
   │ 6 Presentation │ ├──▶  Application      HTTP, DNS, SSH, TLS
   ├────────────────┤ │
   │ 5 Session      │ ┘
   ├────────────────┤
   │ 4 Transport    │ ───▶  Transport        TCP, UDP
   ├────────────────┤
   │ 3 Network      │ ───▶  Internet         IP, ICMP
   ├────────────────┤
   │ 2 Data Link    │ ┐
   ├────────────────┤ ┴──▶  Link / Network   Ethernet, Wi-Fi, MAC
   │ 1 Physical     │
   └────────────────┘

Layers 5 and 6 are the giveaway. Try to find the process on your operating system that implements the Session layer. There is none. HTTP manages its own state using cookies and tokens.

TLS handles encryption, which textbooks label Presentation, but TLS runs on top of TCP and carries HTTP. It sits in a gap the OSI model has no clean category for. People argue whether TLS belongs in Layer 5, 6, or 7. That debate has no answer because the original model did not anticipate how modern web encryption would work.

What actually happens to your request: encapsulation

The most important mechanism to understand in networking is encapsulation.

Each layer wraps the data from the layer above it in a new header. Each header contains only the metadata required by its own level of the stack.

When your browser requests a web page, this exact sequence of headers goes across the wire:

┌──────────────┬───────────┬────────────┬─────────────┬────────────────┐
│   Ethernet   │    IP     │    TCP     │  TLS record │  HTTP request  │
│   14 bytes   │  20 bytes │  20 bytes  │   5 bytes   │  "GET /health" │
├──────────────┼───────────┼────────────┼─────────────┼────────────────┤
│ dst MAC      │ dst IP    │ dst port   │ version     │ method, path   │
│ src MAC      │ src IP    │ src port   │ length      │ headers        │
│ ethertype    │ TTL       │ seq, ack   │             │ body           │
├──────────────┼───────────┼────────────┼─────────────┼────────────────┤
│   Layer 2    │  Layer 3  │  Layer 4   │  no slot    │    Layer 7     │
└──────────────┴───────────┴────────────┴─────────────┴────────────────┘

Read that diagram from left to right to see what each layer knows:

• The Ethernet header (Layer 2) knows the MAC address of the very next physical router or switch on your local wire. It has no idea what the ultimate destination IP is.
• The IP header (Layer 3) knows the destination server IP across the internet, but has no concept of which program or application on that server should receive it.
• The TCP header (Layer 4) contains the port number (like port 443), which tells the operating system kernel which exact process owns the socket.
• The innermost payload (Layer 7) is the only part that knows you requested /health.

You can inspect this header stacking live in your terminal:

sudo tcpdump -i any -n 'port 443' -c 1 -v

# IP 192.168.1.15.54892 > 104.18.2.9.443: Flags [S], seq 1829301,
#    win 64240, options [mss 1460,sackOK,TS val 891 ecr 0], length 0
#    ^^^^^^^^^^^^^^^ Layer 3     ^^^^^ Layer 4

Notice that there is zero HTTP payload yet. That packet is the TCP SYN handshake starting, three round-trips before any HTTP text exists.

This strict layering explains why internet routers can route millions of packets per second without decrypting your traffic: they read the 20-byte IP header and forward the packet immediately.

Code in action: raw Layer 4 vs Layer 7

To understand why this abstraction matters in software, look at how code communicates at Layer 4 versus Layer 7.

At Layer 4 (Transport), your application opens a raw TCP socket. There are no URLs, no JSON objects, and no HTTP status codes. There is only a stream of raw bytes:

# Layer 4 (Transport): Raw TCP socket stream
import socket

sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
sock.connect(("example.com", 80))

# At Layer 4, you must manually construct the protocol framing
sock.sendall(b"GET / HTTP/1.1
Host: example.com
Connection: close

")

raw_response = sock.recv(4096)
print(raw_response[:50]) # b'HTTP/1.1 200 OK
Content-Type: text/html...'
sock.close()

At Layer 7 (Application), the networking library parses the protocol headers, handles redirects, validates TLS certificates, and gives you structured objects:

# Layer 7 (Application): Protocol-aware HTTP client
import requests

response = requests.get("https://example.com")
print(response.status_code) # 200
print(response.headers["content-type"]) # 'text/html; charset=UTF-8'

Layer 4 gives you an ordered pipe of bytes between two ports. Layer 7 assigns human meaning to those bytes.

Four layers before HTTP exists

A single web request touches almost the entire stack before a single byte of HTTP is transmitted.

When you type curl https://example.com, your computer executes this chain:

1. Find the IP address (DNS). Your machine asks a recursive resolver for the IP of example.com. That is DNS, an application protocol (Layer 7) typically running over UDP (Layer 4).
2. Find the local gateway (ARP). Your machine now has the destination IP, but needs to know which local hardware device to hand the frame to. It uses ARP (Address Resolution Protocol) to get the MAC address of your local Wi-Fi router. That is Layer 2 bridging a gap Layer 3 cannot resolve alone.
3. Establish connection (TCP 3-way handshake). SYN, SYN-ACK, ACK. One round-trip is spent agreeing that both sides are active and synchronized. That is Layer 4.
4. Negotiate encryption (TLS handshake). The client and server agree on a TLS version, negotiate cipher suites, and exchange cryptographic keys.

Only after those four steps complete does GET / HTTP/1.1 leave your machine.

You can measure this sequence directly with curl:

curl -w 'dns: %{time_namelookup}s | tcp: %{time_connect}s | tls: %{time_appconnect}s | total: %{time_total}s
'      -o /dev/null -s https://example.com

# dns: 0.021s | tcp: 0.048s | tls: 0.104s | total: 0.139s

That output is the stack measured in seconds. DNS at Layer 7, TCP handshake at Layer 4, TLS negotiation in between, and the HTTP response at the end. When an API feels sluggish, this single command pinpoints exactly which layer is slow.

Layer 4 vs Layer 7 load balancing

This is the most common place where the OSI model impacts cloud architecture and costs.

          LAYER 4 BALANCER (AWS NLB / IPVS)
Client ──▶ [ L4 Balancer ] ──▶ Backend Server
           Reads: [ Src IP:Port ] ──▶ [ Dst IP: 443 ]
           Payload: Encrypted TLS stream (invisible to L4)
           Decision: "Route TCP stream based on IP hash or round-robin"

          LAYER 7 BALANCER (AWS ALB / Nginx / Envoy)
Client ──▶ [ L7 Balancer ] ──┬──▶ /api/*    ──▶ API cluster
           Decrypts TLS,     └──▶ /images/* ──▶ Image servers
           reads HTTP path:
           "GET /api/checkout HTTP/1.1"

The differences are concrete:

• A Layer 4 load balancer only inspects the TCP/UDP packet headers. It sees IP addresses and ports, and routes the connection. It cannot inspect URLs, cookies, or HTTP headers because the payload is encrypted inside TLS. It is fast, handles millions of requests per second with minimal latency, and never needs your TLS certificates.
• A Layer 7 load balancer terminates the TLS connection, decrypts the request, and inspects the HTTP headers. It can route traffic based on the URL path (/api vs /static), perform cookie-based session affinity, and inject custom headers. However, it requires CPU power for decryption and must manage your SSL/TLS certificates.

If an engineering team asks for path-based routing while refusing to terminate TLS on the load balancer, they have asked for something network encapsulation makes physically impossible. Knowing the layer boundaries lets you spot that contradiction immediately.

Using the model to troubleshoot: the 2 AM incident

When a service goes down, the wrong approach is jumping straight into thousands of lines of application logs. The professional approach is walking up the OSI ladder bottom-up.

The incident scenario

It is 2:00 AM. Your pager rings with an alert: PaymentGatewayTimeout: Connection timed out to payment-service.internal:8080

Instead of guessing, run the thirty-second ladder:

Step 1 (Layer 3 - Network):
  $ ping payment-service.internal
  64 bytes from 10.0.4.12: icmp_seq=1 ttl=64 time=0.42 ms
  → PASS: The host is online, DNS resolved, and routing works.

Step 2 (Layer 4 - Transport):
  $ nc -vz payment-service.internal 8080
  nc: connect to payment-service.internal port 8080: Connection refused
  → REVEALED: Layer 4 reached the machine, but nothing is listening on port 8080!

In ten seconds, you isolated the problem: the payment service process died or crashed on the remote server. You never had to check routing tables, VPC peering, or DNS caches.

The symptom-to-probe playbook

Two diagnostic rules save hours during outages:

Refused is not the same as timed out. "Connection refused" means the packet reached the target machine, and the operating system actively rejected it because no process was listening on that port. Layers 1, 2, and 3 are working fine. "Connection timed out" means your packet was dropped into a black hole along the way, pointing to a security group, firewall rule, or dead network route.

DNS resolution proves almost nothing. Running dig or nslookup only proves that your DNS resolver has a cached record. It does not prove that the server at that IP is online, that the port is open, or that the application is healthy.

Where the model stops being true

Treating the OSI model as an absolute blueprint rather than a helpful map leads to pointless debates.

TLS has no official home. It is the most widely deployed security protocol on Earth, yet the OSI model has no designated slot for it. It sits between Layer 4 transport and Layer 7 applications.

QUIC and HTTP/3 break the hierarchy. QUIC runs reliable, ordered, multiplexed streams over UDP. This places traditional transport features inside what the OSI model classifies as an application packet. By strict academic OSI definitions, QUIC should not exist. Yet it powers over 30% of global internet traffic.

Modern infrastructure spans multiple layers. A Kubernetes Service routes at Layer 4, an Ingress controller routes at Layer 7, and a service mesh sidecar (like Envoy) inspects Layers 3 through 7 simultaneously.

None of this makes the OSI model useless. It makes it a vocabulary. When someone says "we have a Layer 4 firewall but need Layer 7 rate limiting," everyone in the room knows exactly what needs to be built.

Common questions

Do I need to memorize all seven layer names? For academic certification exams, yes. For software engineering and systems architecture, you only need to know Layers 2, 3, 4, and 7 fluently, and recognize that Layers 5 and 6 are absorbed into modern application runtimes.

What layer is a cloud firewall? It depends on what it inspects. An AWS Security Group filtering by port and IP address operates at Layer 4. An AWS WAF (Web Application Firewall) inspecting SQL injection strings in HTTP request bodies operates at Layer 7.

Why do we still teach OSI when TCP/IP is what actually runs? Because the vocabulary is universal. Saying "we need a Layer 7 proxy" is clearer and faster than saying "we need an application-aware reverse proxy that parses HTTP headers and paths."

What is the practical difference between a switch and a router? A network switch operates at Layer 2, moving frames between machines on the same local subnet using hardware MAC addresses. A router operates at Layer 3, forwarding packets between different networks across the world using IP addresses.

What to remember

Encapsulation is the core mechanic. Headers wrap headers. Each piece of network equipment reads only the header relevant to its layer and forwards the payload untouched.

The layer determines visibility. If an intermediary device does not terminate TLS, it cannot read URLs, cookies, or payloads. It can only see destination IPs and ports.

Bottom-up is the debugging law. Higher layers depend strictly on lower layers. If Layer 3 cannot route packets, debugging Layer 7 application code is a waste of time. Verify the connection before debugging the software.