Networking

Every machine on a network is identified by one or more IP addresses. Read the addresses on this sandbox, see the IPv4 and IPv6 forms, and notice the loopback address every host has.

An IP address identifies a host. A port identifies which program on that host. A socket is the IP plus port pair. See the well-known port list and confirm common services.

ping asks one question, is the host alive. traceroute answers a second, which routers does my packet pass through. Use both to debug a slow or broken connection.

DNS turns names into addresses and more. Look up the five record types you will hit most often as an engineer using one tool, dig.

dig has dozens of flags. Three of them carry most of the diagnostic work. Use +short for one-line answers, +trace to follow a query from the root, and +nocmd to keep output tidy.

dig is the engineer favourite, but host and nslookup are present on almost every system and produce more compact output. Use each tool to look up the same name and compare.

Before DNS gets called, Linux checks /etc/hosts. The list of DNS servers to use lives in /etc/resolv.conf. Read both and add a local override.

HTTP is a text protocol over TCP. A request has a method, a path, headers, and a body. A response has a status line, headers, and a body. See both with curl -v.

Status codes are grouped by hundred. 2xx success, 3xx redirect, 4xx client error, 5xx server error. Trigger 200, 301, 404, and 500 from a public test service.

GET, POST, PUT, PATCH, DELETE. Each has a meaning, a safety profile, and an idempotency profile. Send each one with curl against httpbin and see the request echoed back.

Headers carry metadata for the request and response. Cookies are state in a Set-Cookie response header that the client returns on later requests. Set and read both with curl.

curl is the multi-tool of HTTP debugging. Use -v for verbose, -I for headers, -o for output to a file, -w for timing fields, and -L to follow redirects.

TLS protects HTTP from three problems. Read the body of a plain HTTP request and an HTTPS request, see that one is in the clear and the other is not, and confirm the cert chain with curl.

A server cert is trusted because a CA signed it. The CA is trusted because a root signed the CA. Walk the chain with openssl s_client and find the root.

nc is the lowest-level TCP client. Connect to a port, send raw bytes, read raw bytes. Use it to test whether a port is open, and to speak HTTP by typing the request line yourself.

openssl s_client is the TLS equivalent of nc. Open a TLS connection by hand, see the cert, the protocol version, the cipher, and then speak HTTPS yourself.

ss is the tool for asking the kernel what TCP and UDP sockets are open. List listeners, filter by port, and read the receive queue depth.

lsof lists open files, and sockets are files. Use lsof -i to map a port number back to the process that opened it, the classic answer to who is on port 8080.

A reverse proxy accepts requests on one port and forwards them to a backend on another. Configure nginx to proxy port 8080 to a small backend on port 9000 and verify with curl.

A health check is an endpoint that says yes or no. Build a tiny one that returns 200 when a marker file exists and 503 when it does not. Probe with curl to mimic what a load balancer does.

A service ships with a contract, GET /health on 127.0.0.1:8080 answers 200 with body ok. It is broken twice, at two different layers, and the lower fault hides the upper one. Use the OSI model the way operators actually use it, to route each symptom to a layer, pick the tool that probes that layer, and fix what you find.

A reverse proxy answers on its port, so layer 4 says everything is fine. Users still see an error page, because layer 7 knows the backend behind the proxy is dead. Probe the same address at both layers, explain why they disagree, and bring the stack back.

A port carries bytes, and a protocol is the agreement about what those bytes mean. A monitoring client keeps failing against a service that is demonstrably up. Talk to the port raw, read the bytes that actually flow, and discover the two sides are speaking different protocols.

A machine is not one address. It is interfaces, each carrying addresses, and a socket binds to one address on one port. A service is provably running and still unreachable at the address its clients dial, because it bound somewhere else. Map the machine's addresses, find where the socket actually lives, and put it where the contract says.

Trust on the web is a chain, a CA signs a server's certificate and clients verify against the CA they already trust. Build the whole chain yourself, a CA, a signed server certificate, a TLS service. Watch verification fail for the exact reason it should, then fix it by distributing trust the honest way. What you do by hand here is what Let's Encrypt automates for the public web.

An open-ended problem with no prescribed config. Run a backend service on one port and a reverse proxy on another, so the public endpoint serves the backend's content. Any working two-tier setup passes, the checks probe the result.