Computer Networks Interview Questions (2026): Most Commonly Asked, With Answers

Physical, Data Link, Network, Transport, Session, Presentation, and Application, from the bottom up. A common way to keep the order straight is the mnemonic "Please Do Not Throw Sausage Pizza Away." Physical deals with raw bits over a wire or radio signal, Data Link handles framing and MAC addresses on a single segment, Network handles IP addressing and routing between segments, Transport handles TCP or UDP delivery, and the top three (Session, Presentation, Application) cover connection management, data formatting, and the actual application protocol.

TCP is connection-oriented: it opens a session with a handshake, guarantees ordered delivery, retransmits lost segments, and runs flow and congestion control on top of all of that. UDP is connectionless: fire a datagram and it's gone, no handshake, no delivery guarantee, no ordering, and a fraction of TCP's header overhead (8 bytes against TCP's 20-plus).

The client sends a SYN segment carrying an initial sequence number. The server replies with SYN-ACK, acknowledging the client's sequence number and sending its own. The client replies with ACK, acknowledging the server's sequence number, and the connection is now established (RFC 9293, the current TCP specification). Three segments, two round trips, before either side sends a single byte of actual data.

HTTPS is HTTP running inside a TLS-encrypted tunnel. The request and response format doesn't change at all, only what's wrapped around it. HTTP defaults to port 80 and sends everything, headers, cookies, body, in plaintext. HTTPS defaults to port 443, and before a single HTTP byte moves, the client and server run a TLS handshake: negotiate a cipher suite, the server presents a certificate the client validates against a trusted certificate authority, and both sides derive a shared symmetric session key that everything after gets encrypted with.

(Side note: 443 has no cryptographic property of its own, it's just a well-known port. Plenty of internal services run TLS on completely different ports and nothing breaks.)

1xx is informational (100 Continue, rarely seen directly). 2xx is success (200 OK, 201 Created after a POST). 3xx is redirection (301 for a permanent move, 302 for a temporary one, 304 Not Modified when a cached copy is still valid). 4xx is a client error (404 Not Found, 401 Unauthenticated, 403 Forbidden, which people mix up constantly). 5xx is a server error (500 for something unhandled, 503 when the server's up but can't serve the request right now, often on purpose during a deploy).

The resolver, usually your OS or a configured server like 1.1.1.1, checks its own cache first. Nothing cached, it asks a root server which TLD server handles.com. It asks that TLD server which authoritative name server handles the specific domain. It asks that authoritative server for the actual record, gets back an IP address, caches it for the length of the TTL, and hands the answer back to whatever asked in the first place. Four hops in the worst case, zero in the best case, when the answer's already sitting in a cache somewhere along the chain.

IPv4 uses 32-bit addresses, so 2^32, 4,294,967,296 addresses total. That sounded enormous in 1981 when the spec shipped. It wasn't, once every phone, router, and IoT device needed one, and the global free pool ran dry back on February 3, 2011. IPv6 uses 128-bit addresses instead, roughly 340 undecillion of them, a number large enough that address scarcity stops being a design constraint at all.

A switch operates at Layer 2, forwarding frames within a single network based on MAC addresses, building its forwarding table by watching which MAC address showed up on which port. A router operates at Layer 3, forwarding packets between different networks based on IP addresses, using a routing table instead of a MAC table. Put plainly: a switch connects devices on the same network, a router connects different networks to each other.

Because an IP address only gets you to Layer 3, and actually delivering a frame on a local Ethernet segment needs a Layer 2 MAC address, which IP knows nothing about. ARP broadcasts "who has this IP?" to every device on the local segment; whoever owns it replies directly with its MAC address, and that mapping gets cached locally so the broadcast doesn't need to repeat for every single packet.

22 for SSH, 25 for SMTP, 53 for DNS, 80 for HTTP, 443 for HTTPS, 123 for NTP, and 143 for IMAP. On the database side: 3306 for MySQL, 5432 for PostgreSQL, and 6379 for Redis. Anything below 1024 is a "well-known" port reserved for standard services; ports above that are either registered for a specific application or handed out dynamically as ephemeral source ports for outbound connections.

A socket is the OS-level endpoint an application binds to when it wants to send or receive data over a network. Internally, it's just a file descriptor the kernel maps to a chunk of connection state, source and destination addresses, ports, and a protocol.

Uniquely identifying one TCP connection requires five values together: source IP, source port, destination IP, destination port, and protocol. That's why a server listening on port 443 can serve thousands of clients on that same port at once, each client's connection is a distinct tuple because the source IP and source port differ, even though the destination stays fixed. Change any one of those five values and you have a different socket, even if everything else matches.

Bandwidth is the theoretical maximum capacity of a link, the number that gets advertised, like a 1 Gbps connection. Throughput is what you actually measure moving real traffic across that link, and it's always less than or equal to bandwidth because of protocol overhead, congestion, retransmissions, and other traffic sharing the path. Latency is a separate thing entirely, it's the time a single bit takes to travel from sender to receiver, usually measured round trip in milliseconds.

A common trap is assuming more bandwidth fixes a slow-feeling application. If the real problem is 200ms round-trip latency to a server on the other side of the planet, upgrading from 100 Mbps to 10 Gbps changes nothing, because you're not saturating the pipe, you're waiting on distance and router hops. Video calls suffer from latency and jitter far more than bandwidth, while file downloads mostly care about throughput.

Unicast is one sender to one specific receiver, this is basically all normal web traffic. Broadcast is one sender to every device on the local network segment, using a destination like 255.255.255.255 or the subnet's broadcast address, DHCP discovery and ARP requests use this because the sender doesn't yet know exactly who to talk to.

Multicast sits in between, one sender to a group of interested receivers that opted in, using addresses in the 224.0.0.0 to 239.255.255.255 range for IPv4. IPTV and market data feeds use multicast so the source doesn't need a separate copy of the stream per viewer. In practice broadcast doesn't cross routers by default, and multicast needs the switches in between to support IGMP snooping, which is why enterprise multicast video setups often break the moment someone plugs in a switch that doesn't support it.

A MAC address is a 48-bit identifier assigned to a network interface, written as six hex pairs like 00:1B:44:11:3A:B7. The first three bytes are the OUI, assigned by IEEE to the manufacturer, so the prefix alone can usually tell you who made the card. A MAC address only matters on the local network segment, it's how frames get delivered at layer 2 between devices on the same LAN or Wi-Fi network.

An IP address is layer 3, it's how packets get routed across different networks to reach a destination anywhere on the internet, and unlike a MAC address it can change, get reassigned by DHCP, or get rewritten by NAT. The relationship between the two is exactly what ARP resolves, given an IP address on your local subnet, ARP finds the MAC address that packet actually needs to be delivered to at the hardware level.

Ping uses ICMP, specifically an Echo Request sent to the target, which replies with an Echo Reply if it's reachable and isn't blocking ICMP. It isn't TCP or UDP at all, ICMP sits directly on top of IP as its own protocol, which is exactly why ping can succeed while an actual application on that host stays completely unreachable, a firewall might allow ICMP through while blocking the TCP port your application uses.

What ping actually tests is basic layer 3 reachability and round-trip time, nothing about the application layer. A "ping works but the site doesn't load" report almost always means routing and connectivity are fine, and the real problem is a firewall rule, a service that's down, or DNS pointing somewhere that ICMP happens to still reach.

TCP/IP compresses OSI's top three layers (Session, Presentation, Application) into a single Application layer, keeps Transport and Network as they are, and merges Physical and Data Link into one Network Access layer. Four layers instead of seven. Real protocol stacks line up with TCP/IP far more closely, since nothing in production actually implements Session and Presentation as separate, addressable layers. Wireshark's protocol tree groups packets the TCP/IP way too, for what that's worth.

Because guaranteed delivery isn't free, it costs latency, and for some traffic a late packet is worse than a lost one. A video call frame that arrives 400ms late is useless, you'd rather drop it and move on than wait for TCP to retransmit and reorder it. DNS queries default to UDP too, mostly because a single small request-response round trip doesn't need connection setup overhead at all (DNS falls back to TCP only when a response outgrows one UDP datagram).

Because a TCP connection is full-duplex, and closing one direction doesn't automatically close the other. Side A sends FIN, meaning "I'm done sending." Side B ACKs it but might still have data left to send, so it keeps going until it's ready, then sends its own FIN. Side A ACKs that, and only then is the connection fully closed in both directions. The handshake can collapse SYN-ACK into one segment because both sides are just opening together; teardown usually can't, because one side finishing has nothing to do with whether the other side is finished too.

401 means the server doesn't know who you are, or doesn't trust the credentials you sent, so it's asking you to authenticate. 403 means the server knows exactly who you are and is refusing anyway, because you're authenticated but not authorized for that specific resource. People mix them up because most APIs return 401 for both cases out of an abundance of caution, so nobody sees a genuine 403 often enough in the wild to build the reflex for it.

A maps a name to an IPv4 address, AAAA maps a name to an IPv6 address, CNAME aliases one name to another name rather than directly to an IP, MX points at the mail servers responsible for a domain, NS delegates a zone to its authoritative name servers, and TXT holds arbitrary text, which today mostly means domain verification and SPF or DKIM email authentication rather than anything resembling its original loose purpose.

The /24 is CIDR notation for a subnet mask, here 255.255.255.0, meaning the first 24 bits identify the network and the remaining 8 bits identify hosts within it. 2^8 gives 256 total addresses, but you lose two: the first address (.0) is the network address itself, and the last (.255) is the broadcast address, neither assignable to a host. So 254 usable addresses on a /24.

Public addresses are globally unique and routable across the open internet. Private addresses (RFC 1918 reserves 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16) aren't routed on the public internet at all, and routers are supposed to drop packets addressed to them if they ever leak out. Yes, two unrelated companies can both run 192.168.1.0/24 internally with zero conflict, because those addresses only mean something inside each company's own network. That's also exactly why NAT exists, to translate those private addresses into a shared public one at the network edge.

Longest prefix match, almost always. If a packet's destination matches both a /24 route and a /16 route in the table, the router picks the /24, the more specific match, over the broader one, regardless of which route got added first or which one has a "better" metric on paper. Only when two routes tie on prefix length does the router fall back to metric, administrative distance, or whatever tiebreaker the specific routing protocol defines.

Discover: the client, with no IP address yet, broadcasts a request for one. Offer: a DHCP server on the segment replies with a proposed IP address, subnet mask, gateway, and DNS servers. Request: the client broadcasts back that it's accepting that specific offer, which also tells any other DHCP server on the segment its offer wasn't chosen. Acknowledge: the server confirms and the lease timer starts. Four steps, and it's broadcast-heavy by design, because the client has no IP address of its own until step four finishes.

Flow control protects the receiver: it's the receiver telling the sender, through the advertised window size in every TCP segment, exactly how much unacknowledged data it's willing to buffer right now, so a fast sender can't overwhelm a slow receiver. Congestion control protects the network path as a whole, everything between the two endpoints, using algorithms like slow start and congestion avoidance (Cubic is Linux's default; Google's BBR takes a different approach based on measured bandwidth and round-trip time rather than reacting to packet loss) to estimate how much that path can actually carry before something in the middle starts dropping packets.

DNS resolution, most likely, since that A record is probably still inside its TTL and sitting in the OS cache. If the browser kept the TCP connection alive, keep-alive on HTTP/1.1, or a multiplexed HTTP/2 connection that never fully closed, the handshake and TLS negotiation get skipped too, and the second request just reuses the existing encrypted connection. What almost never gets skipped is the HTTP request-response cycle itself, unless the specific resource is cacheable and the browser's local cache still considers its copy fresh, which is a separate question from whether the connection underneath it is fresh.

A forward proxy sits in front of clients and represents them to the outside world. The classic example is a corporate proxy that all employee traffic routes through before hitting the internet, so from the destination server's point of view, every request looks like it came from the proxy. Clients are configured to know about the forward proxy; servers on the other end usually have no idea a proxy is involved.

A reverse proxy sits in front of servers instead, and clients think they're talking directly to the actual service, with no visibility into whether nginx or a load balancer is intercepting the request and routing it to one of several backend instances. Reverse proxies are what make load balancing, TLS termination, caching, and hiding internal architecture possible, a client hitting api.example.com has no idea whether that request landed on server 3 or server 47. The direction of who's being hidden from whom is really the whole distinction.

A stateless firewall evaluates each packet in isolation against a fixed rule set, checking things like source IP, destination IP, port, and protocol, with no memory of what packets came before it. That means you have to write rules for both directions of every connection explicitly, allow outbound on port 443 and separately allow the matching return traffic, which is messy and easy to misconfigure into either blocking legitimate traffic or leaving a hole open.

A stateful firewall tracks connections in a state table, so once it sees an outbound SYN establishing a connection, it automatically allows the matching return traffic without a separate rule, and it can tell a spoofed or out-of-sequence packet apart from one that actually belongs to an established session. The cost is that stateful firewalls consume memory and CPU proportional to the number of concurrent connections, which is exactly the vector SYN flood attacks target, flooding the state table with half-open connections until legitimate ones can no longer get tracked.

MTU is the largest packet size a given link can carry without fragmenting, most Ethernet networks default to 1500 bytes. When a packet is larger than the MTU of a link it needs to cross, IPv4 either fragments it into smaller pieces reassembled at the destination, or, if the Don't Fragment bit is set, the router drops it and sends back an ICMP "fragmentation needed" message instead.

This becomes a real production issue with tunneling and VPNs, since encapsulating a packet inside another protocol like IPsec or GRE adds header overhead, which can push an already-1500-byte packet over the tunnel's effective MTU. The classic symptom is small requests working fine while anything with a larger payload silently hangs, because the ICMP "fragmentation needed" message got dropped somewhere along the path by an overly strict firewall, so the sender never learns it needs to shrink its packets. This is the black hole problem behind most "works on ping, breaks on real traffic" VPN tickets.

The client sends a ClientHello listing the TLS versions and cipher suites it supports along with a random value. The server responds with a ServerHello picking one cipher suite and version from that list, sends its certificate chain so the client can verify identity against a trusted CA, and either sends its own key share directly or waits for the client to encrypt a pre-master secret with the server's public key, depending on the key exchange method.

With TLS 1.3 this collapsed to effectively one round trip, the server can send its certificate and finish message right after the ClientHello, versus TLS 1.2's typical two round trips before any application data flows. Once both sides derive a shared master secret independently, without ever sending it over the wire, they switch to symmetric encryption, since asymmetric crypto is too slow for bulk data. The certificate step is what actually establishes trust, the cryptography protects data in transit, but proving you're talking to the right server at all is the certificate chain's job.

A site-to-site VPN connects two networks permanently, like linking an office network to a cloud VPC, so every device on either side can reach the other transparently, with the tunnel established once between two gateway devices. A client VPN connects a single device to a remote network, this is what remote employees run to reach internal resources, and it needs client software or an OS-native VPN configuration on every device that connects.

IPsec operates at layer 3 and encrypts IP packets directly, which is why most site-to-site VPNs use it, it's fast and doesn't care what's inside the packet. SSL/TLS-based VPNs like OpenVPN or a corporate SSL VPN portal tunnel traffic over a TLS connection instead, slower per packet but much friendlier to firewalls and NAT since it just looks like HTTPS traffic on port 443, whereas IPsec often needs specific ports and protocols opened that get blocked on restrictive networks like hotel Wi-Fi.

A layer 4 load balancer makes routing decisions using only IP address and port, it never looks inside the payload, so it can't tell an HTTP request for /api/users apart from one for /images/logo.png, it just forwards TCP or UDP traffic to a backend based on a simple algorithm. That makes it extremely fast and low overhead, but limited, no routing on URL path, headers, or cookies.

A layer 7 load balancer terminates the connection, actually reads the HTTP request, and makes smarter decisions, routing /api to one backend fleet and /static to another, doing sticky sessions off a cookie, or rewriting headers on the way through. The cost is more CPU per request from TLS termination and HTTP parsing, and it adds a hop where the backend sees the load balancer's IP instead of the real client's, which is why X-Forwarded-For headers exist to recover the original client IP for logging and rate limiting.

A VLAN lets you carve a single physical switch, or a set of switches, into multiple logically separate broadcast domains, even though devices plug into the same physical hardware. Without VLANs, every device on a switch shares one broadcast domain, so ARP requests and DHCP discovers from any device reach every other device, which doesn't scale and isn't secure when you want guest Wi-Fi and finance department servers on the same physical stack but fully isolated from each other.

Trunk ports carry traffic for multiple VLANs over a single physical link between switches, tagging each frame with an 802.1Q header identifying which VLAN it belongs to, while access ports connect to end devices and only carry one VLAN's untagged traffic. Segmenting this way limits the blast radius of both broadcast storms and security incidents, a compromised device on the guest VLAN simply cannot ARP-scan or reach anything on the servers VLAN unless a router or firewall explicitly permits routing between them.

CORS preflight is the browser's way of asking a server's permission before sending a risky cross-origin request, one using a method other than GET, POST, or HEAD, setting custom headers, or a Content-Type outside a small safe list. Before sending the real request, the browser fires an OPTIONS request with Access-Control-Request-Method and Access-Control-Request-Headers set, and the server has to respond with matching Access-Control-Allow-Origin, Access-Control-Allow-Methods, and Access-Control-Allow-Headers before the browser lets the actual request through.

This entirely happens client-side in the browser, it isn't a network-level security control and does nothing to stop a server-to-server request or a curl call, it exists purely to stop a malicious site's JavaScript from silently making authenticated requests to a different site on a logged-in user's behalf. A lot of developers get bitten by preflight failures because they forget it's cached, the Access-Control-Max-Age header controls how long the browser can skip re-checking, and if that's set too low every single request pays the extra OPTIONS round trip.

The 128-bit address space is the headline feature, but the more practically relevant differences are in the protocol design. IPv6 has no broadcast at all, it replaces broadcast-based mechanisms with multicast and a new protocol called Neighbor Discovery Protocol, which does what ARP does in IPv4, resolving link-layer addresses, using ICMPv6 messages instead of a separate protocol.

IPv6 also simplified the header, dropping the checksum field entirely since it's redundant with checksums already done at layer 2 and layer 4, and it pushed fragmentation to only happen at the source host rather than at routers along the path, so a packet that's too big just gets dropped with an ICMPv6 "packet too big" message telling the source to shrink it. Address autoconfiguration is another real difference, a device can generate its own address using SLAAC from the router's advertised prefix plus its own interface identifier without needing DHCP at all, though DHCPv6 still exists for networks that want centralized control.

Nagle's algorithm exists to stop a connection from being flooded with tiny packets. If an application writes small amounts of data repeatedly, like one keystroke at a time, TCP buffers it and waits either for enough data to fill a full segment or for an ACK of previously sent data before sending the next small chunk. That's great for something like a bulk file transfer where efficiency matters more than per-byte latency.

The problem shows up when Nagle's algorithm meets delayed ACK on the receiving side, which holds off sending an ACK for up to around 40ms hoping to piggyback it on outgoing data instead of sending an empty ACK packet. If the sender is waiting for that ACK before sending its next small chunk, and the receiver is delaying the ACK waiting for data to piggyback on, both sides stall for that 40ms window on every exchange. This is exactly the interaction that made early SSH and interactive telnet sessions feel laggy, and why most real-time or request-response protocols disable Nagle's algorithm with TCP_NODELAY.

A CDN reduces latency by putting cached copies of content on servers physically closer to users, so instead of a request in Tokyo traveling to an origin server in Virginia, it hits an edge node in or near Tokyo instead. Getting a user routed to the nearest edge node usually relies on anycast, where the same IP address is announced from many physical locations, and BGP routing naturally sends the user's traffic to whichever announcement is topologically closest, the internet's own routing does the work, no special DNS logic required.

Beyond distance, CDNs also cut origin load, a popular static asset gets served thousands of times from cache without ever hitting the origin, and they absorb a lot of DDoS traffic simply because it gets spread and filtered across hundreds of edge locations before it could reach a single origin. The tradeoff is cache invalidation, if you push a bad deploy and need to purge a cached asset globally, that purge has to propagate to every edge location, which depending on the provider can take anywhere from seconds to a couple of minutes, and that matters a lot when you're debugging why production still shows the old version.

Keep-alive is a property of a single TCP connection, it tells the server not to close the connection after sending one response, so the same client can send another request over that already-established connection instead of paying for a new handshake every time. Without it, every HTTP request needs its own TCP handshake and, over HTTPS, its own TLS handshake too, which is expensive for anything doing more than one request.

Connection pooling is a level above that, it's how a client, like a backend service calling another service, maintains a set of already-open keep-alive connections and reuses whichever one is free instead of opening a new connection per request or serializing everything through a single one. This matters a lot for backend-to-backend traffic, a service with a poorly sized connection pool to its database or a downstream API will either bottleneck on too few connections, queuing requests waiting for a free one, or exhaust the downstream service's connection limits if the pool is too large.

In HTTP/1.1, each TCP connection can only have one request in flight at a time waiting on its response. Browsers work around this by opening several parallel connections per domain, usually around six, but that's still a hard cap, and if one response is slow, every request queued behind it on that connection stalls, which is head-of-line blocking at the application layer.

HTTP/2 multiplexes many requests and responses over a single TCP connection by breaking them into frames tagged with a stream ID, so the server can interleave responses for request 1, 3, and 7 on the wire in whatever order they're ready, and the client reassembles them by stream ID. This removes the application-layer head-of-line blocking problem and lets one connection saturate available bandwidth instead of splitting it across six half-idle ones. It doesn't fully solve head-of-line blocking though, since it's still one TCP connection underneath, so if a single packet gets lost, TCP holds up delivery of every stream's data behind it until that packet is retransmitted, even though the frames belong to logically independent requests, which is exactly the gap HTTP/3 was built to close.

TCP's sliding window is how a sender knows how much unacknowledged data it's allowed to have in flight at once. The receiver advertises a window size in every ACK telling the sender how much buffer space it currently has available, and the sender can keep sending up to that limit without waiting for each individual ACK, which is what lets TCP pipeline data instead of stopping and waiting after every segment.

The original TCP header only reserves 16 bits for window size, capping it at 65,535 bytes, which becomes a real throughput ceiling on high-latency links, since maximum throughput is roughly window size divided by round-trip time. On a connection with 100ms RTT, a 64KB window caps you around 5 Mbps no matter how much bandwidth is actually available, the classic long fat network problem. Window scaling, negotiated as a TCP option during the handshake, lets both sides agree on a scale factor that multiplies the effective window up to about 1GB, which is necessary for moving large amounts of data across continents, and why some misbehaving legacy middleboxes that strip TCP options can silently tank throughput for connections passing through them.

TIME_WAIT is a delay state the side that sent the final ACK holds a closed connection in, for twice the Maximum Segment Lifetime, before it actually releases the socket. RFC 9293 recommends an MSL of two minutes, which would make TIME_WAIT four minutes long by the book; Linux and most production systems shorten that considerably, closer to sixty seconds. The point is making sure a duplicate, delayed packet from the old connection can't get misdelivered into a brand new connection that happens to reuse the same four-tuple.

On a server opening and closing thousands of short-lived outbound connections a second, TIME_WAIT sockets can pile up faster than the ephemeral port range frees them, and you genuinely run out of local ports to open new connections from. SO_REUSEADDR and a wider ephemeral port range are the usual fixes. I'd be skeptical of anyone who tells you to just disable TIME_WAIT outright.

Statelessness means the protocol itself carries no memory between one request and the next, the server treats each HTTP request as if it's never seen that client before. Everything that feels like "the server remembers me" is built on top of that, not inside it, usually a session ID stored in a cookie that the browser resends automatically with every request, which the server uses to look up the real session data (RFC 9110, the current HTTP semantics specification, still defines the protocol this way, even though almost no user-facing site behaves like a stateless system in practice). Tokens move that state into the token itself instead of a server-side lookup, but the underlying protocol stays stateless either way, the statefulness is entirely an application-layer illusion built with cookies, headers, or tokens.

TTL, almost certainly. Every DNS record ships with a Time To Live telling resolvers how long they're allowed to cache it before asking again, and a resolver that cached the old value five minutes before your change, with a one-hour TTL, is going to keep serving that old answer for up to fifty-five more minutes, correctly, by design. "DNS propagation" as a vague multi-day phenomenon is mostly a myth; what's actually happening is a predictable, TTL-governed cache expiry across however many resolvers cached the old answer. That's exactly why teams drop the TTL to something short, sixty or ninety seconds, in the hours before a planned cutover, then raise it back up once the new value is stable.

Borrow two bits from the host portion, moving from /24 to /26, since 2^2 = 4 gives exactly four subnets. Each /26 has 2^(32-26) = 64 addresses total, 62 usable after subtracting the network and broadcast addresses, which clears the 60-host requirement with two to spare. The four subnets land at 10.20.30.0/26 (hosts.1 through.62), 10.20.30.64/26 (.65 through.126), 10.20.30.128/26 (.129 through.190), and 10.20.30.192/26 (.193 through.254).

$ ipcalc 10.20.30.0/26
Address:  10.20.30.0
Netmask:  255.255.255.192 = 26
Network:  10.20.30.0/26
HostMin:  10.20.30.1
HostMax:  10.20.30.62
Broadcast: 10.20.30.63
Hosts/Net: 62

Not really, and I'd push back on anyone who leans on it that way. NAT exists to solve address scarcity, letting a household's dozen devices share one public IP by translating and tracking connections through Port Address Translation. The fact that unsolicited inbound traffic can't reach a device behind NAT without an explicit forward is a side effect of that translation, not a designed security boundary, and it's exactly the kind of side effect that breaks the moment someone opens a port forward or a UPnP request punches a hole through it. A stateful firewall is a security feature. NAT is an address-sharing mechanism that happens to look like one from the outside.

The browser checks its own DNS cache, then the OS cache; nothing fresh, it queries the configured resolver, which works its way from root to.com to Google's authoritative servers and returns an IP address. The browser opens a TCP connection to that IP on port 443: SYN, SYN-ACK, ACK. Before a single byte of the actual page loads, a TLS handshake runs on top of that connection, negotiating a cipher suite, presenting and validating a certificate, and deriving a shared session key. Only after that does the browser send an HTTP GET request, encrypted, and the server, almost certainly sitting behind a load balancer and a CDN edge node at Google's scale, returns a response, typically a 200 with the page's HTML.

The browser then parses that HTML, discovers references to CSS, JavaScript, and images, and fetches those too, usually multiplexed over the same connection if the server speaks HTTP/2 or HTTP/3, rather than opening a fresh TCP and TLS handshake for every single asset the way an HTTP/1.1-only setup would have to.

$ curl -v https://google.com 2>&1 | head -12
* Connected to google.com (142.250.x.x) port 443
* TLS handshake, Client hello (1)
* TLS handshake, Server hello (2)
* SSL connection using TLSv1.3
* Server certificate: CN=*.google.com
> GET / HTTP/2
> Host: google.com
< HTTP/2 200
< content-type: text/html; charset=UTF-8

When latency and loss only show up under load, the first thing I'd rule out is bufferbloat rather than actual congestion-driven loss. Consumer routers and plenty of enterprise switches have deep output queues, and instead of dropping packets early when a link starts to saturate, they buffer everything, which means TCP's congestion control never sees the signal it needs, a dropped packet or an ECN mark, to back off, so the queue keeps growing and every packet sitting in it accumulates extra latency, sometimes hundreds of milliseconds, even though nothing is technically lost yet.

tcpdump -i eth0 -w capture.pcap 'tcp port 443'

I'd confirm this with a capture on both ends during a loaded test, looking at the gap between when a segment is sent and its ACK comes back, and checking for retransmissions via duplicate ACKs or SACK blocks in the TCP options versus outright timeouts. A rising RTT with occasional real loss under load, but not while idle, points at a saturated link with an oversized buffer. Loss that shows up immediately and scales with the number of concurrent flows points more toward an actual capacity problem or a misconfigured QoS policy dropping the wrong queue's packets. The fix for bufferbloat is usually enabling active queue management, like fq_codel, on the bottleneck device, which drops or marks packets early enough that TCP's congestion control actually reacts instead of the buffer just growing deeper.

BGP is the protocol autonomous systems, essentially independent networks like an ISP or a large cloud provider, use to tell each other which IP prefixes they can route to and through how many hops. Every AS announces the prefixes it owns or can reach to its neighbors, and each router picks the best path based on attributes like AS path length, not on actual latency or bandwidth, BGP has no concept of network performance at all, it's purely reachability and policy.

That's exactly why a misconfigured BGP announcement can take down services far outside the network that made the mistake. If an AS accidentally announces a more specific prefix, or a prefix it doesn't own, other networks that trust that announcement start routing traffic for those addresses toward the misconfigured AS, since BGP prefers more specific routes and has essentially no built-in authentication of who's allowed to announce what. This is what happened in the 2008 Pakistan Telecom incident that took YouTube offline globally for a couple of hours, a route meant to just block YouTube inside Pakistan leaked to upstream providers and propagated worldwide. RPKI, which cryptographically signs which AS is authorized to originate which prefix, is the current mitigation, but adoption is still far from universal, which is why route leaks and hijacks remain a recurring category of major outage even now.

A full cone NAT maps an internal IP and port to the same external IP and port for every destination, and once that mapping exists, any external host can send traffic back through it to the internal device, which makes it relatively easy for a peer to punch through. A symmetric NAT, common on corporate and mobile carrier networks, creates a different external port mapping for every distinct destination the internal host talks to, so a peer that learned your external address from a STUN request talking to one server can't actually reach you through that mapping, because your NAT uses a completely different port when you talk to that peer directly.

This is exactly why WebRTC needs the full ICE framework rather than STUN alone. STUN works fine to discover your public IP and port when both sides sit behind full cone or restricted cone NATs, but two peers both behind symmetric NAT genuinely cannot connect directly no matter how many times they retry, the mappings are unpredictable from the outside. TURN exists as the fallback for exactly that case, a relay server both peers connect to and send all their media through, at the cost of extra latency and paying for that server's bandwidth. ICE is the negotiation layer that tries every candidate pair, direct connection, connection via a reflexive public address, and finally the TURN relay, and picks whichever one actually works. In practice, budgeting TURN relay bandwidth for something like 15 to 20 percent of calls in a production WebRTC service is a normal cost of doing business, since a meaningful chunk of real-world networks sit behind symmetric NAT or otherwise block direct peer-to-peer traffic.

That error is client-side ephemeral port exhaustion, not the server-side TIME_WAIT problem people usually think of first. Every outbound TCP connection from a given source IP to a specific destination IP and port needs a unique local ephemeral port, and the default ephemeral port range on Linux is only around 28,000 ports, 32768 to 60999. Once that many connections are in flight, or lingering in TIME_WAIT, to the exact same destination, the OS has no more source ports left to hand out for new connections to that destination.

sysctl net.ipv4.ip_local_port_range="1024 65535"
sysctl net.ipv4.tcp_fin_timeout=15
sysctl net.ipv4.tcp_tw_reuse=1

The fix depends on what's actually available. Widening ip_local_port_range gives more ports to work with, lowering tcp_fin_timeout shortens how long closed connections linger in TIME_WAIT, and enabling tcp_tw_reuse lets the kernel recycle TIME_WAIT sockets for new outgoing connections when it's safe to do so. But the real fix for a service under sustained high connection rates to one destination is almost always connection pooling and reuse via keep-alive rather than opening a new connection per request, since even doubling the ephemeral port range just delays hitting the ceiling again at higher scale, it doesn't remove the underlying design problem of treating a downstream call as a fresh connection every time.

HTTP/2 solved head-of-line blocking at the application layer by multiplexing streams over one TCP connection, but it's still bottlenecked by TCP itself, since TCP guarantees in-order delivery for the entire connection. A single lost packet stalls every stream's data behind it in the kernel's receive buffer until that one packet gets retransmitted, even if the lost packet belonged to a completely unrelated stream. HTTP/3 fixes this by moving off TCP entirely and running over QUIC, which is built on UDP but reimplements reliability and ordering itself, per stream, so a lost packet on stream 5 only blocks stream 5, streams 1 through 4 keep flowing independently.

QUIC also folds the transport and TLS handshakes together instead of doing them as separate round trips, and supports 0-RTT resumption, where a client reconnecting to a server it's talked to recently can send actual application data in its very first packet using cached parameters from the previous session, at the cost of some replay-attack considerations server implementations have to guard against for anything non-idempotent. The other significant win is connection migration, a QUIC connection is identified by a connection ID rather than the traditional source and destination IP and port tuple, so a phone switching from Wi-Fi to cellular mid-download can keep the exact same logical connection alive across the network change instead of the whole thing dropping and needing a fresh TCP and TLS handshake, which is a problem TCP simply has no answer for.

It builds just enough reliability on top of UDP for the specific things that need it, and accepts loss for everything else. Player position updates usually don't get retransmitted at all, since a fresher one is arriving 20 to 60 times a second anyway, and a stale one arriving late is worse than none. Anything that genuinely can't be dropped, a kill confirmation, an inventory change, gets its own lightweight acknowledgment and retry logic inside the game's own protocol, which costs far less than paying TCP's full ordering guarantee on every packet in the stream.