How networks gets asked

So that no one had to solve the whole problem, and so parts can change independently. Each layer offers a defined service upward and demands one downward, which is why you can swap Ethernet for Wi-Fi without touching HTTP, or IPv4 for IPv6 without rewriting applications. The cost is that layering hides information — a layer can't see what's above or below it, which is exactly why TCP can't tell Wi-Fi loss from congestion, and why MTU problems produce such confusing symptoms.

TCP/IP is what runs; OSI is the reference vocabulary. OSI has seven layers but 5 (session) and 6 (presentation) don't map onto anything deployed — TLS sits awkwardly between transport and application. In practice engineers say "L4" for transport-level and "L7" for application-level, which is OSI numbering used loosely. Saying this rather than reciting seven names signals you've used it professionally.

MAC — identifies a network interface, meaningful only on the current link, and rewritten at every hop. IP — identifies a host, meaningful end to end, and unchanged across the whole path (except through NAT). Port — identifies which process on that host. That "MAC changes every hop, IP doesn't" fact answers a surprising number of questions.

A hub is layer 1 and repeats every bit to every port — one collision domain, obsolete. A switch is layer 2, forwards by destination MAC, and gives each port its own collision domain. A router is layer 3, forwards by destination IP, rewrites layer-2 addresses and decrements TTL. The key distinction: switches separate collision domains; routers separate broadcast domains. That's why a flat network of thousands of hosts drowns in ARP no matter how good the switches are.

It learns by observation. When a frame arrives it records (source MAC → the port it came in on) in its MAC address table. If it knows the destination MAC it forwards to that single port; if not, it floods to all other ports and learns from the reply. This is why a switch needs no configuration. Note that flooding also means an unknown-destination frame briefly behaves like a broadcast.

ARP maps an IP address to a MAC address so a frame can be built. Check the cache; on a miss, broadcast "who has this IP?" and the owner replies with its MAC. The case people get wrong: if the destination is outside your subnet you do not ARP for it — you ARP for your default gateway and send the frame with the gateway's MAC but the destination's IP. Every router along the path rewrites the MACs and leaves the IPs alone. ARP is also completely unauthenticated, which is the basis of ARP spoofing.

If two switches are cabled in a loop, a broadcast frame circulates forever and is duplicated at each loop, saturating the network within seconds. There's nothing to stop it because Ethernet frames have no TTL field — that's an IP concept, and layer 2 has no equivalent hop counter. The fix is Spanning Tree Protocol, which detects loops and logically disables redundant links until they're needed.

Because a radio cannot listen while transmitting — its own signal swamps its receiver — so collisions can't be detected, only avoided. Hence random backoff even when the medium seems idle, and a layer-2 acknowledgement for every frame so the sender knows it arrived. That per-frame ACK is a large part of why Wi-Fi throughput is roughly half its advertised rate. Add the hidden terminal problem — two clients that can hear the AP but not each other — which RTS/CTS mitigates.

Almost nothing — best-effort delivery. Packets may be lost, duplicated, reordered, delayed arbitrarily, or corrupted (the header checksum catches header corruption only; IPv6 dropped even that). That minimalism is the reason IP scaled: routers stay simple and stateless, and anything more demanding is built at the edges. Reliability is TCP's job, ordering is TCP's job, and congestion response is the endpoints' job.

2^(32−26) − 2 = 64 − 2 = 62. The formula is 2^{(32−prefix)} − 2, subtracting the network address (all host bits 0) and the broadcast address (all host bits 1). Worth adding: cloud providers reserve more — AWS takes five per subnet, so an AWS /24 gives 251 rather than 254.

Block size = 256 − 192 = 64, so subnets step .0, .64, .128, .192. 130 falls in the .128 block. Network = 192.168.10.128, first usable .129, last usable .190, broadcast .191, 62 usable hosts. The fast method needs no binary: block size, count up in steps until you pass the address, step back one.

Because fixed class boundaries wasted enormous amounts of space. An organisation needing 300 addresses had to take a class B with 65,534 and waste 65,000 of them, since a class C's 254 wasn't enough. CIDR allows any prefix length, so that organisation gets a /23 with 510 addresses. It also enables route aggregation — advertising one /22 instead of four /24s — which is what kept the global BGP table from exploding. CIDR is the main reason IPv4 lasted decades past its predicted exhaustion.

Largest first, or you fragment the space. 100 hosts → /25 at 192.168.1.0 (usable .1–.126). 50 → /26 at .128 (.129–.190). 25 → /27 at .192 (.193–.222). Then two /30s at .224 (.225–.226) and .228 (.229–.230), leaving .232–.255 free. The reason order matters is alignment: a /25 must start at .0 or .128, so allocating the small ones first would strand the first half.

To stop packets circulating forever when routing is temporarily inconsistent. Every router decrements it; at zero the packet is dropped and an ICMP time-exceeded is returned to the source. Without it a routing loop would accumulate packets until the links saturated. Its secondary use is what traceroute exploits: send TTL=1 to make the first router reveal itself, TTL=2 for the second, and so on.

Losing any single fragment loses the entire original packet, so loss probability multiplies; reassembly consumes memory at the destination and is a DoS vector; and firewalls can't read ports on non-first fragments. So modern practice sets Don't Fragment and relies on Path MTU Discovery, and IPv6 removed router fragmentation entirely. The failure mode: if a firewall blocks the ICMP "fragmentation needed" message, PMTUD breaks silently and you get a connection that handshakes fine and hangs on the first full-size packet.

MTU is the largest frame payload the link will carry — 1500 bytes on Ethernet. MSS is the largest TCP payload, so MSS = MTU − IP header − TCP header = 1500 − 20 − 20 = 1460. MSS is negotiated in the SYN. Tunnels and VPNs add headers and shrink the usable MTU, which is why MSS clamping exists on VPN gateways.

The router rewrites the source IP and port of outbound packets to its own public IP and a unique port, records the mapping, and reverses it for replies. One public address therefore multiplexes tens of thousands of flows. What it breaks: inbound connections (no mapping exists until you send out — hence STUN, TURN and UPnP for P2P and VoIP), protocols embedding addresses in the payload (active FTP, SIP), IPsec AH, and per-IP rate limiting, since thousands of users share one address. And it is not a firewall — blocking unsolicited inbound is a side effect of having no mapping, not a policy.

DHCP failed and the host self-assigned a link-local address (APIPA on Windows). You'll have connectivity to other link-local hosts and nothing else. It's one of the fastest diagnostics in networking: seeing it tells you to look at the DHCP server, the relay, or the switch port. Worth also knowing 169.254.169.254 is the cloud instance metadata endpoint.

DORA. Discover — the client broadcasts from 0.0.0.0 because it has no address. Offer — a server proposes an address plus mask, gateway, DNS and lease time. Request — the client broadcasts its acceptance (a broadcast, so other servers know their offers were declined). Acknowledge — confirmed. Renewal happens at 50% of the lease. Because Discover is a broadcast it can't cross a router, so each subnet needs a relay agent forwarding to a central server.

It isn't backwards compatible — an IPv6-only host can't reach an IPv4-only host — so there was never a moment when one operator switching was individually rational, and NAT removed the urgency by making scarcity survivable. Everyone runs dual stack, with Happy Eyeballs racing both. Beyond 128 bits: a fixed 40-byte header for fast hardware parsing, no header checksum (layers 2 and 4 already verify), no router fragmentation, multicast instead of broadcast, NDP instead of ARP, and SLAAC so a host can self-configure from a router advertisement with no server.

A packet may match several routing table entries; the router uses the one with the longest prefix, because a longer prefix is a more specific claim about the network. For 10.1.5.99 against entries 10.0.0.0/8, 10.1.0.0/16, 10.1.5.0/24 and 0.0.0.0/0, all four match and the /24 wins. This is what makes hierarchy work: a provider advertises an aggregate while a customer advertises a more specific prefix inside it, and traffic still reaches the customer.

Routing is the control plane: protocols exchanging reachability information to build a picture of the network, on a timescale of seconds to minutes, in software. Forwarding is the data plane: looking up a destination and moving a packet out of the right interface, in nanoseconds, per packet, often in specialised hardware. The RIB is what the protocols built; the FIB is the optimised best-path-only copy the hardware uses.

Distance vector routers know only a distance and direction per destination and trust their neighbours' numbers, sharing their whole table with immediate neighbours (Bellman-Ford). Cheap on CPU and memory, slow to converge, and vulnerable to count-to-infinity. Link state routers flood their local link information to everyone so each builds the entire topology and runs Dijkstra locally — fast, consistent convergence at higher CPU and memory cost. RIP is the former; OSPF and IS-IS the latter.

A distance-vector failure: a destination goes down, but router A hears from B that B can reach it — via A — so A believes B and increments its cost, B then increments too, and the metric climbs slowly toward infinity while packets loop. Mitigations: cap the metric (RIP's maximum is 15 hops, 16 means unreachable), split horizon (never advertise a route back to the neighbour you learned it from), route poisoning, and triggered updates instead of waiting for the periodic timer.

OSPF finds the shortest path inside one administrative domain, where everyone cooperates and the metric is technical. BGP routes between autonomous systems run by competing companies, so the metric is policy — local preference, AS-path length, MED, communities — and expresses contracts and money rather than distance. It's path vector: advertisements carry the full AS path, which gives loop detection for free and makes policy expressible. The consequence: BGP optimises for business relationships, not latency, so traffic between two nearby cities can transit another continent.

Because BGP has no built-in verification that an AS is entitled to announce a prefix — it was designed among a small number of mutually trusting operators. If someone announces a more specific prefix for your network, longest-prefix match means the world prefers their announcement. Pakistan Telecom took YouTube offline globally in 2008 this way, and Facebook's 2021 outage was self-inflicted BGP withdrawal that made its DNS servers unreachable. Mitigations are RPKI route origin validation, prefix filtering between peers, and monitoring — it remains a partly open problem.

TCP gives a reliable, ordered byte stream with flow and congestion control, at the cost of a handshake, buffering and head-of-line blocking. UDP adds only ports and a checksum. Choose UDP when the guarantees cost more than they're worth: DNS (a handshake would triple the packets for a one-packet question), voice and video (a retransmitted frame arrives too late to play, so reliability actively hurts), gaming (newer state supersedes older), DHCP (you have no address yet), and QUIC (wants reliability but implemented in user space so it can evolve). Also: UDP preserves message boundaries and TCP doesn't.

Opening piggybacks: the server's ACK of your SYN travels in the same packet as its own SYN, so three suffices to establish sequence numbers in both directions. Closing can't be combined because TCP is full duplex and "I have no more data" is a per-direction statement — when the client sends FIN the server may still have plenty to send, which is the half-closed CLOSE_WAIT state. Only when the server's application also closes does it send its own FIN.

The side that closes first waits 2×MSL (~60 s) for two reasons. First, the final ACK might be lost, so someone must still be there to re-acknowledge a retransmitted FIN. Second, delayed duplicate packets from this connection must expire before the same four-tuple is reused, or they'd be accepted as valid data on a new connection. The problem: a busy proxy that initiates closes accumulates tens of thousands of these and exhausts ephemeral ports. The right fixes are connection reuse and tcp_tw_reuse; the wrong fix is SO_LINGER 0, which sends an RST and can discard data.

An application bug — your code isn't calling close() on sockets the peer has already closed. CLOSE_WAIT means "the peer sent FIN and we acknowledged it, but our application hasn't closed its end". The kernel cannot resolve this for you; the socket sits there holding a file descriptor until the process exits, and eventually you hit the fd limit. Contrast TIME_WAIT, which is normal kernel behaviour on the side that closed first.

Two mechanisms. A retransmission timeout based on a smoothed RTT estimate plus variance, doubled on repeated failure. And fast retransmit: three duplicate ACKs for the same sequence number imply one segment was lost while later ones arrived, so resend immediately rather than waiting for the timer. Fast retransmit matters because the RTO is deliberately conservative and waiting for it would be very slow.

With plain cumulative ACKs, if you send segments 1–10 and only 3 is lost, the receiver can only report "I have up to 2" — the sender has no idea whether 4–10 arrived, so it may retransmit all seven unnecessarily, on a network that just showed signs of congestion. Selective acknowledgement adds a TCP option listing the ranges actually received ("up to 2, and also 4–10"), so exactly segment 3 is resent. It's the difference between a lossy mobile link being usable and unusable.

Flow control protects the receiver and is explicit — the receiver advertises a window size in every ACK saying how much buffer it has free. Congestion control protects the network and is implicit — nobody tells you the network is busy, you infer it from loss or rising delay. The sender's limit is min(receive window, congestion window). Conflating these two is one of the most commonly marked-down errors in the subject.

Slow start: begin at ~10 segments and double every RTT — "slow" because it starts low, not because it grows slowly. Congestion avoidance: past ssthresh, add one segment per RTT. Fast recovery: three duplicate ACKs mean packets are still flowing, so halve the window and continue linearly. Timeout: silence is a much worse signal, so drop the window to one and restart slow start. That's AIMD, which is provably stable and converges on a fair share between flows.

Loss-based congestion control only backs off when a buffer overflows. Router vendors fitted very large buffers to avoid loss, so TCP now fills hundreds of milliseconds of queue before receiving any congestion signal. Throughput looks fine while latency is destroyed — which is why a large download used to make a video call unusable on the same line. Fixes: active queue management at the router (CoDel, FQ-CoDel) that drops early to signal congestion, and delay-aware senders like BBR. The lesson: "no packet loss" is not the same as "good network".

CUBIC is loss-based: it grows the window as a cubic function of time since the last loss and treats any loss as congestion. BBR instead builds a model — estimating the bottleneck bandwidth and the minimum RTT — and paces sending to match, aiming to keep the pipe full without filling buffers. That makes it much better on links where loss isn't congestion (mobile, Wi-Fi) and avoids bufferbloat. The criticism is that BBR can be aggressive toward loss-based flows sharing a bottleneck.

Throughput ≈ window / RTT = 65,536 B / 0.1 s = 655 KB/s ≈ 5 Mbps — on a 1 Gbps link, so 0.5% utilisation. The BDP is 1 Gbps × 0.1 s = 12.5 MB, so you'd need a 12.5 MB window to fill the pipe, and TCP's 16-bit window field caps at 64 KB. That's why the window scale option exists, shifting the window by up to 14 bits. It's also why a middlebox stripping window scaling produces a transfer that works but is mysteriously slow.

Nagle's algorithm interacting with delayed ACK. Nagle (sender) withholds a small segment until the previous one is acknowledged; delayed ACK (receiver) waits up to ~40–200 ms hoping to piggyback the ACK on a response. So the sender waits for an ACK and the receiver waits for data — a brief deadlock resolved only by the delayed-ACK timer. It shows up when an application writes headers and body in separate send() calls. Fix with TCP_NODELAY, or better, write the whole message in one call.

Four reasons. Transport head-of-line blocking — HTTP/2 multiplexes streams but TCP delivers one ordered byte stream, so one lost packet stalls every stream. Handshake cost — TCP's RTT plus TLS's means 2–3 round trips; QUIC merges them into one. Ossification — TCP lives in kernels and is policed by middleboxes, so changes take a decade; QUIC runs in user space over UDP and is encrypted, so it ships with a browser release. Connection migration — QUIC identifies connections by an ID rather than the four-tuple, so switching from Wi-Fi to mobile doesn't kill them.

0-RTT data is sent before the handshake completes, using keys from a previous session, which makes it replayable — an attacker who captures it can resend it later and the server can't distinguish the replay. So it's only safe for idempotent requests: a GET is fine, a POST that moves money is not. Applications have to explicitly opt in per request. Naming this limitation unprompted is a strong signal.

Caches are checked in order: browser → OS → /etc/hosts → recursive resolver. On a full miss the resolver queries a root server, which refers it to the .com TLD servers; those refer it to the authoritative name server for the domain; that returns the A record. Every step is cached for its TTL. Note the terminology: your query to the resolver is recursive (it does the work for you); the resolver's outward queries are iterative (each returns a referral, not an answer).

Because a CNAME means "this name is an alias for that name, use its records for everything" — and it cannot coexist with other records at the same name. The apex must have SOA and NS records, so a CNAME there would conflict. That's why providers invented non-standard ALIAS/ANAME/flattened records, which resolve the target server-side and return A records at the apex.

It's the trade between agility and load. A 60-second TTL means changes take effect fast but generates far more query volume and more cold-lookup latency. A 24-hour TTL caches efficiently but means you cannot move that server for a day. Standard practice is to lower the TTL to 60 s a day before a planned migration, make the change, verify, then raise it again. And know the limit: some resolvers and browsers ignore short TTLs, so DNS is not a reliable failover mechanism — use anycast or a health-checked load balancer.

HTTP/1.1: one request at a time per connection; pipelining required in-order responses so a slow first response blocked the rest. Browsers worked around it with ~6 connections per origin. HTTP/2: multiplexed streams fix it at the HTTP layer, but TCP still delivers one ordered byte stream, so a single lost packet stalls every stream — under loss HTTP/2 can be worse than HTTP/1.1's six independent connections. HTTP/3: QUIC gives each stream independent loss recovery, so a lost packet only stalls its own stream.

GET, HEAD, PUT, DELETE and OPTIONS are idempotent; POST is not; PATCH depends on the patch semantics ({"status":"shipped"} is, {"count":"+1"} isn't). It matters because idempotent requests are safe to retry automatically — which load balancers, proxies and client libraries do on timeout. A non-idempotent request retried after a lost response can duplicate the effect, which is why POST needs an idempotency key.

The same-origin policy stops a script on one origin reading responses from another, because the browser would attach the user's cookies to that request. CORS is how a server opts in: it returns Access-Control-Allow-Origin, and without it the browser blocks the script from reading the response — note the request was still sent and the server still processed it. Non-simple requests get an OPTIONS preflight first, which adds a round trip unless cached via Access-Control-Max-Age. CORS protects the browser's user, not your server — curl ignores it entirely, so it is never authorisation.

Content-hash the filename (app.4f2a1b.js) and serve it with Cache-Control: max-age=31536000, immutable — cache for a year, never revalidate. Serve the HTML that references it with no-cache so it's always revalidated. A deploy changes the hash, so the URL changes, so cache invalidation never has to happen — the hard problem is designed away. Add ETag for conditional requests and Vary: Accept-Encoding so a CDN doesn't serve brotli to a client that can't decode it.

no-cache is badly named: it means "you may store this, but revalidate with the origin before using it". no-store means "never write this down anywhere" — that's the one for sensitive data like bank statements. Related: private lets the browser cache but forbids shared caches and CDNs, which is what you want for personalised pages.

A server-side session stores state keyed by an opaque ID in a cookie — revocation is immediate (delete the row) but it needs shared storage like Redis. A JWT is self-contained and verifiable by any server with the key, so it scales statelessly, but revocation is hard: it's valid until it expires unless you maintain a denylist, which reintroduces the state you were avoiding. The usual compromise is short-lived access tokens (minutes) plus a stateful refresh token, bounding the revocation window.

HttpOnly — JavaScript can't read it, mitigating token theft via XSS. Secure — only sent over HTTPS. SameSite — controls cross-site sending and is the main structural defence against CSRF: Strict never sends cross-site, Lax (the modern default) sends on top-level GET navigation, None always sends and requires Secure. Plus Domain, Path and expiry to scope it.

If data only flows server→client — notifications, live scores, dashboards, token streaming — SSE is usually better: it's plain HTTP so it works with existing proxies, auth and compression, the browser reconnects automatically, and Last-Event-ID gives resumption for free. Use WebSockets when the client genuinely needs to push too — chat, collaborative editing, games — accepting connection state, no HTTP caching, and proxy configuration. WebSocket starts as an HTTP Upgrade returning 101, then stops being HTTP.

SMTP has no authentication, so all three are retrofits. SPF is a DNS record listing which servers may send for your domain, checked against the envelope sender. DKIM has the sending server sign the message with a private key whose public half is in DNS, proving integrity and authorised signing. DMARC declares what to do when those fail (none/quarantine/reject), requests reports, and crucially requires alignment — the authenticated domain must match the visible From: — which is what actually stops display-name spoofing.

Because each solves the other's problem. Symmetric crypto is fast — hardware accelerated — but can't bootstrap a shared secret over a hostile network. Asymmetric crypto solves key distribution and authentication but is roughly a thousand times slower, far too slow for bulk data. So TLS is hybrid: asymmetric operations once during the handshake to authenticate the server and agree a session key, then symmetric encryption for all the actual traffic. The expensive part is paid per connection, not per byte.

ClientHello carries the version, cipher suites, a random, the SNI hostname in the clear, and — the 1.3 trick — a guessed Diffie-Hellman key share. ServerHello returns the chosen cipher, its own key share, then (already encrypted) the certificate chain, a signature over the transcript, and Finished. The client verifies the chain to a trusted root, checks the hostname, dates and revocation, derives the same session keys from both key shares, and sends Finished plus application data. One round trip, versus two in TLS 1.2.

With old RSA key exchange the client encrypted the session key to the server's public key, so an attacker who recorded years of traffic and later stole the private key could decrypt all of it retroactively. With ephemeral Diffie-Hellman a fresh key pair is generated per session and discarded; the certificate key only signs the exchange. Stealing it tomorrow lets you impersonate the server going forward but decrypts nothing recorded in the past. TLS 1.3 removed static RSA key exchange entirely, so every session has it.

Not just the signature. It verifies the chain links up to a root in its trust store; that the hostname matches a SAN entry (CN alone is deprecated); that the current time is within the validity period — which is why clock skew breaks HTTPS; that it isn't revoked (in practice via OCSP stapling, since live OCSP was slow and leaked browsing history); and that the signature algorithms are still acceptable. Missing any one of these is a distinct real-world failure mode.

No. The SNI hostname is sent in the clear so one IP can host many sites, so an observer learns which site you visited. The destination IP is visible by definition. DNS lookups are plaintext unless you use DoT/DoH. And traffic size and timing leak information — you can often fingerprint which page was loaded. Encrypted Client Hello is the deployment fix for SNI. The content and headers are protected, which is the important part, but "encrypted" isn't "invisible".

The attacker sends SYNs with spoofed source addresses and never completes the handshake. Each half-open connection occupies a slot in the backlog queue, and once it's full legitimate clients can't connect — cheap for the attacker because they never have to receive anything. The fix is SYN cookies: encode the connection state into the initial sequence number itself, so the server allocates no memory until the final ACK returns and proves the client actually received the SYN-ACK. Plus backlog tuning and rate limiting.

Send a small query with a spoofed source address to a service whose replies are much larger — DNS, NTP, memcached — so the large response floods the victim. A 60-byte request can produce a 4,000-byte reply, roughly 70× amplification, and the attacker's bandwidth is multiplied accordingly. The root cause is that IP source addresses were never authenticated. The real fix is BCP 38 ingress filtering at ISPs so spoofed sources can't leave a network, plus not running open resolvers and rate-limiting responses.

No. It happens to block unsolicited inbound traffic as a side effect of having no translation entry for it, but it enforces no policy, inspects nothing, and once a mapping exists traffic flows freely. It also does nothing about outbound threats or anything inside the network. Treating NAT as security is a common and marked-down mistake — and it's why IPv6 removing the need for NAT is not a security regression, provided you actually run a stateful firewall.

An encrypted tunnel so traffic crosses an untrusted network as if it were on a trusted one — genuinely useful for remote access to a private network and for site-to-site links. Two clarifications worth volunteering: a commercial "privacy VPN" doesn't provide anonymity, it moves the trust from your ISP to the VPN provider, who sees everything your ISP would. And it adds nothing to traffic that's already end-to-end encrypted — HTTPS is encrypted before the tunnel receives it.

ICMP echo is being filtered. Many networks, cloud security groups and hosts block ICMP by default, so ping failing proves only that ICMP echo isn't getting through — not that the host is down or unreachable. Test the actual service instead: curl it, or nc -zv host 443. This is also why traceroute shows * * * for some hops while traffic passes through them perfectly well.