Networking - Basic

Why Networking Matters in DevOps

You can write flawless code, containerize it perfectly, and deploy it to a rock-solid server - and none of it matters if the request from a user's browser can't find its way there and back. Networking is the plumbing underneath everything else in DevOps: every deploy, every health check, every API call between two services, every git push is network traffic. When something in production breaks, "is it a code problem or a network problem" is often the very first fork in the road, and you can't answer that question without understanding what's supposed to be happening underneath.

This tutorial focuses on networking as it shows up in infrastructure and operations work - not the deep academic theory, but the concepts you'll actually lean on when reading logs, configuring a load balancer, or figuring out why a service can't reach another service.

---

IP Addresses and Subnets

Every device on a network needs an address, the same way every house needs a street address for mail to arrive. That's an IP address - a numeric identifier like 192.168.1.10. The version you'll see constantly is IPv4, written as four numbers from 0-255 separated by dots.

Addresses don't exist in isolation - they're grouped into subnets, blocks of addresses that belong together, the way houses on the same street share a zip code. A subnet is usually written with a slash, like 192.168.1.0/24. That /24 says "the first 24 bits are fixed for this network, the remaining 8 bits identify individual devices" - which works out to 256 possible addresses in that block.

Why does this matter operationally? Because two machines can only talk directly if they're reachable on the same network path, and cloud providers (AWS, GCP, Azure) organize entire virtual networks - VPCs - around subnets. When you provision a server "in a private subnet," you're saying it gets an address that isn't reachable from the public internet at all, only from other things inside that same virtual network.

---

Ports and Protocols

An IP address gets a packet to the right machine. A port gets it to the right application on that machine. Think of the IP address as a building's street address and the port as the specific suite number inside it - the mail carrier needs both.

Ports are numbers from 0 to 65535, and certain ones are reserved by convention as "well-known ports": 80 for plain HTTP, 443 for HTTPS, 22 for SSH, 5432 for Postgres, 3306 for MySQL. When you connect to example.com:443, you're saying "reach this machine, then hand my traffic to whatever's listening on port 443" - which is almost always a web server.

Underneath the port sits the protocol - the rules for how the conversation happens. The two you'll deal with constantly:

• TCP (Transmission Control Protocol): reliable and ordered. It confirms every piece of data arrived, and resends anything lost. Web traffic, database connections, and SSH all use TCP because losing or scrambling data would be unacceptable.
• UDP (User Datagram Protocol): fast and "fire and forget." No confirmation, no automatic resending. Used for things like DNS lookups and video streaming, where a little loss is fine but waiting for a retransmission would be worse.

This is a common beginner confusion: TCP isn't just "the good one" - it trades speed for reliability. UDP is a deliberate choice, not a lesser protocol.

---

How DNS Resolution Actually Works

Nobody wants to remember 93.184.216.34 when they could type example.com instead. DNS (Domain Name System) is the system that translates human-readable names into IP addresses, and understanding its actual mechanics - not just "it turns names into IPs" - will save you real debugging time later.

When your computer needs to resolve example.com, it doesn't just ask one server and get an instant answer. It typically asks a resolver (often run by your ISP or a service like Google's 8.8.8.8), which then walks a hierarchy:

1. It asks a root server: "who handles .com?"
2. The root server points it to a TLD server for .com.
3. The TLD server points it to the authoritative name server for example.com specifically - usually run by whoever hosts the domain.
4. That authoritative server finally answers with the actual IP address.

In practice, this whole chain is heavily cached at every step, so it's rarely done from scratch - but when you hear "DNS propagation is slow" or "the DNS cache is stale," this is the machinery being referenced. A DNS record also carries a TTL (time-to-live), which tells caches how long they're allowed to keep an answer before asking again.

---

HTTP Basics

HTTP (HyperText Transfer Protocol) is the language browsers and web servers speak to each other, and it's a request/response protocol - the client sends a request, the server sends back a response, and that's the whole interaction.

A request has a method describing the intent - GET to fetch something, POST to submit data, PUT to replace something, DELETE to remove it - plus a path and some headers with metadata.

The response always comes back with a status code, a three-digit number telling you broadly what happened:

• 2xx - success (200 OK is the classic "it worked")
• 3xx - redirection ("go look over here instead")
• 4xx - client error, something wrong with the request (404 Not Found, 401 Unauthorized)
• 5xx - server error, something broke on the server's end

Getting fast at reading status codes is one of the highest-leverage skills in this whole tutorial - a 502 versus a 404 versus a 504 immediately tells you whether to look at your code, your infrastructure, or the thing you're trying to reach.

---