You probably think the internet lives in the cloud. Something wireless, beamed down from satellites, floating somewhere above your head.
It doesn't.
Around 95% of all the data crossing oceans travels through actual cables sitting on the seabed. Glass cables, roughly the thickness of a human hair, lying in the dark thousands of metres underwater. When you load a site hosted in another country, your request goes down one of those cables and comes back. No magic. Just light moving through glass, very fast.
I work on websites and apps for businesses in Australia and across the GCC, and clients ask me the same thing all the time: "why does my site feel slow?" The honest answer is almost never their internet plan. It's one of the hidden layers below, the systems nobody sees but everybody depends on. Here's the tour.
It all runs on hair-thin glass
The core of a single fibre cable is about 8 to 10 micrometres wide. Thinner than a hair. Inside it, light travels at roughly two-thirds the speed it would in a vacuum, which means a signal crosses the 6,700 km between New York and London in about 30 to 35 milliseconds.
The numbers have gone somewhere absurd. In 1988, the first transatlantic fibre cable carried 280 megabits per second. A modern cable like Marea moves 160 terabits per second. That's roughly a millionfold jump, and lab setups have already hit petabits. There are over 400 active submarine cable systems out there, more than a million kilometres of them in total, engineered to survive 25-plus years of crushing pressure with signal repeaters every 50 to 100 km.
So the thing carrying nearly all the world's data is fragile glass that somehow outlasts everything else on the ocean floor. Not ideal for the fish. Great for the rest of us.
Satellites are catching up, sort of
Everyone assumes fibre is the fastest way to move data across the planet. Sometimes it isn't.
Low Earth Orbit satellites sit 500 to 1,200 km up. Close enough that a signal goes up and back in 30 to 50 milliseconds. Compare that to the old geostationary satellites parked at nearly 36,000 km, which need 500 to 600 milliseconds for a round trip. Ten times slower.
Here's the weird part. Light moves at 300,000 km per second in a vacuum but only 200,000 km per second inside glass. So for some long routes, bouncing data through space (faster medium, longer path) can actually beat sending it through undersea fibre (slower medium, shorter path). Your data leaves the planet to arrive faster.
Starlink had over 5,000 satellites running by the mid-2020s. For a farm or a remote site with no fibre, this changes everything. The catch: astronomers are unhappy about thousands of bright objects wrecking telescope views, and nobody's fully sure what happens when several satellite networks try to serve the same dense city from overhead at once.
Where networks meet and haggle
Ever wonder why traffic between two providers in the same city sometimes flies to another continent and back? The fix for that is an internet exchange point, or IXP.
An IXP is basically a big shared switch in a data centre where hundreds or thousands of networks plug in and hand traffic to each other directly. Think of a motorway interchange for data. The biggest ones, like DE-CIX in Frankfurt or AMS-IX in Amsterdam, push over 10 terabits per second at peak. More data than most countries produce in total.
Without a local IXP, two providers in the same country might route your packets through some third party on another continent, adding thousands of kilometres and tens of milliseconds for no good reason. With local peering, the same packets cross a single switch in a fraction of a millisecond. The gap between a snappy site and a sluggish one often comes down to whether your provider bothers to peer locally. This is exactly why hosting region matters so much in the GCC, something we dig into in Edge computing for web apps: why latency matters in the GCC.
The internet runs on an honour system
This one surprises people. The protocol that stitches all those independent networks together, BGP (Border Gateway Protocol), was built in 1989 with zero security. It just trusted that everyone telling it "I own these addresses" was being honest.
That is not ideal.
One typo from one operator can hijack huge blocks of the internet. In 2008, a Pakistani provider tried to block YouTube locally by announcing a more specific route. The announcement leaked worldwide, and YouTube vanished from the entire planet for hours. One config mistake, global blackout. Efforts to add proper cryptographic checks exist, but they roll out slowly. BGP is a necessary evil that somehow keeps working despite itself.
One address, hundreds of machines
You type 8.8.8.8 and you think you're hitting one specific Google server in California. You're not. You're being lied to, beautifully.
It's called anycast. Hundreds of physical machines scattered around the world all answer to the exact same IP address. Your device has no idea. It fires a packet at that address, and BGP quietly steers it to whichever machine is closest. Someone in Tokyo hits a server in Tokyo. Someone in London lands on a machine in London. Same number, different continent, different hardware.
The clever bit: if a whole data centre catches fire and drops offline, its announcement just disappears, and traffic automatically reroutes to the next nearest site. No downtime, no client changes. The internet heals around the hole. Bad for the data centre, great for everyone else.
The internet's invisible director
Most people call DNS the internet's phone book. That undersells it. DNS (Domain Name System) doesn't just turn names like dsrpt.com.au into addresses. It actively steers your traffic based on where you are, how busy a server is, or which version of a page you should see.
The real trick is caching. Your first lookup might add tens of milliseconds as it walks the whole hierarchy. After that, the answer is cached and returns in microseconds. This is also why DNS changes don't take effect everywhere instantly: each answer carries a "time to live", anywhere from 5 minutes to 24 hours, and resolvers hold the old address until that timer runs out. If you've ever moved a website and watched it slowly switch over for a day, that's why.
The two protocols holding it all together
Every page you load leans on two protocols working together: IP and TCP.
IP handles addresses and routing. It gets packets from A to B on a best-effort basis, which is a polite way of saying "we'll try, no promises." It doesn't care if your data arrives out of order, gets duplicated, or vanishes.
TCP fixes all of that. It chops your data into numbered pieces, checks they arrived, and resends anything that got lost. It also manages how fast to send so it doesn't flood the network. All of this happens silently inside your device's operating system while you browse.
And here's the part nobody thinks about: when a page loads slowly, it's often TCP, not your bandwidth. The retransmissions, the congestion control, the connection setup, that's frequently the real bottleneck. People blame their provider's speed when the protocol behaviour is what's costing them.
The padlock doesn't mean what you think
Almost every site now shows a little padlock. That's HTTPS doing its job: encrypting the connection so nobody between you and the server can read it.
When this took off, people assumed encrypting everything would slow the web to a crawl. It didn't. Modern encryption can finish its handshake in a single round trip, adding well under 100 milliseconds to your first request. A transatlantic round trip is already 60 to 80 milliseconds, so the encryption is basically a rounding error.
But here's where people get fooled. That padlock only means the connection is encrypted. It does not mean the site is safe, real, or trustworthy. A phishing site can have a perfect padlock and still steal your card. The whole system rests on certificate authorities being honest, and there have been incidents where they weren't. If you want the deeper version of why "secure" and "trustworthy" are not the same thing, we cover that mindset in Zero trust architecture explained for non-technical business owners.
Getting the data closer to you
When you stream a show or load a site, you probably picture the data coming from some distant server farm. Usually it isn't. The bytes are already sitting in your city, often inside your own provider's network, waiting. That's a CDN (content delivery network) at work.
The idea started with Akamai in 1998. Now players like Cloudflare and Fastly, plus in-house systems at Netflix and Google, run thousands of edge servers worldwide. For popular sites, a big share of the data is served from a cache in your own country rather than across an ocean. That drops round-trip times from hundreds of milliseconds to single digits, which is the difference between smooth 4K and constant buffering.
For any business serving customers across Australia and the GCC, this is one of the cheapest, highest-impact things you can do. It's a big part of how we pick the right web hosting for every client project and a core reason a properly built site on our website design and development work feels fast no matter where the visitor is.
The dark side: concentration. A huge slice of web traffic runs through a small number of CDNs. When one of them has a bad day, large chunks of the internet just vanish for hours. You've probably lived through one of those mornings without knowing the cause.
The traffic cop you never see
You type api.example.com and your request gets handled. Simple. But that single address is a lie too. Behind it could be two machines or 200, and something has to decide which one takes your request. That's the load balancer.
It watches every back-end server: response times, error rates, whether they're even alive. If one starts lagging or dies, the load balancer quietly stops sending it traffic and routes around the problem. No outage, no drama. Your next three requests might hit three completely different machines and you'd never notice.
And when a site feels slow, everyone blames the servers. Often it's a saturated load balancer choking the traffic while the servers behind it sit there doing nothing.
Where speed meets silicon
People think more RAM or a faster processor fixes slow load times. Usually the real bottleneck is storage.
A modern SSD answers a request in roughly 100 microseconds. A spinning hard drive takes around 10 milliseconds for the same thing, a hundred times slower. Fetch it from remote storage and you're into hundreds of milliseconds. So when a data centre keeps the popular stuff on SSDs, the difference is enormous.
Here's the number worth keeping: delays under 100 milliseconds feel instant to a human. An SSD cache hit lands a thousand times below that. You can't perceive it. It just registers as "already there." That feeling of instant is engineered, one cache layer at a time.
The final frontier: kill the distance
You can't cheat the speed of light. If your server is 5,000 km away and you need an answer, you're paying at least 50 milliseconds per round trip, no matter how good your connection is. Physics doesn't negotiate.
Edge computing found the loophole. Instead of trying to send signals faster, it moves the server closer to you. Rather than packing all the computing into a few giant data centres, you scatter smaller ones everywhere: at cell towers, in metro areas, inside provider networks. When you use a service, you're not talking to a machine in Virginia. You're talking to one 10 km away. That 50-millisecond delay drops to 5. For cloud gaming, AR, or industrial systems that need sub-20-millisecond responses, it's the line between possible and impossible.
It also handles data smarter. A factory floor with a thousand sensors spitting out gigabytes an hour doesn't need to ship all that to the cloud. An edge server filters and summarises it locally into a few megabytes of useful insight. The cloud gets what it needs, the local systems respond instantly, and nobody pays to ship raw noise across the planet.
The honest caveat: running thousands of small distributed sites is much harder than running three big ones. Every location needs power, cooling, security, and someone to fix it when the hardware dies. You trade simplicity for distributed chaos. And plenty of things people imagine "need" edge computing run perfectly well on a good CDN cache. If you want the practical, business-side version of this, Edge computing for web apps: why latency matters in the GCC is the place to start.
What this means for your business
You don't need to remember a single protocol name from this. Here's the part that actually matters when you're paying for a website or an app:
The speed your customers feel is mostly about distance and round trips, not their internet plan. Get your content close to them with a CDN. Host in or near the region you serve. Keep the number of back-and-forth handshakes low. Those three moves fix the vast majority of "my site feels slow" complaints, and none of them are exotic.
If you're not sure whether your current site is doing any of this, that's worth a look. We build sites and apps with this stuff baked in from day one, for clients across Australia and the GCC. Have a look at what we do on the DSRPT services page, or read how we pick the right web hosting for every client project to see how we think about it.