VPS-netwerk is meer dan alleen bandbreedte: gebruik ASN en retourpad om lijnkwaliteit te herkennen

Maak van netwerkkwaliteit een reproduceerbare data-audit.

Bijgewerkt 2026-08-16 · CloudWorth

ASNretourpadnetwerktestlijnauditVPS-prijs-kwaliteitCloudWorthSteal TimeVPS oversellingVPS benchmark

Alleen door ASN-herkomst, retourpad en latentiecruiscontrole te combineren, kun je de echtheid en premie van een lijn herkennen.

Wat de ASN-toewijzing kan onthullen

Bij het kopen van een VPS kijken de meesten eerst naar bandbreedtecijfers, maar er zijn te veel voorbeelden van \"gigabit-poorten\" die in de avondspits verworden tot een slideshow. Bandbreedte is slechts de limiet; de echte lijnkwaliteit hangt af van de route die het verkeer werkelijk neemt — het eerste wat je doet is de ASN-toewijzing controleren. Gebruik whois of een online ASN-querytool om de ASN van het IP te bekijken, en je kunt onmiddellijk zien tot welk datacenter of welke provider dit IP-blok behoort. Als een provider bijvoorbeeld \"CN2 GIA\" adverteert, maar de ASN blijkt gewoon Cogent of NTT te zijn, dan is er grote kans op valse reclame of NAT-doorverkoop.

Nog belangrijker is dat de ASN routeringsstrategieën kan blootleggen. Verschillende IP-blokken van dezelfde provider kunnen verschillende ASN's uitzenden, wat leidt tot grote verschillen in de terugroute voor de drie grote netwerken. Gebruik MTR om de ASN van elke hop te bekijken; als de route via de VS of via Europa omgaat, zijn de latentie en het pakketverlies uiteraard hoog. Dit verklaart ook waarom dezelfde VPS met verschillende IP-blokken een totaal verschillende ervaring kan geven. Bij het terugredeneren moet je ook de consistentie tussen Route Registry en WHOIS controleren, om te voorkomen dat de provider ASN-nummers vervalst.

Vanuit het perspectief van cloudkosten is de ASN-toewijzing direct gekoppeld aan de FinOps-premie. Hoogwaardige ASN's (zoals China Telecom 4134, China Unicom 9929) hebben veel hogere bandbreedtekosten dan gewone internationale lijnen; of deze premie in de prijsstelling van de provider redelijk is, kan via een ASN-audit worden geëvalueerd. Veel \"oververkochte\" machines beknibbelen en ruilen in voor goedkope upstream; dat zie je meteen aan de ASN. Gebruik de snelheidstesttool van deze site en combineer dat met ASN WHOIS, dan kun je de netwerkkwaliteit omzetten in een reproduceerbare data-audit. Als je ook de operationele risico's achter de cloudprovider wilt achterhalen, raadpleeg dan de gids voor het herkennen van cloudproviders en verifieer de echtheid van de lijn en de geloofwaardigheid van de provider samen.

Hoe meet je het retourpad

Het belangrijkste bij netwerksnelheidstests van een VPS is niet de bandbreedte, maar het retourpad. Splits eerst “heen” en “terug”: van lokaal naar VPS is heen, van VPS terug naar lokaal is terug. De meeste providers optimaliseren alleen het heenpad, en het retourpad dat omleidt via Amerika of Europa wordt dan zichtbaar. Gebruik MTR om continu pakketten te sturen en de latentie en het pakketverlies van elke hop te bekijken; dat is betrouwbaarder dan een eenmalige traceroute:

mtr -r -c 20 --no-dns <你的IP>

Let vervolgens vooral op de ASN-toewijzing van elke hop. Kijk niet alleen naar het IP; gebruik WHOIS of bgp.he.net om het ASN van het prefix van die hop op te zoeken en bepaal of de route via de verwachte node loopt. Bijvoorbeeld bij een toegang vanuit China Telecom: als het retourpad via AS4134 (Telecom) loopt, is dat normaal; als AS4809 of AS174 (Cogent) verschijnt, is er waarschijnlijk sprake van een omweg, en zullen latentie en pakketverlies duidelijk toenemen.

Valkuil: providers adverteren een “nep-ASN”. Controleer of de Route Registry en WHOIS overeenkomen; zo kun je afleiden of de route echt is.

Kruisverwijzing: dit is dezelfde forensische logica als bij de identificatie van cloudproviders. Je gebruikt ASN om de echtheid van de route te verifiëren, net zoals je met facturen de FinOps-premie controleert — vervang de geadverteerde “CN2/GIA” door het werkelijke retourpad om te weten of de premie de moeite waard is. Evenzo kan de aanpak voor het verlagen van specificaties die in /guides/cloud-serve wordt beschreven, worden onderbouwd met retourpadgegevens. Nadat je het retourpad hebt gemeten, kun je dat combineren met bandbreedte en latentie om de netwerkkwaliteit om te zetten in een reproduceerbare data-audit.

Hoe toon je een opgeblazen bandbreedte aan?

Bandbreedtecijfers zijn slechts een 'gevel'; wat de ervaring echt bepaalt is het pad. Om bewijs te verzamelen, splits je 'snelheidstest' eerst op in drie lagen: doorvoer, latentie en retourpad. Gebruik MTR of traceroute met 100 pakketten en noteer de ASN van elke hop. Het commando whois -h whois.radb.net -- '-i origin ASXXXX' kan de eigenaar achterhalen. Als een VPS 'CN2 GIA' beweert te zijn, maar de derde hop al naar Level3 of Telia gaat, is het waarschijnlijk een valse broadcast of half-route optimalisatie. Voer de test opnieuw uit tijdens de avondpiek (20:00–23:00) en kijk naar RTT-jitter en de locatie van pakketverlies: als het verlies geconcentreerd is bij een bepaalde provider peer-segment, duidt dit op QoS-beperking in plaats van netwerkcongestie.

Een hardere aanpak is het vergelijken van de consistentie tussen Route Registry en WHOIS. Sommige aanbieders adverteren ASN-prefixen die niet bestaan; gebruik bgpq4 of bgp.he.net om de routeringsbron te verifiëren, en het is direct ontmaskerd. Een ander verborgen punt: dezelfde VPS met verschillende IP-blokken kan een totaal tegenovergesteld retourpad hebben — de ene gaat via China Telecom 163, de andere via China Unicom CUVIP, afhankelijk van de upstream die de aanbieder voor elk blok heeft gekocht, niet 'willekeurig toegewezen'.

Vat deze gegevens samen in een tabel: ASN-eigenaar, retourpad, avondpiek-latentie, pakketverliespercentage, en vergelijk die met de productpagina van de aanbieder. Als er '1000Mbps' wordt beloofd, maar iperf3 single-thread slechts 30Mbps haalt en de TCP-venster klein is, dan is er sprake van beperking of oververkoop. Gebruik dan een VPS-netwerkbenchmarkscript om een standaard benchmark uit te voeren; het resultaat is reproduceerbaar.

Vergeet ten slotte niet om de onderzoeksresultaten om te zetten naar een kostperspectief: binnen dezelfde prijsklasse is een VPS met een route via de VS, zelfs met een grote bandbreedte, in werkelijke doorvoer veel duurder dan een directe verbinding — dit is precies de 'nepwinstmarge' die FinOps-premie eraf trekt. Hetzelfde geldt voor cloudproviderherkenning: de ASN-eigenaar en de retourpadkwaliteit bepalen of de aanbieder echt dedicated bandbreedte gebruikt, of gedeelde bandbreedte als dedicated verkoopt. De volgende keer dat iemand opschept over 'grote bandbreedte', vraag dan eerst om zijn ASN-tabel en het pakketverliespercentage tijdens de avondpiek.

Hoe congestie en throttling te bepalen

Hoe mooi de bandbreedtecijfers ook zijn, bij congestie tijdens de avondspits komt de waarheid bovendrijven. Om throttling te bepalen moet je niet alleen kijken naar de piek op Speedtest, maar naar het congestievenster – gebruik mtr gedurende 5 minuten en observeer het pakketverlies en de latency-jitter. Als de latentie van 20ms naar 200ms springt, vergezeld van 5%+ pakketverlies, kun je er vrij zeker van zijn dat er sprake is van congestie bij de upstream-peer of dat de provider QoS-throttling toepast.

Belangrijker is om de IP-eigenaar van elke hop te achterhalen:

for ip in $(mtr -r -c 10 8.8.8.8 | awk '{print $2}' | grep -v '^|' | tail -n +2); do whois $ip | grep -E 'origin|netname' | head -2; echo "---"; done

Vergelijk dit met de ASN- en Route Registry-gegevens. Als de provider CN2 GIA adverteert maar in de terugweg feitelijk ASN's van Level3 of Telia verschijnen, is het in acht van de tien gevallen een neplijn. Deze kruisverificatie helpt je om 'omhulde' VPS'en te herkennen – veel cloudproviders (vooral goedkope doorverkopers) geven gewone lijnen uit als geoptimaliseerde lijnen, maar een controle van de ASN-eigenaar doorziet dat direct.

Even een FinOps-perspectief: stel dat je 30% premie betaalt voor 'lage latentie', maar MTR toont aan dat de doorvoer bij congestie terugvalt tot een tiende, dan betaal je die premie eigenlijk aan de overboekende provider. Een machine die het waard is om te houden, heeft een stabiele terugweg-ASN, een verschil in latentie van minder dan 20ms tussen de drie netwerken en 0% pakketverlies tijdens de avondspits. Met deze methode auditen is een stuk betrouwbaarder dan het bestuderen van marketingpagina's.

Premiepercentage en aankoopbeslissingen

Wanneer de echtheid van een route wordt bevestigd door drie aspecten – ASN-toewijzing, retourpad en real-time latentie – is het "premiepercentage" geen mystiek. Ik pas doorgaans het FinOps-achtige kostperspectief toe op VPS-aankopen: eerst draai ik een vps network speed test (YABS-script volstaat), vervolgens gebruik ik mtr -z om de ASN van elke hop te achterhalen, gecombineerd met whois om de herkomst van de aankondiging te bevestigen, en tot slot voer ik een kruisvalidatie uit met het pakketverliespercentage van het retourpad gedurende drie opeenvolgende avondspitsen. Op deze manier komen de "premium netwerken" en "gewone routes" van aanbieders snel en duidelijk aan het licht.

Premiepercentage = (werkelijk gemeten doorvoer + retourtrajectkwaliteitsscore) / jaarlijkse kosten. Als een aanbieder bijvoorbeeld 1 Gbps bandbreedte claimt, maar de ASN laat zien dat de peers voornamelijk obscure IX'en zijn, het retourtraject via de VS loopt en het pakketverlies tijdens de avondspits 8% bedraagt, dan is die dienst slechts $20/jaar waard. Omgekeerd, als de ASN direct verbonden is met Telecom CN2, het retourtraject voor alle drie de netwerken direct is en packet loss bijna nul is, dan is het zelfs voor $60 extra de moeite waard. Vergeleken met vergelijkbare configuraties in de publieke cloud, helpt deze audit je om op het niveau van "cloudleverancier-identificatie" te doorzien of er een "lijnbelasting op goedgelovigheid" wordt geheven.

Beslissingschecklist:

• Controleer de ASN: whois -h whois.radb.net -- -i origin ASxxxxx, controleer of deze overeenkomt met de claims van de aanbieder
• Meet het retourtraject: mtr -r -c 100 -z doel-IP, controleer of de ASN van de laatste drie hops tot de backbone van de drie netwerken behoort
• Bereken de premie: bandbreedtegetal ÷ latentie × pakketverliesfactor, vervolgens gedeeld door de prijs, om een prijs-kwaliteitindex te krijgen

Vergeet ten slotte niet dat echte reputatie voortkomt uit reproduceerbare gegevens, niet uit schermafbeeldingen van de aanbieder. Archiveer de resultaten van elke test en raadpleeg bij de volgende keuze of downgrade direct de historische gegevens. Vergelijk daarnaast de basislijnen van de publieke cloud in /guides/cloud-serve om de premieruimte te verkleinen.