Lesson 2: The OSI and TCP/IP Models

Why bother with layers?

In Level 1 a network was a set of devices that share a medium and agree on rules for passing messages. Loading one web page uses a lot of those rules at once. Something turns bits into electrical or radio signals. Something gets a message to the right machine on the local network. Something routes it across the internet, makes sure nothing goes missing, and in the end something has to understand "GET /index.html".

To keep this manageable, engineers split the work into layers. Each layer does one job and only talks to the layer directly above or below it. Think of a parcel service. The person writing the letter doesn't care whether it travels by van or plane, and the van driver doesn't read the letter. Each person does their own part and passes the parcel on.

There are two models you will hear about, and you need both.

The two models side by side

The OSI model is a seven-layer reference model from ISO. It was first published in 1984, and the current edition is ISO/IEC 7498-1:1994. The TCP/IP model describes how the internet's protocols are actually built. RFC 1122 sets it out as four layers.

OSI (7 layers)          TCP/IP (4 layers)     Real protocol examples
--------------------    -----------------     ----------------------
7 Application   \
6 Presentation   >----  Application           HTTP, DNS, SSH, TLS*
5 Session       /
4 Transport     -----   Transport             TCP, UDP
3 Network       -----   Internet              IP (IPv4/IPv6), ICMP (ping)
2 Data Link     \
1 Physical       >----  Link                  Ethernet, Wi-Fi

*TLS doesn't fit neatly into either model. People argue about where it belongs, and that argument tells you something: the models are maps, and the terrain doesn't always match them.

What production work teaches you: engineers talk in OSI numbers and build with TCP/IP. When someone says "it's a Layer 7 load balancer" (it understands HTTP) or "that's a Layer 2 problem" (local link), they're using OSI numbering. You'll rarely hear anyone talk about layers 5 and 6 on their own.

Encapsulation: wrapping the parcel

When your browser sends a request, each layer on the way down wraps the data from the layer above with its own header, a small block of control information for that layer's job:

Application:   [ HTTP request: GET / ... ]                    -> "data"
Transport:     [TCP hdr][ HTTP request ]                      -> "segment"
Internet:      [IP hdr][TCP hdr][ HTTP request ]              -> "packet"
Link:          [Eth hdr][IP hdr][TCP hdr][ HTTP ][Eth trailer] -> "frame"
Physical:      0101100111010... as voltage, light or radio    -> "bits"

• The TCP header holds things like port numbers, so the receiving machine knows which program the data is for. With no options it is 20 bytes.
• The IP header holds the source and destination IP addresses. An IPv4 header is at least 20 bytes.
• The link header holds the addresses for the next hop on the local network. Ethernet also adds a trailer used to check for errors.

The receiver does the reverse, which is called decapsulation. Each layer reads and removes its own header, then hands what's left up to the next layer. A router in the middle only unwraps as far as the IP header. It doesn't need to read your HTTP.

Gotcha: the names change by layer: segment (TCP), packet (IP), frame (link). Mixing them up in a ticket is harmless, but using the right word shows people you know which layer you're talking about.

Hands-on: test your own machine layer by layer

The real payoff is troubleshooting. Start at the bottom and work up. When one layer fails, the layers above it don't matter yet. Try these on your computer now.

Link layer: is the adapter connected at all?

# Windows (PowerShell): Status should say "Up"
Get-NetAdapter
# Name    InterfaceDescription        Status  LinkSpeed
# Wi-Fi   Intel(R) Wi-Fi 6 AX201      Up      866.7 Mbps

# Linux: look for "state UP"
ip link show
# macOS: en0 is usually Wi-Fi; look for "status: active"
ifconfig en0

Internet layer: do I have an IP address, and can I reach a remote IP?

ipconfig            # Windows: look for the IPv4 Address line
ip addr show        # Linux: look for an "inet" line
ipconfig getifaddr en0   # macOS: prints just the address

ping 8.8.8.8        # ICMP to a public IP, no names involved
# Reply from 8.8.8.8: bytes=32 time=14ms TTL=117

Application layer (DNS): can names be turned into addresses?

nslookup example.com
# Name:    example.com
# Address: <an IP address>

Application layer (HTTP): does the service answer?

curl -I https://example.com     # -I = fetch headers only
# HTTP/2 200

Windows gotcha: in Windows PowerShell 5.1, curl is an alias for Invoke-WebRequest, which takes different options. Type curl.exe to run the real curl that ships with Windows.

Sorting symptoms by layer

This is how you'll use the models every day:

The classic check: if pinging an IP works but pinging a name fails, stop looking at cables and look at DNS. One test like that rules out a whole set of layers.

Trade-off: layers overlap in real life, and some faults show up at more than one layer. Use the model to decide what to test next, and don't expect every fault to sit in exactly one box.

Key takeaways

• OSI has 7 layers (a reference model). TCP/IP has 4: Link, Internet, Transport, Application (how the internet is actually built).
• Example protocols: Ethernet/Wi-Fi (link), IP/ICMP (internet), TCP/UDP (transport), HTTP/DNS (application).
• Encapsulation: each layer adds its own header on the way down, and the receiver removes them on the way up.
• The units are named frame (link), packet (IP) and segment (TCP).
• Troubleshoot from the bottom up: link → IP → DNS → application.
• If you can ping an IP but not a name, the problem is DNS, not the cable.