Skip to content

Networking

The OSI and TCP/IP Models

Networking is built in layers. The OSI and TCP/IP models are mental maps that split the job of moving data into manageable layers, so you can reason about, build, and troubleshoot networks one piece at a time.

Applies to

These models are OS-agnostic — they describe how networking works everywhere: Linux, Windows, macOS, and physical network gear. We point out where common tools and devices (a switch, a router, ping, curl) sit in the stack.

Why layered models exist

Moving data from one app to another across the world is a huge problem. Layering breaks it into independent jobs, each with a clear responsibility:

  • Separation of concerns — Wi-Fi (the physical layer) can change without rewriting your web browser.
  • Interoperability — gear from different vendors works together if each obeys the layer standards.
  • Easier troubleshooting — you can isolate a fault to one layer instead of guessing.

Each layer talks to the same layer on the other machine, while relying on the layer below it to actually carry the data.

The OSI 7-layer model

The OSI (Open Systems Interconnection) model is a 7-layer reference model. Layer 1 is closest to the wire; Layer 7 is closest to the user.

# Layer Purpose Examples / PDU
7 Application Interface to user-facing network services HTTP, HTTPS, DNS, SMTP, SSH — PDU: data
6 Presentation Data format, encryption, compression TLS/SSL, character encoding, JPEG — PDU: data
5 Session Sets up, manages, and tears down sessions Session establishment, dialog control — PDU: data
4 Transport End-to-end delivery, ports, reliability TCP, UDP — PDU: segment (TCP) / datagram (UDP)
3 Network Logical addressing and routing between networks IP, ICMP, routers — PDU: packet
2 Data Link Local delivery on one link via hardware addresses Ethernet, MAC, switches, ARP — PDU: frame
1 Physical The actual signals: cables, radio, voltages Copper, fiber, Wi-Fi radio, pins — PDU: bits

PDU = Protocol Data Unit

The name for the chunk of data at each layer: bits → frames → packets → segments → data. Knowing the PDU name tells you which layer someone is discussing.

A mnemonic

Remember the order (Layer 7 down to Layer 1):

  7 Application    All
  6 Presentation   People
  5 Session        Seem
  4 Transport      To
  3 Network        Need
  2 Data Link      Data
  1 Physical       Processing

"All People Seem To Need Data Processing" — top to bottom.

The TCP/IP 4-layer model

The OSI model is a teaching reference; the TCP/IP model is what the internet actually runs on. It collapses OSI's seven layers into four practical ones.

TCP/IP layer Maps to OSI layers Examples
Application 7 Application + 6 Presentation + 5 Session HTTP, DNS, SSH, TLS
Transport 4 Transport TCP, UDP
Internet 3 Network IP, ICMP
Link (Network Access) 2 Data Link + 1 Physical Ethernet, Wi-Fi, MAC
   OSI (7)                       TCP/IP (4)
  +----------------+
  | 7 Application  |  \
  | 6 Presentation |   >----->  | Application |
  | 5 Session      |  /
  +----------------+
  | 4 Transport    |  ------->  | Transport   |
  +----------------+
  | 3 Network      |  ------->  | Internet    |
  +----------------+
  | 2 Data Link    |  \
  | 1 Physical     |   >----->  | Link        |
  +----------------+  /

Tip

In day-to-day work, people still say "Layer 2," "Layer 3," "Layer 4," "Layer 7" using the OSI numbers even when working with TCP/IP — because OSI gives everyone a shared vocabulary.

Where common things live

Thing Layer Why
Switch L2 (Data Link) Forwards frames using MAC addresses
Router L3 (Network) Routes packets using IP addresses
Firewall L3–L4 (often L7 too) Filters by IP/port; app firewalls inspect L7
TCP / UDP L4 (Transport) Ports and end-to-end delivery
IP / ICMP L3 (Network) Logical addressing; ping uses ICMP
HTTP / DNS / SSH L7 (Application) User- and app-facing protocols
Cable / Wi-Fi radio L1 (Physical) The signal itself

This is why we say a switch is a "Layer 2 device" and a router is a "Layer 3 device." More on those in switching and VLANs and routing and NAT. Ports and TCP vs UDP are covered in TCP, UDP, and ports.

Encapsulation and decapsulation

As data travels down the stack on the sending machine, each layer wraps it in its own header (and the Data Link layer adds a trailer). This is encapsulation — each layer treats everything above it as opaque payload.

  SENDER (down the stack = encapsulation)

  L7  Application:        [ DATA ]
  L4  Transport:    [ TCP | DATA ]                 -> segment
  L3  Network:  [ IP | TCP | DATA ]                -> packet
  L2  Data Link:[ ETH |IP|TCP|DATA| FCS ]          -> frame
  L1  Physical:  101000110101...                   -> bits on the wire

On the receiving machine the reverse happens: each layer strips its own header and hands the payload up. This is decapsulation.

  RECEIVER (up the stack = decapsulation)

  L1  Physical:  101000110101...   -> read bits
  L2  Data Link: strip Ethernet header/trailer
  L3  Network:   strip IP header
  L4  Transport: strip TCP header
  L7  Application: deliver [ DATA ] to the app

The key idea: each layer on one machine logically communicates with the same layer on the other machine, even though the real data physically goes all the way down to the wire and back up.

Troubleshooting: work up the stack

The biggest practical payoff of layering is a methodical way to debug. Start at the bottom and work up — there is no point testing DNS if the cable is unplugged.

Layer Question to ask Tool / check
L1 Physical Is it plugged in / link up? Check cable, link LED, ip link
L2 Data Link Is the local link working? ip neigh (ARP), switch port status
L3 Network Can I reach the IP / gateway? ping <gateway>, ping 8.8.8.8, ip route
L4 Transport Is the port open / listening? ss -tlnp, telnet host 443
L7 Application Does the service respond correctly? curl -v https://..., dig name

Classic example

A user says "the website is down." 1. L3: ping 8.8.8.8 works -> the network and routing are fine. 2. L7: dig example.com returns nothing -> the problem is DNS, not connectivity. Working up the stack pointed straight at the layer at fault.

# Linux quick stack check
ip link                 # L1/L2: is the interface up?
ping -c1 8.8.8.8        # L3: raw IP reachability
ss -tlnp                # L4: what ports are listening?
curl -v https://example.com  # L7: does the app answer?
:: Windows equivalents
ipconfig                 :: L1-L3 interface info
ping 8.8.8.8             :: L3 reachability
netstat -ano             :: L4 listening ports
nslookup example.com     :: L7 DNS lookup

DNS specifics are in DNS and DHCP, and the Linux track has a hands-on guide in networking basics.

Verify your work

  • Recite the OSI layers top to bottom using "All People Seem To Need Data Processing."
  • Which OSI layer is a switch? A router? TCP? HTTP?
  • What is the PDU name at the Transport layer? At the Data Link layer?
  • During encapsulation, does each layer add a header on the way down or up the stack?
  • For a "site is down" report, what is the first layer you should test, and why?

Summary

  • Layered models split networking into independent jobs that are easier to build and debug.
  • OSI has 7 layers (Physical → Application); TCP/IP has 4 (Link, Internet, Transport, Application) and is what the internet runs on.
  • Memorize OSI with "All People Seem To Need Data Processing."
  • PDUs by layer: bits → frames → packets → segments → data.
  • Encapsulation adds headers going down the stack; decapsulation strips them going up.
  • Common mapping: switch = L2, router = L3, TCP/UDP = L4, HTTP/DNS = L7.
  • Troubleshoot by working up the stack — verify physical/link/IP before blaming the application.

Test yourself