Understand OSI and TCP/IP Models

Network problems are everywhere: a slow API, a dropped connection, a packet that never arrives. When something breaks, the worst position you can be in is staring at a tcpdump or curl error with no mental map of what's happening. The OSI and TCP/IP models give you that map — a shared vocabulary that lets you say "this is an application-layer issue, not a transport-layer issue" and know exactly where to look. By the end of this lesson, you'll not only understand these models but be able to use them as a practical diagnostic tool in your Linux and DevOps work.

The problem this lesson solves

Imagine you're the on-call engineer at 2 a.m. A service is unreachable. You run ping — it's fine. You run curl — it hangs. You check ss -tulpn — the port is listening. You're left guessing: is it DNS? A firewall? A TLS handshake problem? A bug in the app? Without a clear model of how network communication is layered, troubleshooting becomes random poking.

The OSI and TCP/IP models turn that chaos into a systematic search. Each layer has a specific job, a specific protocol, and a specific set of tools you can use to inspect it. When you know which layer you're on, you pick the right diagnostic command and the right place to look. This lesson gives you that knowledge, so the next time the network drops, you're a detective with a map, not a panicked pinger.

Core concept / mental model

Think of the network stack as a postal system. You write a letter (application data). You seal it in an envelope with the recipient's address (the transport layer adds port numbers). The post office routes it through a network of sorting centers (the network layer handles IP addresses and routing). Finally, the physical trucks and roads move the letter (the physical layer). Each step relies on the one below it, and none can work without the others.

The OSI model: the 7-layer reference

The OSI (Open Systems Interconnection) model is a conceptual framework with seven layers. Each layer has a distinct function and communicates with the layer above and below it:

1. Physical — raw bits on the wire (copper, fiber, radio).
2. Data Link — frames, MAC addresses, and local network switching (Ethernet, Wi-Fi).
3. Network — packets, IP addresses, and routing across networks (IP, ICMP).
4. Transport — segments, port numbers, and reliable/ordered delivery (TCP, UDP).
5. Session — establishes, manages, and terminates sessions (rarely used directly in TCP/IP).
6. Presentation — data formatting, encryption, and translation (often merged into the application layer).
7. Application — the user-facing protocols (HTTP, DNS, SSH).

The TCP/IP model: the 4-layer practical reality

The TCP/IP model is what the internet actually uses, and it simplifies the seven layers into four:

• Link (combines OSI 1 & 2)
• Internet (OSI 3)
• Transport (OSI 4)
• Application (combines OSI 5, 6, 7)

In practice, when you debug a network issue, you'll almost always map your commands to the TCP/IP layers: ping (Internet), tcpdump (Transport), curl (Application). The OSI model is the theory; TCP/IP is the reality. Understanding both gives you the full picture — the OSI model helps you reason about sessions and presentation, while TCP/IP shows you what's actually running under the hood.

How it works step by step

The layers work together through a process called encapsulation. When you send data, each layer adds its own header (and sometimes footer) to the payload. Here's the step-by-step journey for a simple HTTP request:

1. Application — Your browser creates an HTTP request: GET /index.html HTTP/1.1. This is pure application data.
2. Transport (TCP) — TCP takes that data, splits it into segments, and adds a header with source and destination port numbers (e.g., 12345 → 80). It also handles sequencing and acknowledgements for reliability.
3. Internet (IP) — The router wraps each TCP segment in an IP packet, adding source and destination IP addresses.
4. Link (Ethernet) — The network interface card adds a frame header with source and destination MAC addresses for the local network segment.
5. Physical — The frame is converted to electrical, optical, or radio signals and sent over the wire.

At the receiving end, the process reverses (de-encapsulation): each layer strips its header, and the data is handed up to the next layer until the application sees the original request.

How data travels: a real-life example

Let's trace a curl https://example.com command:

1. DNS resolution (Application) — curl asks a DNS server for the IP of example.com via UDP or TCP on port 53.
2. TCP handshake (Transport) — curl opens a TCP connection to port 443 (HTTPS) with a three-way handshake (SYN, SYN-ACK, ACK).
3. TLS negotiation (Presentation/Application) — the TLS handshake establishes encryption, often on top of TCP.
4. HTTP request (Application) — curl sends the HTTP GET request.
5. Response — the server sends the response back, and the layers de-encapsulate it in reverse.

Each step involves a different layer, and a failure at any step produces a distinct error message. Knowing which layer failed helps you choose the right tool.

Hands-on walkthrough

Let's put this into practice on a Linux machine. We'll use everyday tools to observe each layer in action.

1. Inspect the application layer with curl

First, make an HTTP request and see the headers. The -v flag shows the TLS handshake and request/response headers — all application-layer details.

curl -v https://example.com 2>&1 | head -n 20

Expected output (trimmed):

*   Trying 93.184.215.14:443...
* Connected to example.com (93.184.215.14) port 443
* TLS 1.3 handshake completed
> GET / HTTP/1.1
> Host: example.com
>
< HTTP/1.1 200 OK
...

Notice the IP and port — that's the transport and internet layer info surfacing in the output.

2. See the internet layer with ping

ping uses ICMP, which lives at the internet layer of TCP/IP (OSI network layer). It tests IP connectivity and latency:

ping -c 3 example.com

Expected output:

PING example.com (93.184.215.14): 56 data bytes
64 bytes from 93.184.215.14: icmp_seq=0 ttl=56 time=49.0 ms
...

If ping works but curl fails, the problem is likely at the transport or application layer, not the internet layer.

3. Capture packets with tcpdump (transport layer)

tcpdump captures packets at the link/internet/transport layers. Here's how to see the TCP handshake for a connection:

sudo tcpdump -i any -c 10 'tcp port 443 and host example.com'

Then in another terminal, run curl https://example.com. The tcpdump output will show the SYN, SYN-ACK, ACK sequence, and the TLS traffic.

4. Probe ports with nc (transport layer)

Use nc (netcat) to test whether a TCP port is open — a transport layer check:

nc -zv example.com 443

Expected output:

Connection to example.com port 443 [tcp/https] succeeded!

If this succeeds but curl fails, the issue is likely in the application layer (e.g., HTTP error or TLS problem).

Compare options / when to choose what

The OSI and TCP/IP models are not competing protocols — they are different levels of abstraction. Use them as follows:

For example, a TLS certificate error is a presentation layer problem in OSI terms, but in TCP/IP you'd simply say it's an application-layer issue. Both are correct; you just pick the granularity you need.

If you want even more detail, there's a hybrid model with five layers (combining the physical and data link layers) — often used in networking courses. But for your Linux work, stick with TCP/IP's four layers for simplicity and speed.

Troubleshooting & edge cases

Common issues and how the layer model helps diagnose them:

• ping fails, but the network works — ICMP is often blocked by firewalls. This is an internet-layer issue, but not necessarily a broken network. Use curl or nc to confirm.
• curl hangs forever — Check DNS (application layer) with dig or nslookup. If DNS works, check the TCP port with nc (transport layer). A hang usually means a firewall is silently dropping packets (not rejecting with RST).
• Connection refused — The server is reachable (internet layer), but no process is listening on that port (transport layer). Check with ss -tulpn.
• TLS errors in curl — This is a presentation/application layer issue. Check the certificate with openssl s_client -connect example.com:443.
• Unknown protocol — Not all protocols fit neatly into one layer. For instance, QUIC (used by HTTP/3) actually runs over UDP at the transport layer but also does its own congestion control and encryption. This blurs the lines — which is fine; the models are mindsets, not laws.

Pro tip: When you troubleshoot, go from the bottom up: link → internet → transport → application. Start with ip link and ping, then nc -zv, then curl -v. This systematically eliminates layers.

What you learned & what's next

You can now explain the core idea behind the OSI and TCP/IP models — layered encapsulation — and you've completed a practical exercise using curl, ping, nc, and tcpdump to inspect layers on a live network. You've seen how each layer has its own protocols, headers, and failure modes, and you know which tools to reach for at each level.

Next, you'll use this foundation to learn about IP addressing and subnetting — how IP packets are addressed and routed, and how the internet layer fits into the bigger picture. That lesson will dive deeper into ip addr, subnets, and CIDR notation, giving you the skills to design and debug real network architectures.

Keep practicing: trace the layers of any HTTP request you make, and you'll build the intuition that makes you a faster, more confident troubleshooter.