Networking - Medium

The TCP/IP Model in Practice

You'll sometimes see networking taught as a strict seven-layer OSI model, but day-to-day troubleshooting works better with a looser, four-ish layer mental model: link (physical/local network), internet (IP addressing and routing), transport (TCP/UDP), and application (HTTP, DNS, and so on). The real value of thinking in layers isn't academic - it's that it gives you a systematic way to narrow down where a problem lives.

If ping to an IP fails, you likely have a routing or link problem - the packet can't even get there. If ping succeeds but a specific port refuses to connect, the transport layer is fine but nothing's listening at the application layer. If the connection opens but the response is garbage or wrong, the problem has moved up to the application itself. Working through layers from the bottom up (or top down, depending on habit) turns "the app is broken" into a specific, falsifiable question at each step, instead of guessing.

---

DNS Record Types and TTL

Beyond the basic name-to-IP lookup, DNS carries several distinct record types, and mixing them up is a common source of misconfiguration:

• A record: maps a name directly to an IPv4 address.
• AAAA record: same idea, for IPv6.
• CNAME: an alias - "this name is really just another name," which then gets resolved again. You can't put a CNAME on the same name as other records (like an MX), which trips people up constantly.
• MX: where email for this domain should be delivered.
• TXT: arbitrary text, commonly used for domain verification and email anti-spoofing (SPF, DKIM).

Every record carries a TTL in seconds, telling resolvers how long they may cache the answer before re-checking. This is the direct cause of DNS propagation delay: when you change a record, anyone who already cached the old value under the old TTL keeps using it until that TTL expires, regardless of how fast the authoritative server updates. Lowering a record's TTL before a planned change (say, an hour ahead of a migration) is a standard trick to make the actual cutover propagate faster, because it shrinks the window stale caches can hold onto old data.

---

The TCP Handshake and What Connection Errors Actually Mean

Before any data flows over TCP, two sides perform a three-way handshake: the client sends SYN ("I want to connect"), the server replies SYN-ACK ("okay, acknowledged, and here's my end"), and the client replies ACK ("acknowledged"). Only after that exchange does actual data start moving.

Understanding this handshake makes connection errors far more diagnosable, because different failure points produce distinctly different symptoms:

• Connection refused: the packet reached the target machine, but nothing is listening on that port. The OS itself is actively rejecting the connection. This usually means the app isn't running, crashed, or is bound to a different port than you expect.
• Connection timeout: the initial SYN never got a reply at all - not rejected, just silence. This usually points to a firewall silently dropping the packet, a routing problem, or the target being entirely unreachable. Timeouts are slower to diagnose precisely because nothing comes back to tell you why.
• Connection reset: the connection was established and then forcibly torn down mid-conversation, often by a firewall, load balancer, or the app itself crashing partway through handling the request.

Learning to distinguish "refused" from "timeout" from "reset" from a tool's error output is one of the single highest-value networking skills for operational work, because each one sends you looking in a completely different place.

---

Load Balancing Algorithms and Health Checks

A load balancer has to decide which backend gets each request, and the algorithm it uses matters more than it might seem:

• Round robin: cycles through servers in order. Simple, but doesn't account for one server already being under heavier load.
• Least connections: sends new traffic to whichever server currently has the fewest active connections - better for workloads where request duration varies a lot.
• IP hash: routes based on a hash of the client's IP, so the same client tends to land on the same server repeatedly.

Health checks are what make any of this safe. A load balancer periodically probes each backend - typically an HTTP request to a specific path like /health - and expects a specific response within a specific time. Two thresholds matter: how many consecutive failures mark a server "unhealthy" and pull it out of rotation, and how many consecutive successes bring it back in. Set the failure threshold too low and one slow response yanks a perfectly fine server out of rotation; set it too high and a genuinely broken server keeps eating real traffic for too long.

---