Networking Study Portal

A: Because most of it is propagation delay, which is a function of distance and the speed of light in fibre, not of how fast your code runs. A UK-to-Australia round trip is roughly 170ms of pure signal travel time, so even an instantaneous server still yields a 170ms response. The only real levers are reducing the number of round trips, moving the data or computation geographically closer to the user via replicas or edge caching, or removing the cross-region dependency from the synchronous path entirely by making it asynchronous. This is why "count the round trips" is the useful analytical habit: a design with three sequential cross-region hops has a latency floor of about 500ms regardless of implementation quality, and no profiling exercise will find it because the time is not being spent in your process.

A: I would choose UDP when data that arrives late is worse than data that never arrives — live audio and video, real-time game state, and high-volume metrics or telemetry where losing a sample is acceptable. TCP's retransmission and in-order delivery actively hurt these: a dropped audio packet retransmitted 200ms later cannot be played because that moment has passed, and worse, TCP's ordering guarantee means it blocks the newer packets behind it. What I take on is that I must handle in the application anything I still need: sequence numbers if I care about ordering or detecting loss, my own acknowledgement scheme if some messages are important, congestion awareness so I do not flood the network, and typically an encryption layer such as DTLS. So the trade is real work in exchange for removing latency I cannot otherwise remove.

A: It can make routing decisions based on the content of the request, because it terminates the connection and parses the HTTP layer rather than only seeing IP addresses and ports. That enables path- and host-based routing to different backend pools, routing on headers or cookies for A/B tests and canary releases, TLS termination so backends serve plain HTTP, header injection and rewriting, response compression, and — importantly — safe retries, since it understands request boundaries and can resend an idempotent request to a healthy backend when one fails. The cost is CPU and a small latency addition from parsing, plus it must handle the protocol correctly, whereas a layer 4 balancer just forwards packets and so is faster and works for any protocol including raw TCP and UDP.

A: Because the dependency is shared, every instance evaluates the same condition and fails at the same moment, so the load balancer removes the entire fleet from rotation at once. The result is that a partial degradation — where the service could still serve cached reads, health endpoints, or the subset of routes that do not touch that dependency — becomes a complete outage returning nothing at all. It also makes recovery worse, because when the dependency returns, every instance passes its check simultaneously and the full load lands on a cold, unwarmed fleet, which can immediately re-fail. The better pattern is for readiness to reflect only conditions local to that instance, and to handle dependency failures inside the request path with timeouts, circuit breakers, and degraded responses, so the blast radius matches the actual damage.

A: Because notifications flow only from server to client, and SSE provides exactly that over plain HTTP while WebSockets adds bidirectional capability I would not use plus real operational cost. SSE runs over a normal HTTP response, so it passes through existing proxies, load balancers, and CDNs without special upgrade handling, works with standard HTTP authentication and compression, and the browser's EventSource implements automatic reconnection with a Last-Event-ID header so the server can resume from where the client left off. WebSockets requires protocol-upgrade support in every hop, needs its own heartbeat and reconnection logic because the browser gives you none, and its bidirectional channel invites protocol design that HTTP semantics would otherwise handle. I would switch to WebSockets when the client genuinely needs to send frequent messages too — chat with typing indicators, collaborative editing, multiplayer game input — because then the second direction is doing real work.

A: It is when the first item in a queue cannot be processed and everything behind it waits, even though the later items are ready. In HTTP it appears at two distinct levels. At the application level in HTTP/1.1, a connection handles one request at a time, so a slow response blocks every subsequent request on that connection — which is why browsers open several connections per host. HTTP/2 fixed that with multiplexing, but reintroduced it at the transport level: many streams share one TCP connection, and because TCP guarantees in-order delivery of the byte stream, a single lost packet halts delivery of all streams until it is retransmitted, so one dropped packet stalls unrelated requests. HTTP/3 addresses this by running over QUIC on UDP, where each stream has independent loss recovery, so a lost packet only affects its own stream. This is why HTTP/3's benefit is largest on lossy networks such as mobile.

A: Roughly 80 to 100 milliseconds. It is propagation delay set by distance and the speed of light in fibre, so no code change reduces it.

A: The HTTP request itself, so it can route on path, host, header, or cookie, terminate TLS, and safely retry idempotent requests.

A: UDP, because a retransmitted audio frame arrives too late to play, and TCP's ordering guarantee would also stall the newer frames behind it.

A: Liveness asks whether the process is wedged and needs restarting. Readiness asks whether this instance should receive traffic right now.