Networking Basics for DevOps

Almost everything you do in DevOps involves a network. When you deploy a website, a user’s browser somewhere in the world needs to reach your server. When your app talks to a database, that is a network call too. If you do not understand how data moves between machines, debugging a broken deployment feels like guessing in the dark. This page gives you a plain-English mental model of networking so the rest of this section makes sense.

What a network actually is

A network is just two or more computers that can send data to each other. They might be connected by a cable, by Wi-Fi, or across the entire internet through many hops in between. The internet is simply the biggest network of networks on Earth.

When one computer wants to send data to another, it does not send everything in one giant lump. Instead it chops the data into small pieces called packets (small, numbered chunks of data). Each packet travels independently across the network and gets reassembled in the right order on the other side. If a packet gets lost on the way, it can be re-sent without re-sending everything. This is why a video can keep playing even when the network hiccups.

Think of packets like pages of a book mailed in separate envelopes. Each envelope has the destination address and a page number, so even if they arrive out of order, the reader can rebuild the book correctly.

Clients and servers

Most network communication follows a client-server model. Two simple definitions:

• A server is a program (running on a computer) that waits for requests and responds to them. A web server, a database, and an SSH service are all servers.
• A client is a program that starts the conversation by sending a request. Your web browser, the curl command, and a mobile app are all clients.

The same physical machine can be both. Your Ubuntu server runs a web server (acting as a server to browsers) but can also run curl to call an external API (acting as a client).

Term	Role	Example
Client	Starts the request	Browser, curl, ssh command
Server	Listens and replies	Nginx, PostgreSQL, the SSH daemon sshd
Request	The “ask” sent by the client	”Give me the home page”
Response	The “reply” from the server	The HTML of the page

When to think client vs server: any time something is not connecting, ask “which side is the client and which is the server, and is the server even running and listening?” That single question solves a huge number of problems.

How a request finds its destination

For a client to reach a server, three things must line up:

1. An address — every device on a network has an IP address (Internet Protocol address), a unique number like 203.0.113.10 that identifies it. This is covered in detail on the IP addresses page.
2. A port — a single server machine runs many services at once, so each service listens on a numbered port (a door on the machine). Web traffic usually uses port "80" or "443"; SSH uses port "22". See the ports page for the full picture.
3. A name — humans use names like devcraftly.com instead of numbers. DNS (Domain Name System) translates a name into an IP address, like a phone book for the internet.

So when you open https://devcraftly.com, your computer asks DNS for the IP, opens a connection to that IP on port "443", and sends an HTTP request. The server replies with the page.

The TCP/IP model in one minute

Networking is built in layers, and the common model is called TCP/IP. You do not need to memorize it, but knowing the layers helps you place a problem.

Layer	What it does	You see it as
Application	The actual app protocol	HTTP, SSH, DNS
Transport	Reliable delivery and ports	TCP, UDP
Internet	Addressing and routing	IP addresses
Link	The physical connection	Ethernet, Wi-Fi

Two transport protocols matter most:

• TCP (Transmission Control Protocol) sets up a connection and guarantees every packet arrives in order, re-sending any that are lost. Use it when correctness matters: web pages, SSH, databases.
• UDP (User Datagram Protocol) just fires packets off with no guarantee they arrive. Use it when speed matters more than perfection: live video, voice calls, DNS lookups.

Checking the network on Ubuntu

Here are real commands you can run today on Ubuntu 22.04 or 24.04 LTS to see networking in action.

See your own IP address and network interfaces:

ip address show

Output:

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 06:1f:9a:2c:44:8e brd ff:ff:ff:ff:ff:ff
    inet 203.0.113.10/24 brd 203.0.113.255 scope global eth0
       valid_lft forever preferred_lft forever

Test whether you can reach another machine (this sends small test packets):

ping -c 3 1.1.1.1

Output:

PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
64 bytes from 1.1.1.1: icmp_seq=1 ttl=57 time=4.21 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=57 time=4.05 ms
64 bytes from 1.1.1.1: icmp_seq=3 ttl=57 time=4.11 ms

--- 1.1.1.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms

See which services are currently listening on your server (which ports have a server behind them):

sudo ss -tlnp

Output:

State    Recv-Q   Send-Q   Local Address:Port    Peer Address:Port   Process
LISTEN   0        128            0.0.0.0:22           0.0.0.0:*       users:(("sshd",pid=812,fd=3))
LISTEN   0        511            0.0.0.0:80           0.0.0.0:*       users:(("nginx",pid=1340,fd=6))

If ss is not installed, add it with sudo apt update && sudo apt install -y iproute2.

Security gotcha: a service listening on 0.0.0.0 is reachable from the whole internet. A service listening on 127.0.0.1 (localhost) is only reachable from the machine itself. Databases should almost always bind to 127.0.0.1 and be exposed only through a firewall or SSH tunnel.

Why this matters for deploying and debugging

Most “the site is down” incidents come down to one of these network facts being wrong:

• The server process is not running, so nothing is listening on the port.
• A firewall is blocking the port (covered on the UFW page).
• DNS points to the wrong IP, so clients reach the wrong place.
• The app is bound to 127.0.0.1 when it needed to be reachable from outside.

Knowing the client-server-address-port chain lets you check each link one at a time instead of randomly restarting things.

Best Practices

• Always know whether you are debugging the client side or the server side before you change anything.
• Use ss -tlnp to confirm a service is actually listening before blaming the network.
• Bind internal services (databases, caches) to 127.0.0.1 and expose them only deliberately.
• Use ping and curl to test one layer at a time: connectivity first, then the application.
• Quote port numbers in config and notes carefully, and document which port each service uses.
• Prefer TCP for anything where correctness matters, and reach for UDP only when low latency beats reliability.

Related Topics

• IP addresses
• Ports and protocols
• DNS basics
• The OSI model
• Network commands