Overview

Each descending layer wraps the payload it receives from the layer above in a new header (and sometimes a trailer) carrying that layer's own addressing/control information, then hands the whole thing to the layer below. At the receiver, each ascending layer strips off exactly one header, uses it to decide how to interpret and hand off the remaining payload, and passes what's left up to the layer above -- OSI's 7 layers and TCP/IP's 4 layers describe the same underlying concerns, just split at different granularity.

Frames are addressed by MAC address, not IP address -- the link layer has no idea what an IP address is. ARP resolves an IP address to its MAC address (by broadcasting a request on the local segment and caching the unicast reply) before a frame carrying that IP packet can actually be put on the wire.

IPv4 is a 32-bit address written as four dotted decimal octets (~4.3 billion addresses total); IPv6 is a 128-bit address written as eight colon-separated hextets. :: compresses exactly ONE contiguous run of all-zero hextets to keep addresses readable -- using it twice in the same address would make the expansion ambiguous, so it's forbidden.

2**(32-27) = 32 raw addresses, of which 30 are usable. The first address in the block is reserved as the network address (identifies the subnet itself) and the last is reserved as the broadcast address (targets every host on the subnet) -- neither can be assigned to an individual host.

A default route (0.0.0.0/0) matches every possible destination. Routers apply longest-prefix-match first among ALL routes that match a destination, so any more specific route always wins over the default -- the default route is deliberately the least specific possible match, used only when nothing more specific applies.

It rewrites the packet's source IP (and usually source port) to its own public IP and a chosen public port. To handle the reply, it keeps a translation-table entry mapping (private IP, private port) to (public IP, public port) so an inbound reply to that public IP/port gets rewritten back to the correct private destination.

Handshake: SYN, SYN-ACK, ACK. Teardown: FIN, ACK, FIN, ACK (or an abrupt RST). The side that sends the FINAL ACK of the teardown enters TIME_WAIT, waiting 2 * MSL to guarantee any duplicate, delayed segment from this now-closed connection expires in the network before the same 4-tuple could be reused by a new connection.

It advertises how many unacknowledged bytes the receiver is currently willing to buffer. A sender that ignores it and keeps sending anyway risks the receiver dropping the excess -- the window exists specifically so a fast sender cannot overrun a slower receiver's buffer.

Reaching ssthresh (or a detected loss event) ends slow start. After that, congestion avoidance grows the congestion window roughly linearly (additive increase) instead of exponentially -- a much more cautious probe of remaining network capacity.

Nagle's algorithm withholds a small unacknowledged write, hoping to coalesce it with more data before sending. Delayed ACK withholds the corresponding ACK for the same reason. If each side is waiting on the other, nothing moves until delayed ACK's own timer finally fires -- two locally sensible optimizations deadlocking each other at the interaction boundary.

TCP_NODELAY disables Nagle's algorithm on that socket, so small writes go out immediately instead of waiting to coalesce. A nonblocking recv() returns immediately (typically with an EWOULDBLOCK/BlockingIOError) if no data is ready, instead of blocking the calling thread -- requiring the caller to poll (e.g. via select()) for readiness.

Root server -> TLD server (e.g. the .com servers) -> the domain's authoritative nameserver, with each intermediate step returning a REFERRAL (not the final answer) pointing to the next server down the chain, until the authoritative server answers directly. Any lookup within the answer's TTL after that is served straight from cache, skipping the whole walk.

An RRSIG is a cryptographic signature over a record set, verifiable using the zone's own DNSKEY. A DS record published in the PARENT zone attests to the child zone's DNSKEY, chaining trust upward zone by zone until it reaches the root zone's built-in, out-of-band trust anchor.

TLS 1.3's client sends its key-share GUESSES in the very first flight (the ClientHello) instead of waiting to first learn which group the server prefers. The server can then derive the shared secret and reply with its own key share, encrypted certificate, and Finished message in a single round trip -- and a resumed session using a PSK can send application data even earlier (0-RTT).

HTTP/1.1 pipelining still delivers responses in strict request order (head-of-line blocking at the framing level) even when sent over one connection. HTTP/2 interleaves independent STREAMS' frames on one TCP connection, so a slow response no longer blocks delivery of a faster response queued behind it.

HTTP/2 multiplexes many streams over ONE TCP connection's single ordered byte stream, so one lost TCP segment stalls delivery of EVERY stream until it's retransmitted. QUIC runs loss recovery independently per stream over UDP, so a lost packet only stalls the one stream it belonged to -- QUIC also lets a connection migrate across a network change via a stable connection ID, instead of requiring a brand-new handshake.

A WebSocket connection is full-duplex -- after the upgrade, either side can send at any time. Server- Sent Events are one-way, server-to-client only, delivered over one ordinary, long-lived HTTP response (text/event-stream) -- there's no channel back to the server on that same connection at all.

WebTransport exposes QUIC's own multiplexed streams and datagrams directly to the browser -- still a client-to-server QUIC/UDP connection under the hood. WebRTC instead negotiates (via a signaling channel plus ICE/STUN/TURN) a DIRECT peer-to-peer path between two browsers, only falling back to a relay (TURN) when a direct path can't be established.

An L4 load balancer only sees transport-level identifiers (source/destination IP and port) with no visibility into application content. An L7 load balancer terminates (or inspects) the application layer, so it can route decisions on HTTP path, header, or cookie value -- content an L4 balancer never sees at all.

A CDN IS a distributed reverse proxy -- many geographically distributed reverse-proxy caches sitting between clients and one (or a few) origin servers, each individually capable of serving a cached response entirely without contacting the origin.

An entirely separate copy of the network stack -- its own interfaces (even its own loopback), its own routing table, and its own firewall rules -- invisible to and independent from every other namespace on the same kernel. Container runtimes give each container its own network namespace for exactly this isolation; ip netns exposes the same primitive directly.

Protocol (tcp/udp/icmp), specific TCP flag bits (e.g. tcp[13] & 2 != 0 isolates SYN packets), packet direction (src/dst), and arbitrary byte offsets and bitmasks within a packet's own header fields -- BPF is a small expression language, not just a host/port matcher.

An average can be pulled down by a large volume of fast requests while completely hiding a long, painful tail -- and it can even improve while the actual painful behavior stays exactly the same or worsens. p95/p99 percentiles, plus jitter (the run-to-run variation between consecutive measurements), actually reflect what the worst commonly-experienced requests feel like.

It matches the packet against a connection-tracking table entry created when the ORIGINAL outbound packet was permitted -- a reply belonging to an already-established, permitted connection is allowed through automatically, with no separate inbound rule required for it.

Split tunneling routes only specific subnets through the VPN, leaving everything else on the normal default route. Full tunneling routes ALL traffic (0.0.0.0/0) through the VPN, which needs extra routing-table and firewall-rule plumbing so the tunnel's own traffic (to the VPN server's real endpoint) doesn't get routed back into itself.

It's simultaneously a crypto-routing rule (only a packet whose SOURCE matches AllowedIPs is accepted as genuinely coming from that peer) and a routing-table entry (an outbound packet to that DESTINATION gets encrypted and sent to that peer) -- one line does both the authentication-boundary job and the routing job.

WireGuard fixes ONE modern cryptographic suite with no negotiation and a minimal config surface, dramatically shrinking both the audit surface and the attack surface at the cost of configurability. IPsec/IKE supports many negotiable cipher suites and modes for broad, decades-long interoperability, at the cost of a much larger, harder-to-audit codebase.

A NAT gateway's translation-table entry for that flow has an idle timeout. Without periodic traffic, the mapping expires and the gateway silently stops forwarding return traffic to that peer -- breaking the tunnel until a fresh outbound packet re-creates the mapping (often on a different public port).

Tailscale (and self-hosted Headscale) use a central coordination server that exchanges public keys and current endpoint info between nodes, and can relay traffic (DERP) when a direct path fails. Nebula instead uses signed host certificates plus one or more "lighthouse" nodes that only help peers discover each other's current IP -- trust is rooted in a certificate authority rather than in an always-available coordination service.

Nagle's algorithm and delayed ACK interacting (co-10) -- each small write waits hoping to coalesce with more data, and each side's delayed ACK is waiting on the other, so nothing moves until delayed ACK's own timer fires. The fix is setting TCP_NODELAY (co-11) on the upload socket so small writes go out immediately.

A broken DNSSEC chain of trust (co-13) -- the new DNSKEY was rotated in the zone, but the corresponding DS record in the parent zone wasn't updated to match. A validating resolver's signature check fails and it returns SERVFAIL; a non-validating resolver skips DNSSEC verification entirely and keeps answering normally, which is exactly why the internal resolver hides the problem.

An ARP resolution failure (co-02) -- most likely because the two hosts are actually on different broadcast domains (e.g. different VLANs) despite having addresses that LOOK like the same subnet. Host A's ARP broadcast never reaches host B, so no MAC address is ever learned, and no frame can be addressed to it.

The video call is almost certainly running over QUIC (co-16), whose connection ID lets it survive a network/IP change via connection migration with no new handshake. The file transfer is plain TCP, whose connection is identified by the 4-tuple (including source IP) -- the IP change makes every in-flight packet look like it belongs to a connection that no longer exists.

An idle NAT/firewall connection-tracking timeout (co-06, co-28) -- if the connection sits idle longer than the NAT gateway's or firewall's translation-table timeout, the entry is evicted, and a later packet on that "dead" mapping gets reset or silently dropped. The fix is enabling TCP keepalive (or an application-level ping) that fires more often than the idle timeout.

They need an L4 load balancer (co-19), not their existing L7 one -- L7 routing decisions depend on application content (HTTP headers/paths) that simply doesn't exist in a raw, non-HTTP TCP stream. L4 routes purely on IP/port and has no such dependency.

The CDN's edge cache (co-20) is still serving a cached copy of the old response until its TTL expires -- the origin being fixed doesn't retroactively invalidate what's already cached at the edge. The fix is either a cache purge/invalidation on deploy, or a shorter TTL for content that changes on deploy.

Capture live traffic with a BPF filter (co-22) isolating just SYN packets destined for the supposedly restricted port (tcp[13] & 2 != 0 and dst port N), and confirm the actual observed sources match the intended policy -- verifying the stateful firewall's (co-24) real, live behavior instead of only reading the config that's supposed to produce it.

p50 hides exactly the tail the complaints are about (co-23) -- check p95/p99 and jitter instead. A low median with a heavy or highly variable tail is precisely what a human perceives as "laggy," even while the median-based dashboard looks fine.

A full-tunnel AllowedIPs = 0.0.0.0/0 (co-25, co-26) is routing ALL traffic -- including completely unrelated internet traffic -- through the tunnel and out through the office's own internet connection. The fix is switching to split tunneling, limiting AllowedIPs to only the internal subnets that actually need to traverse the VPN.

A cross-site WebSocket hijacking risk (co-17) -- unlike fetch/XHR, browsers don't enforce same-origin restrictions on WebSocket connections by default, so any page from any origin can open a WebSocket to this server and the server has no way to distinguish a legitimate client from an attacker's page unless it explicitly validates the Origin header itself.

SSE (co-17) is the right, simpler fit -- the feature's actual data-flow need is purely one-way, and SSE runs over plain HTTP infrastructure with automatic reconnection built in. A WebSocket's full-duplex capability would sit entirely unused, adding complexity (a separate upgrade protocol, a different proxy/load-balancer configuration story) with no corresponding benefit for this feature.

Plain WireGuard (co-26) requires each [Peer] entry to reference a KNOWN endpoint -- it has no concept of dynamic peer discovery, key distribution, or NAT-traversal coordination built in. At the scale of hundreds of dynamically-NATed devices, that manual-config model doesn't scale; a mesh overlay platform (co-29) adds exactly the coordination-plane layer (automatic key exchange, live endpoint discovery, relay fallback) that plain WireGuard deliberately leaves out.

Mutual TLS (co-24) -- ordinary TLS only proves the SERVER's identity to the client. mTLS additionally requires the CLIENT to present its own certificate, which the server verifies before accepting the connection, which is exactly what "prove your own identity via certificate, not via network location alone" requires.

The exact trade-off co-27 names explicitly -- IPsec's broad configurability (many negotiable cipher suites and IKE modes) is precisely what creates cross-vendor interoperability gaps, since two implementations can each be "spec-compliant" while still failing to agree on a common negotiated mode. A fixed-suite protocol like WireGuard trades that same flexibility away specifically to avoid this class of problem -- a real, common reason teams choose it over IPsec despite IPsec's longer pedigree.

Each optimization is locally sound on its own side of the connection -- Nagle reduces the sender's small-packet overhead, delayed ACK reduces the receiver's ACK-traffic overhead. Neither is a bug in isolation. The stall is a layering-and-leaks instance: a behavior that's invisible and reasonable within one side's own logic leaks into a user-visible pathology only once you look at the INTERACTION across the send/receive boundary, which is exactly why the fix (TCP_NODELAY) targets the interaction, not either side's individual logic.

Both need to remember a prior packet of a flow to correctly treat a LATER packet -- NAT needs it to translate a reply's destination address back correctly; a stateful firewall needs it to decide a reply is allowed through without a separate inbound rule. The same state-table pattern, invented to solve one problem, turns out to be the exact mechanism another problem also needs -- a layering-and-leaks case where a technique's structure outlives the specific problem it was first built for.

TCP's ordering guarantee applies to the ONE underlying byte stream, not to each application-level HTTP/2 stream individually. HTTP/2's multiplexing is a layer ABOVE TCP, interleaving multiple logical streams onto that single ordered byte stream -- so one lost TCP segment still blocks delivery of EVERYTHING behind it in that byte stream, regardless of which HTTP/2 stream the data belonged to. QUIC (co-16) fixes this specifically by moving stream-level loss recovery DOWN into the transport itself, where each stream's ordering is genuinely independent.

"Route everything through the tunnel" creates a bootstrapping problem: the tunnel's OWN traffic (to the VPN server's real, outside-the-tunnel endpoint) must NOT itself be routed back into the tunnel, or the connection recurses into itself and never actually reaches the server. A plain routing table can't express that one specific exception cleanly on its own, so policy routing (a separate routing table) plus a firewall mark (to tag the tunnel's own packets for the exception) is needed to carve that traffic out of the "route everything" rule -- a consistency-latency-throughput cost paid for the convenience of "everything just goes through the tunnel."

An average can move in the OPPOSITE direction of the actual painful behavior -- adding a large volume of fast, cheap requests lowers the average even while the slow tail that's causing complaints stays exactly the same or worsens. That's not merely imprecise, it's actively misleading: a dashboard that looks like it's improving while the thing users are complaining about hasn't changed at all. p95/p99 plus jitter (co-23) are needed because they specifically describe the tail, which is the part of the distribution average latency structurally cannot see.

Both were redesigned specifically to collapse the number of round trips their predecessor needed before useful data could flow -- TLS 1.2's 2-RTT became TLS 1.3's 1-RTT (or 0-RTT on resumption); the combined TCP-plus-TLS handshake latency HTTP/2 still pays became QUIC's integrated single handshake. The shared lesson, a consistency-latency-throughput insight: on most real-world links, ROUND TRIPS dominate perceived latency far more than raw bandwidth does, so both protocols attack the same bottleneck by restructuring WHEN cryptographic material is exchanged relative to the handshake's first flight.

WireGuard's own protocol has no concept of peer discovery, key distribution, or NAT-traversal coordination at all -- every [Peer] entry is manually configured with a known endpoint by design. A mesh overlay adds an entire coordination plane (or, for Nebula, a certificate-based PKI plus lighthouse nodes) that WireGuard deliberately leaves out of scope. The mesh layer solves a genuinely different problem -- dynamic peer discovery at scale -- than WireGuard's own minimal, static-config design goal, which is exactly why Tailscale and Nebula still exist as separate projects layered on top of (or alongside) a WireGuard-style data plane rather than being folded into WireGuard itself.

IPsec's configurability -- many negotiable cipher suites and IKE modes -- is precisely what let it interoperate across decades of vendor equipment and evolving cryptographic recommendations without a full protocol rewrite. WireGuard's fixed, unnegotiated modern cryptographic suite achieves a dramatically smaller audit and attack surface specifically BY giving up that same negotiability. It's a genuine consistency-latency-throughput-style trade, not a strict improvement -- less configurability in exchange for a codebase small enough to actually audit line by line.

To inspect HTTP path, header, or cookie content for a routing decision, an L7 load balancer must first decrypt TLS -- there is no way to read encrypted application content without terminating the encryption first. That necessarily means the load balancer sees plaintext application traffic and must re-encrypt (or forward in the clear) to the backend, expanding the trust boundary and the number of places sensitive data exists unencrypted. An L4 load balancer, blind to application content by construction, structurally cannot become that kind of trust boundary at all -- the extra routing power and the extra trust exposure are the same trade-off, not two separate design choices.

Calling it a heartbeat implies an application-level liveness check -- but its actual job is narrower and purely infrastructural: it exists ONLY to keep a NAT or firewall's translation-table entry from expiring due to idle timeout, is completely invisible to the application layer, and (as this topic's own live capture showed) does not even reset WireGuard's own handshake state the way a fresh handshake would -- the byte counters increment while the handshake timestamp stays fixed. Conflating it with an application heartbeat misses that it's solving the exact same co-06/co-24-style connection-tracking state-table problem this topic keeps returning to, not a liveness problem at all.