Waarom Sydney altijd ver weg is
Een ping naar een server in Amsterdam komt vanaf mijn thuisverbinding binnen 14 milliseconden terug. Dezelfde ping naar Sydney doet er 316 over. Er is niets stuk. Dat getal komt grotendeels uit de natuurkunde, en de rest uit de manier waarop het internet over de zeebodem is gelegd.
Hieronder breken we die 316 milliseconden stap voor stap af. Alle meetwaarden zijn gemeten op 24 september 2026 vanaf een Nederlandse verbinding, met ping, traceroute en curl naar de publieke testservers van hostingpartij Vultr.
$ ping syd-au-ping.vultr.com
round-trip min/avg/max = 316.1/321.4/325.9 ms
316 milliseconden
ping syd-au-ping.vultr.com stuurt tien ICMP-echo's naar Sydney. De snelste komt na 316,1 ms terug, de traagste na 325,9 ms. Die spreiding is klein: er zit een harde ondergrens onder.
Ping meet de round-trip time (RTT): heen én terug. Dat is de maat die telt, want bijna elk protocol wacht op een antwoord voordat het verdergaat.
Zelfs licht is niet snel genoeg
De kortste weg over de aardbol van Amsterdam naar Sydney, de grootcirkel, is ongeveer 16.600 km. Licht in vacuüm legt 299.792 km per seconde af. Heen en terug is dat 33.200 km, en dat kost licht al 111 ms.
Dat is de absolute bodem. Geen provider of dikkere lijn krijgt een antwoord uit Sydney sneller terug. Een derde van onze 316 ms zit al vast voordat er ook maar één kabel in het spel is.
Glas is trager dan vacuüm
Internetverkeer reist niet door vacuüm maar door glasvezel. Glas heeft een brekingsindex van ongeveer 1,47, dus licht gaat er zo'n 32 procent langzamer doorheen: circa 204.000 km/s. Handig als vuistregel: in glasvezel kost elke 100 km afstand ongeveer 1 ms RTT.
Over de rechte lijn naar Sydney wordt het minimum daarmee 163 ms. Dat is de ondergrens voor elke echte verbinding over glas. Radio door de lucht is sneller, en daarom leggen beurshandelaren straalverbindingen aan tussen hun datacenters. Een oceaan oversteken doe je zo niet.
Kabels volgen de zeebodem, niet de grootcirkel
De grootcirkel loopt over Rusland, Kazachstan en China. Kabels liggen ergens anders. Vrijwel al het intercontinentale verkeer gaat door zeekabels, volgens TeleGeography zo'n 570 systemen die in bedrijf zijn. Ze volgen kustlijnen en komen alleen aan land bij een landingsstation.
Naar Sydney zijn er grofweg twee richtingen. Oostwaarts via de Middellandse Zee, over land door Egypte, de Rode Zee, India en Singapore, en dan met Indigo via Perth naar Sydney. Westwaarts over de Atlantische Oceaan, dwars door de VS en met de Southern Cross-kabel via Hawaï en Fiji naar Sydney. Beide routes zijn schematisch al ruim 21.000 km: minimaal 211 tot 221 ms RTT, en de echte tracés kronkelen meer dan onze lijnen.
Welke kant op? Dat beslist BGP
Jij kiest de route niet, en de kortste afstand ook niet. Providers wisselen routes uit via BGP en kiezen vooral op wat het ze kost. traceroute laat zien dat het verkeer van mijn provider naar backbone-partij GTT gaat, en de eerstvolgende hop die antwoordt is cr4-syd1.gtt.net, al in Sydney, op 316 ms.
Wat daartussen zit, blijft verborgen. Backbones sturen verkeer vaak door MPLS-tunnels waarin de TTL niet wordt verlaagd. De routers daarbinnen verschijnen dan helemaal niet in je traceroute: in de uitvoer springt het pakketje binnen twee hops van Amsterdam naar Sydney. Welke oceaan het pakketje overstak, zie je dus niet. Op de kaart volgen we als voorbeeld de westroute.
Waar blijven de milliseconden?
Tel het na. 163 ms is natuurkunde over de rechte lijn. De kabelroute kost ongeveer 58 ms extra, omdat hij zo'n 22.500 km lang is in plaats van 16.600 km. Mijn eigen aansluiting (Wi-Fi, kabelmodem, het netwerk van de provider tot Amsterdam) is goed voor ongeveer 14 ms: zoveel kost een ping naar een server in Amsterdam.
Er blijft zo'n 81 ms over. Die gaat op aan het verschil tussen echte en schematische kabelroutes, aan omwegen tussen netwerken, aan wachtrijen in routers en aan het doorsturen van pakketten door apparatuur. Dat laatste kost per router meestal microseconden, de wachtrijen kunnen oplopen tot milliseconden. De optische versterkers die in zeekabels om de 40 à 90 km zitten, vertragen het signaal nauwelijks.
Een ping is nog geen webpagina
Een webpagina ophalen kost meer dan één rondje. Eerst de TCP-handshake: één RTT. Dan TLS 1.3: nog één. Pas daarna gaat het HTTP-verzoek de deur uit, en dat is de derde. Met curl gemeten: de TCP-verbinding naar Sydney staat na 325 ms, TLS is rond na 656 ms en de eerste byte komt binnen na 987 ms. Naar Amsterdam is dat 68 ms.
Bijna een seconde voor één byte. En dan tellen DNS en de voorzichtige start van TCP, dat per rondje eerst maar een paar pakketten verstuurt, nog niet eens mee.
Speel zelf
Kies hierboven een bestemming. Je ziet de grootcirkelafstand, het theoretische minimum over glas en de laagste RTT die ik vanaf mijn aansluiting heb gemeten.
Singapore en New York zitten op 1,8 keer het minimum: daar liggen de kabels redelijk recht. Tokyo zit op 3 keer, en dat past niet bij een rechte route. Londen scoort 6 keer, maar daar is het absolute verschil maar 18 ms, en dat is vooral mijn eigen aansluiting. Voor korte afstanden bepaalt je eigen netwerk de latency, voor lange afstanden de aardbol.
Waarom je dit niet wegkoopt
Bandbreedte kun je kopen, met meer vezelparen of een duurder abonnement. Latency niet. Een 10 Gbit-lijn naar Sydney heeft dezelfde 163 ms ondergrens als een 10 Mbit-lijn. Daarom zetten grote diensten hun servers dicht bij de gebruiker. Een CDN met een knooppunt in Sydney haalt de oceaan uit het rondje, en QUIC en TLS 1.3 zijn zo ontworpen dat er minder rondjes nodig zijn.
Een TCP-verbinding over een lange lijn heeft een groot venster nodig om de lijn vol te krijgen: bandbreedte maal RTT. Voor 1 Gbit/s over 316 ms is dat bijna 40 MB aan data die tegelijk onderweg is. Staat er ergens een te kleine buffer, dan haal je die snelheid nooit.
Zelf proberen
Een ping naar een paar vaste testservers:
ping -c 10 ams-nl-ping.vultr.com
ping -c 10 syd-au-ping.vultr.com
Kijk naar de min, niet naar het gemiddelde: de laagste waarde ligt het dichtst bij de fysieke ondergrens. Wil je zien waar het pakketje langskomt, gebruik dan traceroute of, beter nog, mtr, dat per hop blijft meten:
traceroute -I syd-au-ping.vultr.com
mtr -rwc 20 syd-au-ping.vultr.com
En om te zien wat die rondjes kosten bij een echte HTTPS-verbinding:
curl -s -o /dev/null -r 0-0 \
-w 'tcp %{time_connect} tls %{time_appconnect} eerste byte %{time_starttransfer}\n' \
https://syd-au-ping.vultr.com/vultr.com.100MB.bin
Met -r 0-0 vraag je alleen de eerste byte op, zodat je niet per ongeluk 100 MB binnenhaalt.
Tot slot
Wat ik mooi vind aan dit onderwerp: de grootste post in de rekensom is een natuurconstante. Je kunt protocollen slimmer maken en servers dichterbij zetten, maar tussen Amsterdam en Sydney ligt minimaal 163 ms glas, en dat blijft zo. Als iemand in een overleg vraagt of die verbinding met Australië "niet wat sneller kan", heb ik nu tenminste een kaartje om te laten zien.