Classify any IPv4 or IPv6 address by its leading bits (private, loopback, link-local, documentation, public), read CIDR `/N` to predict host count, and compress an IPv6 address to canonical form with a single `::`.

Run `ifconfig` and one line reads `inet 192.168.1.42`, which looks like four small numbers with dots between them. It is really one 32-bit integer, and its leading bits alone already say whether it can leave your machine at all.

Name the four numbers that identify a TCP connection, predict whether two `bind()` calls collide before running them, and read a `TIME_WAIT` row in `ss` as an address still held after close.

`ss -tn` on a machine serving traffic prints dozens of rows, and every one shows `10.0.0.5:443` on the left with a different address on the right. One slot, dozens of live conversations, and the right column is why.

Separate the stub's single query from the recursive's walk down the root, TLD, and authoritative chain, read a `dig +trace` block by block, and predict when a repeat lookup skips the walk from cache.

`dig example.com` prints one answer in a few milliseconds, but `dig +trace example.com` prints three screens of servers handing you off, each one saying `ask them instead` until the last one finally answers.

Read a `dig` answer line as five fields, match A, AAAA, CNAME, MX, and TXT to the payload each carries, and predict how long a record change takes to clear every cache from the TTL already in flight.

`dig example.com` prints one line: a name, a couple of numbers, and an address. Change that address at the source and half the internet keeps handing out the old one for hours, each server on its own clock.

Trace the `hosts:` line of `/etc/nsswitch.conf` to predict which source answers a name, distinguish an `/etc/hosts` override that `ping` honors from one `dig` ignores, and read the `[NOTFOUND=return]` bracket that keeps `.local` names off your ISP's resolver.

Add one line to a file on your disk and `ping app.example` answers with the address you picked. Run `dig app.example` right after and it ignores that line entirely, going straight to the network instead.

Send SYN, SYN-ACK, and ACK across two endpoints, predict which packet flips each side to `ESTABLISHED`, and read a real `tcpdump` capture line by line where each `ack` is the previous `seq` plus one.

`connect()` looks instant in your code, but the socket sits quiet for one round trip first, while two machines trade three small messages to agree on where each will start counting bytes.

Close each direction of a connection on its own, predict why only the active closer lingers in `TIME-WAIT`, and read the `FIN`, `RST`, and `CLOSE-WAIT` rows an abort or a leak leaves in `ss -tan`.

`ss -tan` can show a socket sitting idle for a minute or more after your program moved on, still holding its place so a late-arriving byte from the old conversation cannot land in a new one.

Meter the sender's in-flight bytes against a receive window that shrinks as the receiver's buffer fills, watch three duplicate acknowledgments fire a fast retransmit while a silent wire falls back to a doubling timer, and unshift a scaled `win` value off `tcpdump`.

`tcpdump` prints a line like `win 501` on nearly every acknowledgment, and that one number is a live ceiling: send past it and the receiver has nowhere to put the bytes, so the sender waits.

Strip TCP's twenty-byte header down to UDP's eight, trace a two-packet DNS exchange against TCP's setup-and-teardown, and decide which workloads go connectionless by weighing a resend's wait against a lost message's cost.

`dig example.com` answers in a single round trip: one packet out, one packet back, and the server holds nothing after it replies. The same fetch over a fresh TCP connection must set the link up before the request can leave.

Size a packet to the smallest link on its path, predict whether an oversize one splits into all-or-nothing fragments or bounces back a too-big report, and read TCP's `mss` as the handshake-time ceiling that avoids fragmentation, until a filtered report hangs the transfer.

`ping -M do -s 1472 example.com` goes through, but bump the size to `-s 1473` and it fails with "message too long": one byte past a limit set not by your machine, but by a link somewhere along the way.

Read a `curl -v` transcript line by line: name the request line, header fields, empty-line boundary, and body, tell a status line from a request line by its first token, and sort each line onto the sent or received side of the wire from its `*`, `>`, `<` prefix.

`curl -v https://example.com/hello` prints a dozen lines before the page ever loads, each tagged `*`, `>`, or `<`, and every one is plain text a parser reads top to bottom: no magic, no binary, nothing you cannot spell out yourself.

Classify each method by its two protocol bits (safe? idempotent?), predict which dropped requests a client auto-retries and which a repeated POST turns into a duplicate, and read the 405 plus Allow header that says the route exists but the verb does not.

`curl -X POST` and `curl -X GET` hit the same URL, and only the letters after `-X` change on the wire. Yet a dropped connection turns one into a free retry and the other into a gamble.

Weight an Accept wishlist with quality values and predict which representation a server returns, tell a served default apart from a 406 when no listed type is available, and name the Vary header that stops a shared cache serving the wrong variant.

Run `curl` against one report URL twice, change the single line naming which format you will take back, and different bytes come home each time, same address, different document, though the URL never said which.

Sort any status code into its class from its first digit alone, route a failure by that class (4xx means change the request, 5xx means retry the server), separate a 5xx from a refused connection that returns no code at all, and catch a 200 whose error body means the request actually failed.

`curl` a broken URL and you might get `< HTTP/1.1 503` back, or `curl: (7)` with no `<` line at all. One is the server talking, the other is silence, and they are not the same failure.

Drive a stored response from fresh to stale, replay its ETag in a conditional request to pull back a bodyless 304 instead of a full 200, and separate no-cache (still stored, always revalidated) from no-store (never stored).

Run `curl -v https://example.com/logo.png` twice and the first prints a full image behind a screenful of headers. The second can come back before the request ever reaches the server, or with an empty body: same command, very different cost.

Trace one lost segment across an HTTP/2 connection versus HTTP/3 over QUIC and predict how many streams freeze, explain why multiplexing relocates head-of-line blocking down a layer instead of deleting it, and pick the protocol whose connection survives a client that changes network mid-download.

Run `curl --http3 https://example.com` and the whole page rides one UDP flow; drop a single segment on the older connection and every asset behind it stalls at once. Same request, two transports, two different failure shapes.

Name the scheme, host, and port that form a URL's origin, decide whether two pages are same-origin, and predict whether a script can read a cross-origin response or only send the request.

Your `fetch('https://api.example.com/data')` fires and the server answers with a normal `200`, yet the console shows a red error and your code cannot touch the body. The response arrived; the browser refused to let your script read it.

Read an OPTIONS preflight exchange and name what each Access-Control-* header does, predict whether a request is sent directly or preflighted from its method and content type, and fix a wildcard origin that breaks the moment credentials ride along.

Your `fetch('https://api.example.org/orders')` comes back blocked, so you keep adding headers to the request and it keeps failing. The one header that unblocks it lives on the response, and only the server can send it.

Predict whether a stored cookie rides a cross-site request from its SameSite value, tell the site boundary apart from the origin boundary that blocks a cross-origin read, and assemble the flags a login session versus a third-party embed each needs.

`curl -v https://app.example.com` prints one line you typed and one the browser adds without asking: a header carrying a value the server handed you on an earlier response, replayed now on its own, with no code re-sending it.

Sort each http subresource an https page loads into upgraded or blocked by whether it can modify the page, predict when an upgrade silently drops a resource, and decide which pages are secure contexts that expose powerful APIs.

You ship a dashboard over `https`, the address bar shows the closed padlock, and one `<script src="http://...">` you pasted months ago never runs. The page half-renders and the console prints one red line explaining the drop.

Trace a request as it stops at the worker's `fetch` handler, predict which response comes back (the network, a hand-filled cache, or a JavaScript string), and tell the worker's Cache Storage apart from the HTTP cache it does not obey.

You switch the browser to `Offline`, reload the notes app you shipped, and `fetch('/today.json')` still comes back `200` with today's list, no request having left the machine. Something answered in the network's place.

Read a TLS 1.3 handshake message by message, predict why a guessed key share closes it in one round trip while a rejected guess costs a second, and separate the certificate the server presents from the signature that actually proves it holds the key.

Type `https://` and your browser runs a whole conversation before the first HTTP byte leaves: a second round of messages that agrees a key nobody sent and proves the server is who it claims. Read what crosses the wire.

Climb a certificate chain from the leaf to a root already in your trust store, predict why a missing intermediate breaks curl and Firefox while Chrome silently refetches it, and watch a cross-signed intermediate give one leaf two valid paths to two different roots.

Your server's certificate is valid, in-date, and names the right host, yet `curl` still refuses it with `unable to get local issuer certificate`. Validity was never the question: someone has to vouch for it, all the way up.

Present a client certificate so a server running mutual TLS lets you in, then pin one expected key and watch a fully valid, freshly-issued certificate get refused on purpose, and see why the wrong pin locks out your own users.

`curl https://api.example.com` succeeds, but `curl` against an internal service stalls: the server sends a `certificate required` alert. It finished checking you, then asked the other way: prove who you are, or you are not coming in.