La rete VPS non è solo banda: usa ASN e percorso di ritorno per riconoscere la vera linea

Trasforma la qualità della rete in un audit riproducibile.

Aggiornato 2026-08-16 · CloudWorth

ASNpercorso di ritornotest di velocità di reteaudit di linearapporto qualità-prezzo VPSCloudWorthSteal TimeOverselling VPSBenchmark VPS

Solo incrociando ASN, percorso di ritorno e latenza si riconoscono l'autenticità della linea e i sovrapprezzi.

Cosa può rivelare l'attribuzione ASN

Quando si acquista un VPS, tutti guardano prima i numeri di banda, ma i casi di "porta gigabit" che si riduce a una presentazione PowerPoint nelle ore di punta serali sono fin troppi. La banda è solo il limite superiore; la vera qualità della linea dipende dal percorso effettivo del traffico: la prima cosa da fare è controllare l'attribuzione ASN. Usando whois o strumenti di query ASN online per verificare l'ASN dell'IP, si può capire immediatamente a quale data center o operatore appartiene quel blocco IP. Ad esempio, se un provider promette "CN2 GIA" ma l'ASN risulta essere normale Cogent o NTT, allora con tutta probabilità si tratta di pubblicità ingannevole o rivendita NAT.

Ancora più importante, l'ASN può rivelare le policy di routing. Lo stesso provider può annunciare ASN diversi per diversi blocchi IP, causando enormi differenze nei percorsi di ritorno delle tre reti principali. Usando MTR per osservare l'ASN di ogni hop, se il percorso passa per gli Stati Uniti o per l'Europa, latenza e perdita di pacchetti saranno naturalmente elevate. Questo spiega anche perché lo stesso modello di VPS può offrire esperienze completamente diverse a seconda del blocco IP. Nel fare verifiche a ritroso, è necessario anche confrontare la coerenza tra Route Registry e WHOIS, per prevenire che il provider falsifichi i numeri ASN.

Dal punto di vista dei costi cloud, l'attribuzione ASN è direttamente collegata al premio FinOps. La larghezza di banda di ASN di alta qualità (come Telecom 4134, Unicom 9929) ha costi molto superiori rispetto alle normali linee internazionali; se questo premio nel prezzo del provider sia ragionevole può essere valutato tramite un audit ASN. Molte macchine "overselling" tagliano i costi sostituendo l'upstream con alternative economiche, e l'ASN lo rivela al primo sguardo. Usa lo strumento di speed test del sito e combinalo con il WHOIS ASN per trasformare la qualità della rete in un audit dati riproducibile. Se vuoi anche identificare i rischi operativi dietro i provider cloud, puoi fare riferimento alla Guida all'identificazione dei provider cloud, incrociando l'autenticità delle linee e l'affidabilità dei fornitori.

Come misurare il percorso di ritorno

La chiave del test di velocità di rete di un VPS non è la larghezza di banda, ma il percorso di ritorno. Prima di tutto, distingui tra 'percorso di andata' e 'percorso di ritorno': dal locale al VPS è il percorso di andata, dal VPS al locale è il percorso di ritorno. Molti provider ottimizzano solo il percorso di andata, così il percorso di ritorno che passa per gli Stati Uniti o per l'Europa diventa evidente. Usare MTR per inviare pacchetti in modo continuo e osservare latenza e perdita di pacchetti a ogni salto è più affidabile di un singolo traceroute:

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

Successivamente, concentrati sull'ASN di ogni salto. Non guardare solo l'IP; usa WHOIS o bgp.he.net per verificare l'ASN del prefisso di quel salto, per capire se passa attraverso i nodi previsti. Ad esempio, per un accesso da China Telecom, se il percorso di ritorno passa per AS4134 (Telecom), è normale; se invece compaiono AS4809 o AS174 (Cogent), molto probabilmente c'è un aggiramento, e latenza e perdita di pacchetti aumenteranno notevolmente.

Trappola: i provider annunciano 'ASN falsi'. Verifica se il Route Registry e il WHOIS sono coerenti; questo può rivelare se il routing è reale.

Incrociando le informazioni: questa è la stessa logica forense dell'identificazione dei cloud provider. Usi l'ASN per verificare l'autenticità della rotta, proprio come usi le fatture per controllare il tasso di premio FinOps: sostituisci il 'CN2/GIA' pubblicizzato con il percorso di ritorno effettivo per capire se il sovrapprezzo vale la pena. Allo stesso modo, le idee di riduzione della configurazione descritte in /guides/cloud-serve possono essere supportate dai dati del percorso di ritorno. Dopo aver misurato il percorso di ritorno, aggiungendo larghezza di banda e latenza, puoi trasformare la qualità della rete in un audit di dati riproducibile.

Come dimostrare la falsa dichiarazione di banda

I numeri di banda sono solo una "facciata"; ciò che determina davvero l'esperienza è il percorso. Per raccogliere prove, scomponi il "test di velocità" in tre livelli: throughput, latenza e percorso di ritorno. Usa MTR o traceroute per inviare 100 pacchetti, registrando l'ASN di ogni hop: il comando whois -h whois.radb.net -- '-i origin ASXXXX' può risalire alla proprietà; se un VPS afferma di essere "CN2 GIA", ma già al terzo hop salta su Level3 o Telia, molto probabilmente si tratta di una falsa diffusione (false broadcast) o di un'ottimizzazione solo parziale del percorso. Esegui di nuovo il test durante le ore di punta serali (20:00–23:00), osservando il jitter del RTT e la posizione della perdita di pacchetti: se la perdita si concentra in un segmento di peering di un operatore, indica un limite di QoS piuttosto che congestione della rete.

Un approccio più avanzato consiste nel confrontare la coerenza tra Route Registry e WHOIS. Alcuni fornitori annunciano prefissi ASN inesistenti; usando bgpq4 o bgp.he.net per verificare l'origine della rotta, il trucco viene subito a galla. Un altro punto subdolo: per lo stesso modello di VPS, IP in intervalli diversi possono avere percorsi di ritorno completamente opposti – uno passa per Telecom 163, l'altro per Unicom CUVIP. Ciò dipende dall'upstream che il fornitore ha acquistato per ogni intervallo, non da una "assegnazione casuale".

Raccogli questi dati in una tabella: attribuzione dell'ASN, percorso di ritorno, latenza nelle ore di punta serali, tasso di perdita di pacchetti, poi confrontali con la descrizione della pagina di prodotto del fornitore. Se viene dichiarato "1000Mbps" ma iperf3 in single-thread raggiunge solo 30Mbps e la finestra TCP è minuscola, allora si tratta di limitazione della velocità o overselling. In tal caso, esegui un benchmark standard con lo script di test di velocità per VPS; il risultato è riproducibile.

Infine, non dimenticare di convertire i risultati delle prove in una prospettiva di costi: a parità di prezzo, un VPS con routing che passa per gli Stati Uniti, anche se ha una banda maggiore, ha un costo di throughput effettivo molto più alto rispetto a una connessione diretta – questo è esattamente il "tasso di profitto fittizio" che il tasso di premio FinOps deve sottrarre. Lo stesso vale per l'identificazione dei provider cloud: l'attribuzione dell'ASN e la qualità del percorso di ritorno indicano se il venditore utilizza davvero banda dedicata o se sta spacciando banda condivisa. La prossima volta che qualcuno vanta una "banda enorme", chiedigli prima di mostrare la tabella ASN e il tasso di perdita di pacchetti nelle ore di punta serali.

Come giudicare congestione e limiti di velocità

Per quanto i numeri di banda siano attraenti, la congestione nelle ore di punta serali rivela la verità. Per giudicare la limitazione della velocità non basta guardare il picco istantaneo di Speedtest; bisogna osservare la finestra di congestione — usando mtr per 5 minuti continui, monitorando il tasso di perdita di pacchetti e la variazione di latenza (jitter). Se la latenza passa da 20ms a 200ms con una perdita di pacchetti del 5% o superiore, si può concludere che c'è congestione del peer a monte o che il provider ha applicato un QoS limitante.

Ancora più importante è verificare la proprietà dell'IP di ogni salto:

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

Confronta i registri ASN e Route Registry. Se il venditore pubblicizza CN2 GIA, ma nel percorso di ritorno effettivo compaiono ASN di Level3 o Telia, molto probabilmente si tratta di una linea falsa. Questa verifica incrociata ti aiuta a riconoscere i VPS 'camuffati' — molti cloud provider (soprattutto rivenditori a basso costo) spacciano linee normali per linee ottimizzate; un controllo dell'attribuzione ASN li smaschera.

Per inciso, dal punto di vista FinOps: supponi di aver pagato un premio del 30% per la 'bassa latenza', ma MTR mostra che in caso di congestione il throughput scende a un decimo; in realtà questo premio è andato a favore del venditore che ha oversold. Le macchine che valgono davvero la pena di mantenere sono quelle con ASN di ritorno stabile, differenza di latenza tra le tre reti inferiore a 20ms e perdita di pacchetti pari a 0 nelle ore di punta. Usare questo metodo per l'audit è molto più affidabile che guardare le pagine pubblicitarie dei venditori.

Premio di prezzo e decisioni di acquisto

Quando l'autenticità della linea è confermata da tre fattori — attribuzione ASN, percorso di ritorno e latenza in tempo reale — il "premio di prezzo" non è più una questione esoterica. Di solito applico una prospettiva di costo in stile FinOps all'acquisto di VPS: prima eseguo un vps network speed test (basta lo script YABS), poi uso mtr -z per estrarre l'ASN di ogni hop, combino con whois per confermare l'origine della diffusione, e infine incrocio i dati con il tasso di perdita di pacchetti del return path per tre giorni consecutivi nelle ore di punta serali. Con questo processo, le "reti premium" e le "linee ordinarie" dei fornitori vengono messe a nudo.

Premio di prezzo = (throughput effettivamente misurato + punteggio di qualità del percorso di ritorno) / costo annuale. Ad esempio, se un fornitore dichiara una banda di 1 Gbps, ma l'ASN mostra che i suoi peer sono per lo più IX di nicchia, il percorso di ritorno passa dagli Stati Uniti e la perdita di pacchetti nelle ore di punta serali è dell'8%, allora vale solo $20/anno; al contrario, se l'ASN è direttamente connesso a China Telecom CN2, il percorso di ritorno è diretto sulle tre reti principali e il packet loss tende a zero, anche se costa $60 in più, conviene. Rispetto a configurazioni simili sul cloud pubblico, questo tipo di audit ti aiuta a capire a livello di "identificazione del fornitore cloud" se stai pagando una "tassa sull'intelligenza della linea".

Lista di controllo:

• Verifica ASN: whois -h whois.radb.net -- -i origin ASxxxxx, confronta con quanto dichiarato dal fornitore
• Test del percorso di ritorno: mtr -r -c 100 -z IP_destinazione, controlla se l'ASN degli ultimi tre hop è quello delle backbone delle tre reti principali
• Calcolo del premio: larghezza di banda ÷ latenza × fattore di perdita di pacchetti, poi dividi per il prezzo per ottenere l'indice di convenienza

Infine, non dimenticare che la vera reputazione deriva da dati riproducibili, non da screenshot dei fornitori. Archivia i risultati di ogni test e, al prossimo acquisto o downgrade, recupera direttamente lo storico, confrontandolo con il benchmark del cloud pubblico in /guides/cloud-serve per restringere il margine del premio.