Skip to content
DevOps devops networking 6 min read

The OSI & TCP/IP Models

Every time your browser loads a website, dozens of separate jobs happen — turning a name like devcraftly.com into an address, packaging your request into chunks, sending those chunks across cables and Wi-Fi, and reassembling them on the other side. To keep all of that organised, networking is split into layers, where each layer does one job and hands its work to the next. The OSI model and the TCP/IP model are two ways of describing those layers. You will hear “layer 7” and “layer 4” constantly in DevOps (especially around load balancers and firewalls), so this page makes them concrete.

Why layers exist

A layered model is just a way of dividing a big problem into smaller, independent steps. Each layer only needs to talk to the layer directly above and below it. That means a web developer can work on the top layer (HTTP) without caring whether the data travels over fibre, copper, or Wi-Fi at the bottom layer.

The two models you will meet:

  • OSI model — a 7-layer teaching model from the 1980s. Nobody implements it exactly, but its layer numbers are the shared vocabulary engineers use (“a layer 4 load balancer”).
  • TCP/IP model — the practical 4-layer model the real internet actually runs on. This is what your Ubuntu server uses.

The OSI 7 layers

Read this from the bottom (1) up. Layer 1 is closest to the physical wire; layer 7 is closest to you, the user.

#LayerWhat it does (plain English)Real examples
7ApplicationThe actual app data you care aboutHTTP, HTTPS, DNS, SSH, SMTP
6PresentationFormatting, encryption, compressionTLS/SSL, JPEG, UTF-8
5SessionOpening/closing conversations between appsTLS session, NetBIOS
4TransportReliable delivery, ports, splitting into segmentsTCP, UDP
3NetworkLogical addressing and routing between networksIP, ICMP (ping), routing
2Data linkMoving frames between two directly-connected devicesEthernet, MAC addresses, ARP, Wi-Fi
1PhysicalThe actual signals on the wire/airCables, fibre, radio, voltages

A common memory aid (top to bottom): All People Seem To Need Data Processing.

In practice, layers 5, 6, and 7 blur together. When someone says “layer 7” they almost always mean the application layer where they can read HTTP requests, including the TLS and formatting that OSI splits into 5 and 6.

The TCP/IP 4-layer model

This is the model the internet — and your server — really uses. It collapses the 7 OSI layers into 4 practical ones.

TCP/IP layerCovers OSI layersJobExamples
Application5, 6, 7App protocolsHTTP, HTTPS, SSH, DNS
Transport4Ports + reliabilityTCP, UDP
Internet3Addressing + routingIP, ICMP
Link1, 2Local hardware deliveryEthernet, Wi-Fi, ARP

So the full journey of a web request, top to bottom: your browser builds an HTTP request (Application), TCP wraps it with a source and destination port and guarantees delivery (Transport), IP stamps it with source and destination IP addresses and figures out the route (Internet), and Ethernet/Wi-Fi turns it into signals on the wire (Link). The receiving server unwraps it in reverse.

TCP vs UDP — the transport layer choice

Layer 4 (Transport) is where you pick how data is delivered. This is a real decision you make when running services.

TCPUDP
Reliable?Yes — resends lost data, keeps orderNo — fire and forget
ConnectionYes (handshake first)No
SpeedSlightly slowerFaster, lower overhead
When to useWeb, SSH, databases, anything that must arriveVideo/voice calls, DNS lookups, gaming, metrics

When NOT to use UDP: anything where a missing byte corrupts the result — file transfers, web pages, API calls. Use TCP there.

Seeing the layers on your Ubuntu server

You can observe these layers with standard tools. Install them on Ubuntu 22.04/24.04:

sudo apt update
sudo apt install -y iproute2 traceroute tcpdump curl

Layer 3 (Internet) — routing. traceroute shows each router (each “hop”) your packet passes through:

traceroute -n devcraftly.com

Output:

traceroute to devcraftly.com (104.21.0.1), 30 hops max, 60 byte packets
 1  192.168.1.1  0.84 ms  0.79 ms  0.77 ms
 2  10.20.0.1    9.21 ms  9.18 ms  9.10 ms
 3  104.21.0.1   11.4 ms  11.3 ms  11.2 ms

Layer 4 (Transport) — ports and connections. ss (socket statistics, the modern replacement for netstat) lists open TCP ports:

sudo ss -tlnp

Output:

State   Recv-Q  Send-Q   Local Address:Port   Process
LISTEN  0       511            0.0.0.0:80      users:(("nginx",pid=812))
LISTEN  0       128            0.0.0.0:22      users:(("sshd",pid=701))

Layers 2-4 together — watch real packets. tcpdump captures live traffic so you can see the MAC, IP, and TCP details in one place:

sudo tcpdump -i any -n -c 5 port 443

Output:

14:02:11.331 IP 203.0.113.5.51422 > 104.21.0.1.443: Flags [S], seq 12, win 64240
14:02:11.349 IP 104.21.0.1.443 > 203.0.113.5.51422: Flags [S.], seq 88, ack 13

That [S] then [S.] is the start of the TCP three-way handshake — a layer 4 event.

Why “layer 4” vs “layer 7” matters in load balancing

This is the single most important reason the layers come up in DevOps. A load balancer (a server that spreads incoming traffic across several backend servers) can work at different layers, and the layer changes what it can do.

Layer 4 load balancerLayer 7 load balancer
SeesIP addresses + TCP/UDP portsFull HTTP request (URL, headers, cookies)
Can route byPort and protocol onlyPath (/api), hostname, cookies
TLSPasses encryption throughCan terminate TLS and read content
SpeedFaster (less to inspect)Slightly slower, far smarter
ExamplesAWS NLB, HAProxy in TCP modeNginx, AWS ALB, HAProxy in HTTP mode

For example, Nginx is a layer 7 load balancer because it reads the HTTP request and can send /api to one group of servers and /images to another. Here is a real Ubuntu config that does that:

# /etc/nginx/sites-available/myapp
upstream api_servers   { server 10.0.0.11:3000; server 10.0.0.12:3000; }
upstream image_servers { server 10.0.0.21:8080; }

server {
    listen 80;
    server_name devcraftly.com;

    location /api/    { proxy_pass http://api_servers; }
    location /images/ { proxy_pass http://image_servers; }
}

A layer 4 load balancer cannot do that path-based routing — it never sees the URL, only the IP and port. Use layer 4 when you need raw speed or are balancing non-HTTP traffic (like a database); use layer 7 when you need to route based on request content.

Best practices

  • Learn the OSI numbers even though the real world runs TCP/IP — “layer 4” and “layer 7” are universal shorthand in cloud and load-balancing docs.
  • Choose layer 7 load balancing (Nginx, AWS ALB) when you route by URL path, hostname, or cookies; choose layer 4 (NLB, HAProxy TCP) for raw speed or non-HTTP protocols.
  • Default to TCP for anything that must arrive intact; reserve UDP for real-time data where a dropped packet is acceptable.
  • Use modern tools — ss instead of netstat, ip instead of ifconfig — on Ubuntu 22.04/24.04.
  • When debugging, work down the layers: confirm DNS and HTTP (layer 7) with curl, then ports (layer 4) with ss, then routing (layer 3) with traceroute.
  • Reach for tcpdump only when higher-level tools fail — it shows the raw truth across layers 2-4.
Last updated June 15, 2026
Was this helpful?