Skip to content

How Does the Internet Actually Work?

A ground-level tour of the cables, routers, and radio waves behind every page you load — and the starting point for this networking course.

It's late. You're on the sofa, phone in hand, and you tap play on a video. There's a half-second pause. Then a face appears, a voice starts talking, and you think nothing of it.

You shouldn't have to think about it. That's the mark of good engineering — it disappears.

But consider what that half-second actually contained. Your fingertip changed the charge on a glass screen. A chip turned that into a request. A radio in your phone turned the request into microwaves and threw them across the room at an antenna in a plastic box. That box pushed the signal down a cable buried under your street to a building a few kilometers away, where it joined traffic from thousands of your neighbours.

From there it became light — literal pulses of laser light — racing through a glass fiber toward a bigger city. Possibly it crossed a border. Possibly it dropped down to a beach, entered a cable no thicker than a garden hose, and traveled along the floor of an ocean to another continent.

At the far end it hit a server in a windowless building full of fans and blinking lights. That server found your video, chopped it into thousands of numbered pieces, and threw them back along a similar path — not necessarily the same one — where your phone caught them, put them back in order, and drew a picture.

Nothing in that story was magical. Every single step was a physical object doing a physical thing, governed by rules written down decades ago and followed by machines that have never met each other.

The internet isn't in the air. It's in the ground, under the sea, and in buildings you could drive past.

This article is a tour of those objects and those rules. It's deliberately broad rather than deep: the goal is to give you the whole shape of the system in one sitting, so that when the course starts taking pieces apart, you already know where each piece sits. Every major concept mentioned here gets a proper article later, and this page links to them as they come up.

Let's start with the most basic question, which is also the one most people get wrong.

What Is the Internet, Really?

The internet is a network of networks. That phrase sounds like a slogan, but it's a literal, technical description.

Your home Wi-Fi is a small network. Your office is a network. Your university campus is a bigger one. Your mobile carrier runs an enormous one. A cloud provider like AWS, Google Cloud, or Azure runs several of the largest networks on Earth. Your national telecom operator runs another.

The internet is what you get when all of those independent networks agree to carry each other's traffic using a shared set of rules. Those size categories have names and real design consequences, which is where the course itself begins — see Types of networks (LAN, WAN, MAN, PAN).

There is no central computer

This is the part that surprises people most. There is no master server. No central switchboard. No head office that "runs" the internet.

There are coordinating bodies — organizations that hand out address blocks, manage the domain name system's root, and publish the technical standards everyone implements. But none of them operates the internet. They maintain the agreements. The operating is done by tens of thousands of separate companies, universities, and governments, each running its own equipment for its own reasons.

Worth knowing: If the internet had a central computer, unplugging it would end the internet. That's not an accident — it's a direct consequence of packet switching, the routing idea covered next, which was designed from the start to route around a broken or missing piece rather than depend on any single one.

The building block: the autonomous system

The unit that actually matters here is the AS (Autonomous System) — a network under a single administrative control, with its own routing policy. Your ISP is an AS. A big university is often an AS. Cloudflare, Google, and Netflix each run their own. Tens of thousands of them are active at any moment, each announcing to its neighbours: "traffic for these blocks of addresses can reach them through me."

That's it. That's the whole coordination mechanism at the top level.

How networks connect to each other

Networks join up in two main ways:

  • Transit — a smaller network pays a larger one to carry its traffic to the rest of the world. This is what your ISP buys.
  • Peering — two networks agree to exchange traffic directly between their own customers, often at no cost, because it's cheaper and faster than paying a third party.

Much of this happens at an IXP (Internet Exchange Point) — a physical facility, usually a large room full of racks and switches in a major city, where dozens or hundreds of networks plug into shared infrastructure and swap traffic locally.

IXPs matter more than their obscurity suggests. When a country has a good local IXP, traffic between two people in that country stays in that country. When it doesn't, an email between neighbours might travel to another continent and back — adding hundreds of milliseconds and real cost.

        ┌──────────────┐
        │  Your ISP    │──── transit ────┐
        └──────┬───────┘                 │
               │ peering            ┌────▼──────────┐
        ┌──────▼───────┐            │ Global carrier│
        │     IXP      │────────────│  (backbone)   │
        └──────┬───────┘            └────┬──────────┘
               │                         │
   ┌───────────▼─────┐          ┌────────▼────────┐
   │ Local ISPs, CDNs│          │ Cloud providers │
   └─────────────────┘          └─────────────────┘

The internet is an agreement between networks, not a machine.

That agreement has a history, and the history explains why almost everything works the way it does today.

A Short History of the Internet

1960s: The idea of breaking data into pieces

Before the internet, long-distance communication meant circuit switching. When you made a phone call, the network reserved a physical path from you to the other person for the whole call. Efficient for continuous speech, terrible for bursty data, and fatally fragile: cut the circuit and the conversation ends.

In the early 1960s, researchers working independently on both sides of the Atlantic arrived at the same alternative: packet switching. Don't reserve a path. Chop the message into small labeled pieces, send each piece independently through whatever route is available, and reassemble them at the destination.

The consequences are enormous:

  • Resilience. No single line to cut. If a path dies, pieces take another.
  • Efficiency. Links are shared by everyone, moment to moment, instead of sitting idle in reserved circuits.
  • Scalability. Adding capacity means adding links, not renegotiating every connection.

Every message you've ever sent has traveled this way.

1969: ARPANET goes live

ARPANET, funded by the U.S. Department of Defense's advanced research agency, connected its first university nodes in 1969. It was tiny — a handful of machines at institutions in California and Utah. The first message crashed the receiving computer partway through.

But it proved packet switching worked outside a whiteboard, and it grew steadily through the 1970s.

1970s: TCP/IP is invented

ARPANET was one network. The harder problem was joining different networks — with different hardware, speeds, and conventions — into a single system. That's the inter-network problem the word "internet" comes from.

The answer, developed through the 1970s, was a pair of protocols:

  • IP (Internet Protocol) — handles addressing and delivery. It's deliberately simple and makes no promises: it does its best and doesn't guarantee anything arrives.
  • TCP (Transmission Control Protocol) — sits on top and adds the guarantees IP leaves out.

What that means concretely: if you send ten pieces of a file over IP alone, they might arrive in a different order, or one might not arrive at all, and nothing would notice or fix it. TCP is the layer that numbers those ten pieces, puts them back in order at the other end, and re-sends the one that went missing — automatically, before your application ever sees the data. That's the "guarantee" — ordering and retransmission — plus one more thing: flow control, so a fast sender doesn't overwhelm a slow receiver with more than it can process at once.

Splitting responsibilities this way was the key insight. The network stays dumb, cheap, and general. The smartness lives at the edges, in the endpoints. That's why the internet could carry web pages, then video, then video calls, then whatever comes next, without redesigning the middle. The formal description of that split is the TCP/IP model.

1983: The TCP/IP "flag day"

On 1 January 1983, ARPANET switched from its older protocol to TCP/IP. Everyone had to change on the same day — there was no gradual migration — which is why engineers still call it flag day.

That switch is the moment a research project became recognizably the internet. The same protocol family still runs everything you use today.

The DNS (Domain Name System) arrived at almost the same time, replacing a single manually maintained file of every host name with a distributed, delegated naming system. Without it, the network could not have grown past a few thousand machines.

1989–1991: The Web arrives

At CERN, Tim Berners-Lee proposed a system of documents linked to each other, readable through a program called a browser. By 1991 the World Wide Web was public, and by the mid-90s it was the reason ordinary people wanted an internet connection at all.

Here's the distinction people miss constantly:

The Web is not the internet. The internet is the road network. The Web is one kind of vehicle that drives on it — alongside email, video calls, game traffic, file transfers, IoT sensors, and every mobile app's API traffic.

1990s–today: Commercialization, broadband, mobile, and the cloud

The 1990s brought commercial ISPs, dial-up modems, and an explosion of consumers. The 2000s brought always-on broadband over DSL and cable, then fiber. The 2010s brought smartphones, which made mobile data the primary way most of humanity connects, and the cloud, which concentrated an enormous share of the world's servers into a small number of very large data centers.

One more shift matters: content moved closer to users. Rather than serving everyone from one origin server, large services push copies of their content into hundreds of locations worldwide via CDNs (Content Delivery Networks). A surprising fraction of what you load today never crosses an ocean at all — because a copy is already in or near your city.

Packet switching optimized for resilience over raw speed from the start. Everything else was built on top of that foundation.

The Physical Internet: What It's Actually Made Of

Let's follow the hardware outward, one layer at a time, from the device in your hand to the data center.

Inside your home

Your devices connect to a router in one of two ways:

  • Ethernet — a copper cable carrying electrical signals. Fast, stable, low latency, immune to interference. Still the right answer for desktops, game consoles, and anything that matters.
  • Wi-Fi — radio waves. Convenient, and degrades with distance, walls, metal, water, and neighbours using the same channel.

Your router does more work than most people realize. It assigns local addresses to your devices, forwards traffic between them, and acts as the single doorway between your home and everything else. Everything leaving your home passes through it — and it rewrites the address on the way out, for reasons covered in Public vs Private IP.

Many homes also have a separate box before the router — a modem, or an ONT (Optical Network Terminal) on fiber connections. The ONT's job is conversion: it turns pulses of light arriving on the fiber into electrical signals your router can understand, and back again.

The last mile

The stretch between your building and your ISP's nearest facility is called the last mile. It's the most expensive part of the network per user, because it can't be shared much — and it's the part that most determines your experience.

Technology Physical medium Typical strengths Typical weaknesses
Fiber (FTTH) Glass, light pulses Highest speeds, low latency, symmetric upload Expensive to deploy, limited availability
Coaxial cable Copper, electrical Fast downloads, widely deployed Shared capacity in a neighbourhood, slower upload
DSL Telephone copper, electrical Uses existing phone lines Speed drops sharply with distance from exchange
Cellular (4G/5G) Radio to a tower Mobile, quick to deploy Shared with everyone nearby, variable
Fixed wireless Radio to a fixed mast Reaches where cable doesn't Needs line of sight, weather sensitive
Satellite Radio to orbit Works nearly anywhere Higher latency, weather sensitive, capacity limits

The POP and the ISP's own network

Your last mile terminates at a POP (Point of Presence) — a local facility, often an unremarkable building or a cabinet on a street corner, where your ISP aggregates traffic from thousands of subscribers.

From there, traffic travels through the ISP's regional and national network toward larger hubs: core routers in major cities, connections to IXPs, and links to the carriers who sell long-distance transit.

The backbone

The backbone is high-capacity, long-haul fiber running between cities, countries, and continents. It's owned by a mix of traditional telecom carriers and, increasingly, the large technology companies who move enough of their own traffic to justify building private networks.

Backbone fiber generally follows existing rights of way — alongside railways, highways, and power lines — because permission to dig is often harder to get than the cable itself.

Data centers

At the far end sit data centers: purpose-built buildings full of racks, packed with servers, wrapped in enormous cooling and power systems. A large one draws as much electricity as a small city and is designed so that no single failure — of a power feed, a cooling unit, or a network link — takes it offline.

 Your device
     │  (Wi-Fi radio or Ethernet cable)
     ▼
 Home router
     │
     ▼
 Modem / ONT ── last mile (fiber, copper, coax, radio) ──┐
                                                          ▼
                                                    ISP POP
                                                          │
                                              ISP regional network
                                                          │
                                            ┌─────────────┴────────────┐
                                            ▼                          ▼
                                          IXP                   Transit carrier
                                            │                          │
                                            └──────────┬───────────────┘
                                                       ▼
                                              Long-haul backbone fiber
                                                       │
                                                       ▼
                                              Data center / CDN edge
                                                       │
                                                       ▼
                                                    Server

Almost every "wireless" connection is wireless for only its first few meters.

And when that backbone has to cross an ocean, it does something that surprises most people.

Cables, Not Clouds: The Truth About Undersea Cables

Intercontinental internet traffic travels through submarine fiber-optic cables lying on the seabed. Not satellites. Cables — by an enormous margin. TeleGeography, which maps this infrastructure for a living, puts satellites at 0.37% of total U.S. international capacity. Everything else is glass on the ocean floor.

Why fiber wins so decisively

  • Speed. Signals travel as light through glass — around two-thirds of the speed of light in vacuum, fast enough that distance, not the medium, becomes the limit.
  • Capacity. A single modern cable contains multiple fiber pairs, each carrying many wavelengths of light simultaneously, adding up to many terabits per second.
  • Latency. A direct seabed path beats a round trip to orbit and back, every time.
  • Cost at scale. Laying a cable is expensive once. Amortized over decades and petabytes, it is remarkably cheap per bit delivered.

What a submarine cable actually is

At the center are the fibers themselves — strands of ultra-pure glass, each thinner than a human hair. Around them sit a steel strength member, a copper conductor, waterproofing, and insulation.

Worth knowing: In the deep ocean, submarine cable is often not much thicker than a garden hose, despite carrying terabits of data. Near shore, where fishing gear and anchors pose real risk, it's wrapped in heavy armor and becomes far bulkier.

Light loses strength over distance, so every 50–100 kilometers the cable includes a repeater — a sealed unit that amplifies the optical signal. Repeaters need power, which is why the copper conductor is there: the cable carries a high-voltage feed from the shore stations at both ends, running the length of the ocean floor.

Laying and landing

Specialized ships lay cable slowly and carefully, surveying the route first to avoid known hazards, and burying the cable beneath the seabed in shallow water where risk is highest.

Both ends arrive at a cable landing station — usually a modest, heavily secured building near a beach — where the optical signal transfers onto the terrestrial backbone and continues overland.

Ownership is typically a consortium: several carriers and content companies jointly fund a cable and each take a share of its capacity. That's why a single cable can carry traffic for competitors who otherwise share nothing.

The cloud has a floor, and a lot of it is the seabed. Which raises the obvious question: then what are all those satellites doing?

So What Are Satellites For?

Satellite internet is real, useful, and improving fast. It just isn't the backbone.

The altitude trade-off

GEO (Geostationary) satellites sit about 36,000 km above the equator. At that altitude a satellite orbits at exactly the speed the Earth rotates, so it appears to hang motionless in the sky — which means a fixed dish can point at it permanently. One satellite covers an enormous area.

The cost is delay. A round trip means the signal climbs 36,000 km to the satellite, comes back down to a ground station, and then does that twice more to get a reply back to you — four hops of 36,000 km, at roughly light speed, adds up to a bit over 480 milliseconds before you count any processing or switching delay. In practice, published figures for a GEO round trip run to 500-600ms or more. Fine for broadcast television. Painful for video calls, remote desktops, and online games.

LEO (Low Earth Orbit) constellations fly far closer — hundreds of kilometers rather than tens of thousands — which cuts latency dramatically, into a range that feels much more like ordinary broadband.

The trade-off: each satellite covers a much smaller patch of ground and races across the sky in minutes. To provide continuous coverage you need hundreds or thousands of them, plus terminals that can track and hand off between satellites automatically.

Geostationary (GEO) Low Earth Orbit (LEO)
Altitude ~36,000 km Hundreds of km
Latency High, noticeable in real-time use Much lower, broadband-like
Coverage per satellite Very large Small
Satellites needed Few Hundreds to thousands
Dish behavior Fixed, points at one spot Tracks moving satellites

Where satellite genuinely shines

  • Remote and rural areas where laying fiber will never pay for itself
  • Ships at sea and aircraft in flight
  • Disaster zones where terrestrial infrastructure has been destroyed
  • Mountains, deserts, islands, jungles, and other hard-to-cable terrain
  • Temporary sites: construction, mining, research stations, field operations

The part everyone forgets

Satellites still hand off to ground stations. Your traffic goes up, comes back down at a gateway on the ground, and joins the same terrestrial fiber network as everyone else's. Some constellations add satellite-to-satellite links to reduce ground hops, but the destination server is still on the ground, reached over the ordinary internet.

Satellites extend the internet's reach. They do not replace its plumbing. And the same "wireless is only the first hop" logic applies much closer to home.

Wi-Fi and Mobile Data: Where Does the Signal Actually Go?

Wi-Fi is not the internet

This is worth stating bluntly, because the confusion causes real support headaches: Wi-Fi is a radio link covering the last few meters between your device and your router. Nothing more.

You can have a perfect five-bar Wi-Fi signal and no internet at all. That combination simply means the link between you and your router is excellent, and something beyond your router is broken — the last mile, your ISP, DNS, or the destination itself. Being able to name which of those failed, rather than saying "the internet is down," is most of what this course teaches; the framework for it is the OSI model.

Wi-Fi operates in shared radio bands. Lower-frequency bands travel further and penetrate walls better but carry less data; higher-frequency bands are much faster but shorter-range and more easily blocked. Everyone in range shares the airtime, which is why apartment buildings are difficult radio environments and why a wired connection is still the reliable choice for anything critical.

The mobile data path

Mobile works the same way, at larger scale and with far more engineering behind it.

 Phone
   │  radio link
   ▼
 Cell tower (base station)
   │  backhaul — almost always fiber
   ▼
 Carrier core network  (authentication, routing, billing, policy)
   │
   ▼
 Carrier's internet edge → IXP / transit → destination

Your phone's radio only reaches the tower — typically a few hundred meters to a few kilometers. From the tower onward, your data rides buried fiber like everything else. That link from tower to core network is called backhaul, and it's the reason a "5G rollout" is mostly a fiber-digging project: new towers are useless without high-capacity wired links behind them.

Newer mobile generations improve three things at once: raw speed, latency, and how many devices a single cell can serve simultaneously. That last one matters more than headline speeds in crowded places.

How Data Actually Travels: Packets, Addresses, and Routing

Everything is 0s and 1s — carried differently

Text, photographs, music, and video are all just binary data: long sequences of 0s and 1s. What changes as your data moves is the physical signal carrying those bits.

Connection type Physical medium How data actually travels
DSL / Coaxial / Ethernet Copper Electrical pulses
Fiber (including undersea) Glass Pulses of light
Wi-Fi Air Radio waves (short range)
Mobile data Air Radio waves (to a cell tower)
Satellite Air / vacuum Radio waves (to orbit)

The same file becomes light, then electricity, then radio, then light again, converted at every boundary by hardware whose entire job is translation. The meaning never changes. Only the carrier does.

Why data is broken into packets

Imagine shipping the contents of a warehouse overseas. You don't send it as one giant indivisible object. You pack it into standard containers, label every container with an origin and destination, and let each one find its way. If one is lost, you re-send that container — not the warehouse.

Packets are those containers. Each is a small chunk of your data wrapped in a header that says, at minimum, where it came from and where it's going.

The benefits are the same as with shipping:

  • Sharing. Thousands of conversations interleave over the same link instead of monopolizing it.
  • Resilience. Packets can take different routes; a failure mid-transfer doesn't destroy the whole transfer.
  • Efficient recovery. Losing one packet costs one retransmission.

Packets can and do arrive out of order — that part is universal, since each one can take a different route. What happens next depends on which protocol is carrying them: some protocols number each packet, reassemble them in order, and ask for a re-send of anything missing; others just hand pieces to the application in whatever order they show up and don't bother re-requesting a lost one. Which behavior you get is the subject of TCP vs UDP, a few sections below.

IP addresses: the postal system

An IP address identifies a device's location on the network — a postal address for a machine. Every packet header carries a source and a destination IP.

There are two versions in use:

  • IPv4 — the older format, written as four numbers like 93.184.216.34. It allows about 4.3 billion addresses, which the world ran out of.
  • IPv6 — the newer format, written as longer hexadecimal strings. Its address space is so large it will not run out in any practical sense.

Because IPv4 addresses are scarce, most home and office networks use NAT (Network Address Translation). Your router holds one public IP and hands out private addresses (like 192.168.x.x) internally, translating between them. This is why every device in your home shares one public address as seen from outside — and why hosting a server at home takes extra configuration.

Addresses get you to the right machine. Ports get you to the right program on that machine: port 443 for HTTPS, 53 for DNS, 22 for SSH, and so on. An address plus a port identifies a specific conversation endpoint.

All three of those ideas get taken apart properly in the course: IP addressing (IPv4, IPv6), Introduction to ports and protocols, and — for the part where you work out which addresses belong to which network — CIDR.

DNS: the address book

Humans don't memorize numbers. DNS (Domain Name System) is the internet's distributed address book: you type a name, DNS returns the IP address behind it.

It's hierarchical and delegated, which is how it scales:

  1. Root servers know who is responsible for each top-level domain (.com, .uz, .org).
  2. TLD servers know which name servers are authoritative for each domain within them.
  3. Authoritative servers hold the actual records for a specific domain.
  4. Resolvers — run by your ISP or a public provider — do the asking on your behalf and cache the answers.

Caching is what makes it fast. Most lookups never leave your ISP, because someone nearby asked the same question recently and the answer is still valid.

Routers and BGP: the map

Routers are the intersections of the internet. Each one holds a routing table, reads each packet's destination address, and forwards it out of whichever interface moves it closer to its goal. No single router knows the full path — it only knows the next hop. The path emerges from thousands of independent local decisions.

Between whole networks, coordination happens through BGP (Border Gateway Protocol). Each autonomous system announces to its neighbours which address blocks it can reach and how. Those announcements propagate, and every network builds its own view of how to reach everything else.

BGP is built on trust and policy rather than central authority, which is both its genius and its weakness. It lets tens of thousands of independent networks agree on routes with no coordinator — and it means a misconfigured or malicious announcement can pull traffic toward the wrong place, which has caused several notable global incidents.

Packets are containers, addresses are labels, DNS is the address book, and BGP is the map everyone shares.

To keep all of this manageable, engineers organize it into layers.

The Layer Model: Why Engineers Talk in Stacks

Networking is taught in layers because layering is how the system is actually built. Each layer does one job and relies on the layer beneath it without needing to know how it works.

The practical model — the one that matches real software — has four layers:

Layer Job Examples
Application What the data means HTTP, DNS, SMTP, SSH
Transport Reliable (or fast) delivery between programs TCP, UDP
Internet Addressing and routing between networks IP, BGP
Link Moving bits across one physical hop Ethernet, Wi-Fi, fiber optics

Why does this matter to you? Because layering is a debugging tool. When something breaks, you're really asking which layer failed:

  • No signal to the router? Link layer.
  • Router fine but nothing loads? Internet layer — routing, or your last mile.
  • The site's IP works but the name doesn't? Application layer — DNS.
  • Page loads but the app misbehaves? Application layer — your code.

There's an older, finer-grained seven-layer version of this model that the whole industry still uses for vocabulary, and the mapping between the two matters in practice. Both get a full article: OSI model (7 layers) and TCP/IP model.

TCP vs UDP in one paragraph

TCP guarantees delivery and order. It establishes a connection, numbers everything, retransmits losses, and slows down when the network is congested. Use it when correctness matters: web pages, file transfers, email.

UDP does none of that. It fires packets and forgets them. Use it when speed matters more than perfection and the application can handle loss itself: live video, voice calls, gaming, DNS queries. A dropped frame in a video call is better than a call that pauses to re-request it.

Anatomy of Loading a Website, Step by Step

Here is the full journey, in order, for a single visit to a site.

Step 1 — DNS lookup

Your device needs an IP address for the domain name. It checks its own cache first, then your operating system's, then your router's, then asks a resolver. If nobody has a cached answer, the resolver walks the hierarchy: root → TLD → authoritative server.

Typical cost: a few milliseconds when cached, tens to hundreds when not.

Step 2 — Routing to the server

Your device sends the first packet toward that IP. Your router forwards it to your ISP, which forwards it onward. Every router along the way makes an independent next-hop decision, guided by routes learned through BGP.

If a CDN is involved — and for large sites it almost always is — DNS may already have pointed you at an edge server in or near your own city rather than the origin on another continent.

Step 3 — Connection established (TCP handshake)

Your device and the server exchange a short three-message handshake to agree they're both present and ready. This costs one full round trip before any real data moves — which is why physical distance is so hard to engineer around.

Step 4 — Encryption negotiated (TLS handshake)

For any https:// site, the two sides then negotiate encryption: agreeing on a cipher, verifying the server's certificate, and establishing keys. This costs additional round trips (fewer in modern versions).

From this point on, everything is encrypted end to end. Intermediate networks can see that you're talking to a server and roughly how much data is flowing — they cannot read the contents.

Step 5 — HTTP request sent

Your browser finally asks for what it wants: a specific page or resource, plus headers describing the browser, accepted formats, cookies, and cache state.

Step 6 — Server response

The server processes the request — possibly querying a database, running application code, or serving a cached copy — and responds with a status code and the content, broken into packets.

TTFB (Time To First Byte) is the gap between request and first byte back. It's the cleanest single measure of "is this slow because of the network or because of the server?"

Step 7 — Reassembly and re-requests

Your device orders the packets by sequence number and requests re-sends for anything missing. TCP handles this invisibly.

Step 8 — Render, then repeat

Your browser parses the HTML and discovers it needs more: stylesheets, scripts, fonts, images, video segments. Each becomes another request — many of them to entirely different domains, each potentially needing its own DNS lookup, connection, and handshake.

A typical modern page triggers dozens of these. Your browser runs many in parallel, reuses connections where it can, and renders progressively so you see something before everything has arrived.

DNS lookup → TCP handshake → TLS handshake → HTTP request
   → server processing → packets return → reassembly → render
        → dozens of follow-up requests for page assets

All of it, usually, in well under a second. A page load is thousands of small deliveries that happen to arrive together.

But what happens when part of that path physically fails?

What Happens When a Cable Breaks?

Submarine cables break more often than you would guess. The International Cable Protection Committee counts roughly 200 faults worldwide in a typical year.

The causes are mostly mundane:

  • Fishing activity — trawler gear dragging across the seabed, the single largest cause
  • Ship anchors, especially in shallow coastal water and busy shipping lanes
  • Earthquakes and undersea landslides, which can sever several cables at once
  • Abrasion where cable rubs against rock on the seabed
  • Ordinary equipment failure and age

Despite the famous myth, shark bites are a marginal cause. Fishing gear, anchors, and undersea landslides do vastly more harm.

Why you usually don't notice

The network is built with redundancy. Most major routes are served by several cables, and terrestrial paths often provide alternatives. When a link dies, BGP notices within seconds to minutes and traffic reroutes automatically around the failure.

This is packet switching's original bet still paying off decades later: no single line to cut.

Why you sometimes do

Redundancy isn't infinite, and it isn't evenly distributed.

If a region is served by only two or three cables and two are cut simultaneously — which happens, since nearby cables share hazards — the surviving capacity must absorb all the traffic. It can't. The result is congestion: pages load, but slowly; video drops quality; calls stutter. Not an outage, but a degradation that can last for weeks.

Weeks, because repair is a physical operation. A cable ship must be dispatched, sail to the site, locate the fault precisely, grapple the cable up from the seabed, splice in a new section, test it, and lay it back down. Weather delays are common, and there are a limited number of these ships worldwide.

Not all outages are physical

Some of the biggest internet disruptions involve no broken hardware at all:

  • BGP misconfigurations that announce routes a network can't actually serve, pulling traffic into a black hole
  • DNS failures at a major provider, which make working servers unreachable by name
  • Data center or cloud region failures, which take down thousands of services that share that dependency
  • Deliberate shutdowns ordered at a national level

Redundancy prevents outages; it doesn't prevent congestion — and not every outage is a cut cable.

Six Myths Worth Killing

Myth 1: "The cloud is wireless." The cloud is other people's computers in buildings, connected by fiber. There is nothing airborne about it.

Myth 2: "Most international traffic goes by satellite." Satellites account for a fraction of a percent of international capacity. Nearly all of it goes through cables on the seabed.

Myth 3: "Wi-Fi is the internet." Wi-Fi is the last few meters. Full signal with no connectivity is a normal, coherent state.

Myth 4: "Sharks are eating the internet." Fishing gear and anchors are the real culprits, by a wide margin.

Myth 5: "More bandwidth always means a faster experience." Bandwidth is how wide the pipe is; latency is how long the trip takes. Loading a typical page involves many round trips, so latency often matters more than raw speed. Upgrading a 500 Mbps connection to 1 Gbps will not make a website on another continent feel closer.

Myth 6: "Someone runs the internet." Standards bodies coordinate. Registries allocate. Nobody operates it.

See It Yourself: Five Commands That Reveal the Internet

Everything above is observable from your own machine. Open a terminal — the shapes below are illustrative (your own hop count, hostnames, and timings will differ), but the structure of the output is exactly what you'll see.

1. ping — sends small packets and measures the round trip. Tells you two things: whether the host is reachable, and your latency to it.

ping -c 3 example.com

64 bytes from 23.192.228.80: icmp_seq=1 ttl=57 time=11.2 ms
64 bytes from 23.192.228.80: icmp_seq=2 ttl=57 time=10.9 ms
64 bytes from 23.192.228.80: icmp_seq=3 ttl=57 time=11.4 ms

Compare a local site to one on another continent — you're measuring the speed of light through glass, plus every router in between.

2. traceroute (Windows: tracert) — shows each hop your packets take, one router at a time.

traceroute example.com

 1  10.0.0.1 (10.0.0.1)  1.203 ms
 2  100.64.0.1 (100.64.0.1)  6.881 ms
 3  core1.isp-backbone.net (203.0.113.1)  9.442 ms
 4  ix1.some-ixp.net (198.51.100.7)  10.117 ms
 5  23.192.228.80 (23.192.228.80)  11.038 ms

You can often read the path in the hostnames: your router, your ISP, an exchange point, and finally the destination network. This is the single most revealing networking command there is — if you learn one command from this article, make it this one.

3. dig (Windows: nslookup) — performs a DNS lookup and shows exactly what came back, including the TTL: how long the answer may be cached.

dig +noall +answer example.com

example.com.        86400   IN      A       23.192.228.80

Run it twice a minute apart and watch the TTL (the number after the name) count down as the cached answer ages.

4. curl -I — fetches only the HTTP response headers.

curl -I https://example.com

HTTP/2 200
content-type: text/html
cache-control: max-age=604800

Shows the status code, caching directives, and — on a CDN-fronted site — often a header naming which edge server answered.

5. Your browser's Network tab (F12 → Network) — the most practical of all. Reload a page and watch every individual request: DNS time, connection time, TLS time, TTFB, download time, and the waterfall showing what blocked what. Nearly every front-end performance problem is visible here.

Why This Matters

If you build or run software, the physical internet stops being trivia the moment something goes wrong.

For developers, understanding latency changes how you design. A network call is not a function call. It can be slow, it can fail halfway, and it can succeed while you think it failed. Knowing that round trips are expensive is why we batch requests, cache aggressively, and load progressively rather than blocking on everything at once.

For DevOps and SRE engineers, geography is architecture. Choosing a region, placing CDN edges, designing failover, and setting timeouts are all decisions about physical distance and real infrastructure. A multi-region setup that depends on one provider's DNS is not as redundant as the diagram suggests.

For sysadmins and network engineers, layered thinking is the fastest path to a fix. Is it the link, the route, the name resolution, or the application? Answering that question in the right order turns a two-hour outage into a ten-minute one.

For security professionals, the shape of the network is the shape of the threat model. Traffic crosses networks and jurisdictions you don't control. That's why encryption in transit is mandatory, why DNS and BGP are attack surfaces and not just plumbing, and why "it's internal traffic" is an assumption worth testing.

And for everyone: knowing that the internet is made of physical things owned by real organizations makes you a better judge of its politics, its economics, and its fragility.

So the next time you tap play and the video just starts, remember what it took: a radio wave, a pulse of light, an ocean floor, and a few hundred machines that have never met agreeing to pass your packets along.

Where to Start in This Course

This page was the map. The course is the territory, and it assumes no prior networking knowledge — start at the beginning and read forward.

Module 1 — Networking fundamentals builds the vocabulary everything else depends on:

From there the course works outward, and each module assumes the ones before it:

Modules 9 and 10 are the ones that pay off fastest in day-to-day infrastructure work, and both are written to be readable early — but they lean on the packet-level mechanics from Modules 1 and 2, so skipping ahead costs you more than it saves.

Glossary

AS (Autonomous System) — A network under single administrative control with its own routing policy.

Backbone — High-capacity long-haul fiber connecting cities, countries, and continents.

BGP (Border Gateway Protocol) — The protocol by which independent networks tell each other which addresses they can reach.

CDN (Content Delivery Network) — A distributed set of servers that cache content close to users.

DNS (Domain Name System) — The distributed system that translates domain names into IP addresses.

GEO / LEO — Geostationary (~36,000 km) and Low Earth Orbit (hundreds of km) satellite orbits.

IP (Internet Protocol) — The addressing and delivery protocol underlying all internet traffic.

ISP (Internet Service Provider) — The company that connects you to the rest of the internet.

IXP (Internet Exchange Point) — A facility where many networks interconnect and exchange traffic locally.

Last mile — The connection between a customer's premises and their ISP's nearest facility.

Latency — The one-way time a packet takes to travel to a destination, usually measured in milliseconds. Round-trip time (RTT) — there and back — is roughly double.

NAT (Network Address Translation) — Sharing one public IP address across many private ones.

ONT (Optical Network Terminal) — The device that converts fiber light signals into electrical ones at your premises.

Packet — A small labeled chunk of data, the unit in which everything travels.

Peering — Two networks exchanging traffic directly, usually without payment.

POP (Point of Presence) — A local facility where an ISP aggregates subscriber traffic.

TCP (Transmission Control Protocol) — Adds reliability and ordering on top of IP.

TLS — The encryption layer behind HTTPS.

Transit — Paying a larger network to carry your traffic to the rest of the internet.

TTFB (Time To First Byte) — Time between sending a request and receiving the first byte of the response.

UDP (User Datagram Protocol) — A fast, unreliable alternative to TCP for real-time traffic.

Sources