Networks

When you open a game and connect to a server, your packets travel a longer distance than most players realize. The data leaves your machine, transits your home router, hands off to your internet service provider, climbs through a hierarchy of larger network operators, and eventually arrives at a data center that may be on a different continent. Most of this journey happens on fiber optic cables: strands of glass thinner than a human hair that carry pulses of light at speeds approaching the speed of light itself.

The most important part of this infrastructure is invisible from any populated area. An estimated 95 percent of all intercontinental data transits submarine cables: bundled fiber-optic strands laid on ocean floors, connecting the major population centers of the world. There are more than five hundred active submarine cable systems globally. They are repaired, when they fail, by specialized cable-laying ships that travel slowly to the fault location, lift the damaged section out of the ocean, splice it, and lower it back. The internet feels weightless to use, but its physical layer is one of the largest engineering projects ever undertaken.

The consequence of that structure is that the internet has no operator to call. Each network decides independently whom to interconnect with and on what terms, and the global result emerges from those bilateral choices. This is why two users on the same street can have genuinely different experiences of the same service, and why a fault can be real for one network and invisible to another. It also explains why diagnosing a problem usually means establishing which network the trouble sits in before anything can be fixed, a question that has to be answered before the question of what broke.

The overwhelming majority of international traffic crosses the ocean inside submarine cables, of which there are a few hundred carrying the connectivity between continents. A deep water cable is surprisingly slender, often around the diameter of a garden hose, holding a small bundle of fibre pairs wrapped in steel and a copper conductor. It is armoured heavily where it approaches shore and left comparatively thin in deep water, because the realistic threats are fishing gear and anchors in shallow water rather than anything at depth.

Light does not survive thousands of kilometres unaided, so cables carry repeaters every few tens of kilometres that amplify the signal optically. The copper conductor exists to deliver power to them from shore, at thousands of volts. This is the detail that makes the system remarkable: a cable laid across an ocean basin must work unattended for its design life of around twenty five years, with no possibility of routine maintenance, and its active components are powered from land hundreds of kilometres away.

Faults are common rather than exceptional, running at well over a hundred a year globally, and most are caused by fishing and anchoring close to shore. Repair means locating the break, sending a cable ship, lifting the cable to the surface, splicing it and lowering it back, which takes days to weeks depending on weather and ship availability. The system tolerates this because capacity is diverse: routes are planned so that the loss of any single cable shifts traffic onto others. When several faults coincide on one corridor, the result is the regional slowdown that occasionally makes the news.

Typing a name does nothing by itself, because routing works on numeric addresses. Resolution begins at a resolver, usually run by an access provider or a public service, which walks down a hierarchy: a root server identifies who is authoritative for the top level, that server identifies who is authoritative for the domain, and that server returns the address. The design is deliberately distributed so no single operator holds the whole namespace, and it is one of the oldest parts of the system still working essentially as designed.

Caching is what makes it fast enough to be invisible. Every answer carries a time to live, and resolvers reuse it until that expires, so the great majority of lookups are answered locally in a millisecond without touching an authoritative server. That cache is also why changes propagate unevenly: shortening the time to live before a planned change is standard practice, and forgetting to do so is the reason a migration can appear complete to one person and not to another for hours.

Because resolution precedes everything, it is a disproportionate source of outages. A domain whose records expire, a signing error, or an authoritative service that becomes unreachable will present to users as the service being down, even when the servers behind it are healthy. This is why operators run authoritative service across multiple independent providers and announce the same addresses from many locations at once, so that the nearest instance answers and the loss of any one of them is absorbed.

Each independently operated network is an autonomous system with its own number, and they exchange reachability claims with their neighbours: announcements saying which blocks of addresses can be reached through them. A router assembles these into a view of the world and selects a path, weighing the commercial relationship first and the number of networks traversed second. Crucially, no router holds a map. Each one knows only what its neighbours have told it, and the end to end path is the emergent consequence of many independent local decisions.

Selection is driven by business as much as by distance. A network prefers to send traffic to a customer, then to a peer that costs nothing, then to a provider that charges, because that ordering is what makes the economics work. This is why a packet between two nearby cities sometimes travels a long way around: the short path exists physically but there is no agreement that permits it. Geography sets the floor on delay, and policy frequently decides how far above that floor the real path sits.

Because the system runs on claims rather than proof, a network can announce addresses that are not its own, by accident or deliberately, and neighbours that accept the announcement will deliver traffic to the wrong place. Historic incidents of this kind have made services globally unreachable for tens of minutes. The defences are filtering based on published records of who may announce what, and cryptographic validation of those records, which is now widely but not universally deployed. Routing security remains one of the genuine unfinished pieces of the internet.

The other half of the physical internet lives in data centers: purpose-built facilities that house the servers, switches, routers, and storage systems that run almost every online service. A modern hyperscale data center is a building the size of several football fields, with redundant power supplies, dedicated cooling systems, fire suppression, and physical security comparable to a bank vault. The largest operators (Amazon Web Services, Google Cloud, Microsoft Azure) run hundreds of data centers worldwide, each capable of serving millions of concurrent users.

The economics of data centers are dominated by power and cooling. Servers generate heat in proportion to the work they do; cooling that heat costs nearly as much electricity as the servers themselves consume. Locating data centers near cheap and reliable electricity (hydroelectric power in the Pacific Northwest, nuclear power in northern Virginia) has shaped the geography of the modern internet as much as proximity to population centers. A game server you connect to in California likely lives in a building chosen for its access to California’s power grid, not for its proximity to its players.

A useful way to read any facility is to ask what can be worked on while it is running. That single question exposes the real design: whether there are two independent power paths or one, whether cooling can lose a unit without raising inlet temperatures, whether a network device can be replaced without isolating a rack. Published tier levels are shorthand for exactly this property, concurrent maintainability, and the reason it matters more than peak capacity is that most outages happen during planned work. A facility that cannot be maintained live will eventually be maintained anyway.

The internet is not a single network. It is, more accurately, a network of networks: autonomous systems that exchange traffic with each other through standardized protocols. At the top of the hierarchy are tier-1 carriers (companies like Cogent, NTT, and Lumen) that operate the largest fiber backbones and exchange traffic with each other for free under settlement-free peering arrangements. Below them are regional carriers, mobile network operators, and the consumer ISPs that ultimately deliver the connection to your home.

Two networks exchange traffic through one of three mechanisms. Peering means two networks agree to carry each other’s traffic without payment, usually because the volume is roughly equal in both directions. Transit means one network pays another to carry its traffic to and from the rest of the internet. Internet exchange points (IXPs) are physical facilities where many networks interconnect simultaneously, reducing the cost and latency of routing. The complexity is real, but the system has scaled gracefully from a few dozen connected institutions in the 1980s to billions of connected devices today.

The pattern underneath almost every resilient service is to make the easy parts disposable and concentrate the difficulty in one place. Request handling is made stateless so that any server can serve any request and an unhealthy one can be discarded without consequence. All the genuinely hard problems, which is to say durability, consistency and failover, are then pushed into the data layer, where they can be solved once and operated by people who specialise in them. Most well publicised outages are failures of that data layer or of the health checking that decides what is still alive, rather than of the servers themselves.

A content delivery network is a set of facilities placed close to concentrations of users, each holding copies of material from an origin. The purpose is partly to reduce delay, since a request served from the same city avoids the irreducible transit time to another continent, and partly to absorb volume, since a popular item can be served from hundreds of locations rather than from one. For anything static the effect is dramatic, turning a request that would have taken a tenth of a second into one that takes a few milliseconds.

The interesting engineering is in deciding what may be cached and for how long. Static material is straightforward. Anything personalised cannot be shared between users at all, and anything that changes must have a way to be invalidated promptly. The common discipline is to make files immutable and give each version a distinct name, so a cache never needs invalidating and a deployment simply references new names. Where that is impossible, operators depend on explicit purges, and a purge that misses one variant of a resource is a classic source of users seeing stale content long after a fix.

Caching also changes the shape of failure. When an origin becomes unavailable, a cache can continue serving what it already holds, so a service can appear healthy for everything popular while being entirely broken for anything new or personalised. That is a desirable behaviour and a monitoring hazard, because external checks that request a cached page will report success throughout. Measuring the origin directly, rather than through the cache, is the standard correction and is frequently omitted.

Opening a secure connection is a negotiation. The two sides agree on which cipher to use, the server presents a certificate proving its identity, and both derive keys for the session. Each exchange costs one round trip, and a round trip is bounded by the speed of light in glass, which is roughly two thirds of the speed in a vacuum. Between distant continents a single round trip can approach two hundred milliseconds, so the number of exchanges required is not an academic detail; it is most of the delay before the first byte of content.

This is why successive revisions of the protocol have been preoccupied with removing round trips. Older versions needed two before any application data moved, in addition to the one spent establishing the underlying connection. Current versions need one, and offer resumption, where a client returning to a server it has spoken to before can send data immediately using material retained from the previous session. Newer transports combine the connection and the encryption negotiation so that both complete together, which removes another exchange outright.

The practical lesson is that a page can be slow for reasons that have nothing to do with its size. A first visit to a distant origin over a fresh connection may spend several hundred milliseconds purely on negotiation, and that cost is paid again for every separate origin a page references. Reducing the number of distinct origins, allowing connections to be reused, and terminating encryption close to the user are therefore performance work, even though none of them makes anything smaller.

Reliability in the internet world is measured in nines. A service with 99.9 percent uptime is allowed to be down for roughly nine hours per year. A service with 99.99 percent uptime (four nines) gets fifty-three minutes of downtime annually. Five-nines reliability allows roughly five minutes of downtime per year and is the threshold most major telecom and infrastructure providers commit to. Achieving five nines requires redundancy at every layer: redundant power supplies, redundant network paths, redundant data centers, redundant operating teams.

Latency is the second key metric. Round-trip time between a player and a game server determines how responsive a competitive shooter feels. A latency below 50 milliseconds is generally indistinguishable from local play; above 100 milliseconds, even casual players begin to notice. Game studios mitigate latency by deploying server clusters around the world and routing players to the closest one. The map of game-server regions (Frankfurt for European players, São Paulo for South American players, Singapore for Southeast Asian players) closely tracks the underlying geography of the internet’s data centers.

The weakness of a single availability figure is that it treats all failure as equivalent. An hour in which everything is unreachable and an hour in which one feature is slow for a tenth of users can produce identical numbers, while being entirely different events for the people affected. This is why operational practice has moved toward stating objectives per user visible journey, measured as the proportion of requests served correctly and quickly enough, and reporting that rather than whether the service was notionally up. It is a more honest measure because it counts the experience rather than the equipment.

Response times are not symmetrically distributed. A small proportion of requests take far longer than the rest, because of a retry, a cache miss, a garbage collection pause or a congested link, and that tail is what users notice and remember. Reporting a mean conceals it almost perfectly: a service whose average is comfortable can still fail a measurable share of requests badly. Operational reporting therefore uses percentiles, commonly the median alongside the ninety fifth and ninety ninth, because the gap between them describes the consistency that an average cannot.

Tail latency also compounds across dependencies. If one page assembles results from several services, the user waits for the slowest of them, so the probability of a slow response rises with the number of calls even when each one is individually fast. A page making twenty internal calls, each with a one in a hundred chance of being slow, is slow about a fifth of the time. This arithmetic is why reducing the number of sequential dependencies is usually a larger improvement than optimising any one of them.

Variation matters as much as magnitude for anything interactive. Jitter, the variability of delay rather than its size, is what makes live audio and games feel unstable, and a connection with a consistent eighty milliseconds is more pleasant than one averaging fifty with regular spikes. One common and fixable cause is excessive buffering in network equipment, which trades delay for throughput and can add hundreds of milliseconds under load. Modern queue management addresses it, which is why a connection can measure the same bandwidth and feel considerably better.

The internet’s distributed structure makes it resilient, but not invulnerable. Submarine cables get cut by ship anchors and earthquakes. Data centers lose power during heat waves. ISPs misconfigure routers and accidentally send traffic to the wrong place; this is called a route leak, and it has caused some of the largest outages in internet history. DDoS incidents (distributed denial-of-service events in which thousands of compromised devices flood a target with traffic) periodically take services offline despite massive defensive investments. Most of these problems heal within hours. A few cause days of disruption.

Every major service now publishes a status page that summarizes operational state in human-readable terms. Status pages exist because users need to know whether the problem is on their end or on the provider’s. For competitive online gaming, where five seconds of disconnection can lose a ranked match, status pages have become important enough that some sites monitor multiple status feeds simultaneously and aggregate them. Reliable internet is no longer a luxury; it is the precondition for an entire category of leisure and professional activity.

The most consistent finding across published incident analyses is that duration is dominated by detection and diagnosis rather than repair. A fault noticed in one minute and understood in five is usually fixed quickly, because the recent change is obvious; the same fault noticed after an hour has accumulated enough secondary effects to obscure its own origin. This is why investment flows toward monitoring that reflects user experience, and toward making changes small and reversible, so that the first response can be to undo the most recent one rather than to begin an investigation.

Online gaming sits on top of all of this infrastructure. Every match in a battle royale, every duel in a tactical shooter, every voice chat in a Discord server depends on the same basic chain: your packets traveling fiber optics, hitting routers, passing through ISPs, arriving at a data center, returning by the same path. The system is invisible when it works and infuriating when it does not. Twenty-five years ago, this much capability would have been science fiction. Today it is the precondition for any modern online community.

For Cosmo Strategy Guides readers, the practical implications are simple. Wired connections beat wireless ones for any competitive session. Server location matters: playing on a North American server from Europe will always cost you ping. ISPs are not interchangeable, especially for anyone who streams. A few minutes of network optimization (quality-of-service rules, router placement, choosing the closest server region) pays dividends across hundreds of hours of play. The infrastructure is mostly invisible, but it is not magic. Understanding it gives you control.

Everything earlier in this page converges on interactive play, which is the least forgiving ordinary use of a network. A game cannot wait for a retransmission, cannot hide a two hundred millisecond path, and cannot buffer its way out of jitter without destroying the feel it exists to provide. So it does what the voice systems do: it sends small frequent datagrams, tolerates loss instead of correcting it, predicts locally to mask the delay it cannot remove, and then quietly reconciles with the authoritative state. Understanding that chain is why region selection, and not bandwidth, is the single most useful thing a player can control.