The three-box mental model
Almost everything in networking can be explained with three boxes. A request starts at the client, travels across the network, and arrives at the server — and the response travels back the same way.
- A request leaves the client, crosses the network, and reaches the server.
- When something breaks, the fault is in one box or the link between them.
DNS: turning names into IP addresses
When you type a URL like google.com, your computer does not actually understand the name. Computers only understand numbers — IP addresses. DNS (the Domain Name System) exists to bridge that gap: it resolves a name to an IP address.
- Computers only understand IP addresses, not names.
- If DNS fails, nothing else works even when the server is healthy.
Think of DNS like a phone book: you look someone up by name and get back a number. And it is load-bearing — if DNS breaks, nothing works, even when your server is perfectly healthy, because nothing can find its address.
IP addresses and ports
An IP address identifies a machine on a network; a port identifies which application on that machine you want to talk to. A single machine can run many applications at once, each on its own port.
- Public IP (e.g. 13.234.56.78) — reachable from the internet.
- Private IP (e.g. 192.168.1.10) — only reachable inside a private network, such as a cloud VPC (Virtual Private Cloud).
- IP picks the machine; the port picks which app on it.
- Common ports: 22 SSH, 80 HTTP, 443 HTTPS, 5432 PostgreSQL.
So the shorthand is simple: the IP address is which computer, and the port is which app on that computer.
TCP vs UDP: how data is sent
Once you know where to connect, the next question is how the data travels. That is set by the transport protocol — and for DevOps the two that matter are TCP and UDP.
| Aspect | TCP | UDP |
|---|---|---|
| Reliability | Guaranteed delivery | No delivery guarantee |
| Ordering | Arrives in order | May arrive out of order |
| Connection | Connection-based | Connectionless |
| Speed | Slightly more overhead | Faster, low overhead |
| Used by | HTTP, HTTPS, SSH, databases | DNS, streaming, some internal systems |
A useful way to remember the difference: TCP is like a phone call — you connect, you talk, you hang up, and you know the other side heard you. UDP is like shouting a message across a room — fast, but with no confirmation it arrived.
What ping really does (ICMP)
ping is usually the first reachability test people reach for. It sends a special network message called an ICMP Echo Request — essentially asking the server, "are you alive?" If the server is reachable and allows it, it replies with an ICMP Echo Reply, and your terminal prints a round-trip time. But ping checks less than people assume.
| ping verifies | ping does NOT verify |
|---|---|
| The IP is reachable over the network | The application is running |
| Basic connectivity exists | The website is working |
| The network path works | The port is open |
| The round-trip time | The server is healthy |
ping vs dig and nslookup
If ping already does a DNS lookup when you give it a name, why do dig and nslookup exist? Because ping only does DNS as a prerequisite to get going. dig and nslookup exist to inspect and debug DNS itself — showing the DNS server, record types, TTLs, and multiple IPs.
| Aspect | ping | dig / nslookup |
|---|---|---|
| Main question | Can I reach the IP? | Is DNS working correctly? |
| Main purpose | Network reachability | DNS resolution and config |
| Uses DNS? | Yes, minimally | Yes, as the main focus |
| Shows the DNS server | No | Yes |
| Shows record types and TTL | No | Yes |
| Affected if ICMP is blocked | Yes | No |
Why cloud servers block ping
ping uses ICMP, a low-level network check. Attackers can use it to find live servers and map infrastructure, so cloud providers often block it for security. Real users never use ICMP anyway — they use HTTP, HTTPS, and TCP connections — so blocking ping does not affect them. That is why ping myserver.com can fail while the application is running perfectly.
ICMP vs TCP vs HTTP
These three protocols sit at different layers and answer different questions. ICMP only asks "can I reach this server at all?" TCP opens reliable connections to applications on ports. HTTP and HTTPS are application-level protocols built on top of TCP — the ones real users actually use.
| Thing | ICMP (ping) | TCP / HTTP |
|---|---|---|
| Purpose | Reachability | Real communication |
| Uses ports? | No | Yes |
| Talks to the app? | No | Yes |
| Blocked often? | Yes | Rarely |
| Used by real users? | No | Yes |
The DevOps networking toolkit
Four questions, five commands. Each tool checks one specific thing, from the name all the way to the application.
- dig / nslookup — is DNS resolving the name to an IP? nslookup also shows the DNS server and response details.
- ping — is the host reachable over the network? (ICMP)
- nc (netcat) — is the port open? It opens a TCP connection and reports back.
- curl — does the application actually respond over HTTP/HTTPS?
# 1. Is DNS resolving?
dig google.com +short
nslookup google.com
# 2. Is the host reachable?
ping google.com
# 3. Is the port open? (nc = netcat; -v verbose, -z no data sent)
nc -vz google.com 443
# 4. Does the app respond? (-I = HEAD request, headers only)
curl -I https://google.comThe real debugging order
Put it together and you get a reliable order: resolve the name, reach the host, open the port, then talk to the app. Work through it top to bottom and stop at the first failure — that is where the problem is.
- dig checks DNS, ping checks reachability, nc checks the port, curl checks the app.
- Each step assumes the previous one passed; stop at the first failure.
dig google.com # DNS resolving?
ping google.com # host reachable?
nc -vz google.com 443 # port open?
curl https://google.com # app responding?Drafted with AI assistance from an author outline and edited by TechToolsHQ.