Misuralo da solo
Ogni dato di latenza su questo sito proviene dalle nostre sonde, che è esattamente il tipo di affermazione di cui non dovresti fidarti. Il looking glass gira su tutti i 34 siti, non richiede account e risponde all'unica domanda che conta: com'è realmente il percorso tra te e quella città in questo momento.
Costruisci il comando
Scegli un sito e uno strumento. Questi vengono eseguiti dalla tua macchina, verso i nostri host di test pubblicati, che è l'unica misurazione che ti dice qualcosa sul tuo percorso.
mtr -rwzbc 100 lg-ams-01.paragonvps.comUn file da 1 GB di dati casuali non comprimibili, per misurare la velocità effettiva piuttosto che il tuo compressore.
Esegui ciascuno di questi tre volte in orari diversi prima di trarre una conclusione. Un singolo traceroute durante la finestra di manutenzione di qualcun altro non è una prova.
Cos'è e cosa non è
Un host di sonda in ogni sito, sulla stessa VLAN della produzione, dietro lo stesso filtraggio.
Il looking glass è un piccolo host in ogni sito che esegue test per conto tuo e stampa l'output grezzo. Si trova sulla stessa rete delle istanze dei clienti e dietro lo stesso filtraggio di bordo, quindi ciò che misura è ciò che otterresti. Nessun percorso di test ottimizzato, nessun uplink separato, nessun angolo tranquillo del rack.
Non è un benchmark e non è uno strumento di marketing. Alcuni risultati sono poco lusinghieri: Sydney verso qualsiasi luogo è costosa in millisecondi, e Johannesburg sta ancora assestando il suo transito. Quei numeri sono lì perché nasconderli sarebbe inutile quando chiunque può eseguire il test.
Tutti i 34 siti, sempre
Inclusi i siti in pre-ordine. Johannesburg risponde alle sonde da prima che avesse una singola istanza pagante.
Nessun account, nessuna registrazione
Coerente con il resto del servizio. L'unico test che richiede qualcosa da te è iperf3, e serve un token solo per evitare che il server venga usato come sorgente di flood.
Limitato volutamente
Un test alla volta per indirizzo sorgente e quattro test al minuto. Un looking glass è uno splendido vettore di amplificazione se l'operatore non ci ha pensato.
I risultati sono tuoi
L'output è testo semplice con un permalink che dura trenta giorni. Incollalo in un ticket, o in una discussione con il team di rete di qualcun altro.
Cosa puoi eseguire
Cinque test, scelti perché rispondono a domande diverse. Eseguirli tutti dimostra poco; scegliere quello giusto di solito risolve la questione in un minuto.
Inizia con MTR, non con ping
Un singolo ping ti dice un solo momento. Trecento cicli MTR ti dicono se il percorso è cattivo, a volte cattivo, o buono e sei stato sfortunato.
Usa prima il file di test per il throughput
Un download da 1 GB via HTTPS riproduce ciò che fanno la maggior parte dei carichi di lavoro reali. Se quello è lento ma iperf3 è veloce, il problema è il controllo della congestione o i middlebox, non la capacità.
La MTU del percorso vale novanta secondi
Una sorprendente fetta di ticket come 'il sito si carica ma i caricamenti grandi si bloccano' finisce qui, di solito a un tunnel dimenticato tra te e noi.
| Test | La domanda a cui risponde | Limiti |
|---|---|---|
| Ping ICMP | È raggiungibile e qual è il tempo di andata e ritorno in questo momento | Fino a 100 pacchetti per esecuzione |
| Traceroute (ICMP e UDP) | Quali hop il percorso in avanti attraversa lasciando quel sito | Massimo 30 hop, 3 sonde per hop |
| MTR | Perdita e latenza per hop nel tempo invece che in un'unica istantanea | Fino a 500 cicli, circa 8 minuti |
| Target iperf3 | Quale throughput puoi realmente ottenere verso quel sito | Token del pannello, 60 secondi, fino a 4 flussi |
| File di test | Una risposta sulla throughput senza installare nulla | 100 MB e 1 GB su HTTPS |
| Sonda MTU del percorso | Se qualcosa nel mezzo sta mangiando pacchetti grandi | Riporta la dimensione più grande che sopravvive |
Leggere l'output senza interpretarlo male
L'output di traceroute non è un'immagine del tuo traffico. È un insieme di risposte da router che avevano cose migliori da fare, e leggerlo come un grafico di latenza produce conclusioni sicure ma errate.
La maggior parte dei reclami di routing che riceviamo è corretta sul sintomo e sbagliata sul hop.
I hop intermedi esagerano
Un router che risponde a una sonda traceroute lo fa sul suo piano di controllo, che è occupato e tratta ICMP come la priorità più bassa che possiede. Quando un hop mostra 180 ms e il successivo 14 ms, quel primo router era occupato, non il percorso davanti a sé.
Solo l'ultima riga è reale
La perdita che appare al hop sei e sparisce al hop sette è risposte con limite di velocità, non traffico perso. Quando inizia al hop sei e continua fino alla destinazione, inviaci l'output.
Il reverse DNS è un indizio
I codici aeroportuali nei nomi dei hop sono spesso stantii da anni. Trattali come un'indicazione di intento di chi ha nominato l'interfaccia, mai come prova di geografia.
MPLS nasconde il mezzo
I percorsi che attraversano un core con commutazione di etichetta possono sembrare tre hop più corti di quanto siano. La latenza c'è ancora; manca solo l'onestà sulla sua origine.
La fisica impone il minimo
Amsterdam-Singapore è circa 168 ms e nessuna quantità di peering lo migliorerà in modo significativo. Se la tua misurazione è vicina alla nostra cifra pubblicata, il percorso funziona correttamente e la risposta è un secondo sito, non un ticket.
Route asimmetriche, dove vive la confusione
Un traceroute misura il percorso in avanti e nient'altro. Ogni numero in esso, però, include il viaggio di ritorno della risposta di quel hop, e il viaggio di ritorno può prendere una rotta completamente diversa attraverso il pianeta.
Il traffico da noi a te e quello da te a noi sono decisioni separate prese da reti separate. Noi scegliamo cosa esce; le reti in mezzo scelgono cosa torna. La maggior parte degli operatori consegna il traffico alla prima occasione, quindi il tuo percorso di ritorno spesso lascia il tuo provider in una città diversa da quella in cui il nostro percorso è entrato.
La conseguenza visibile è un hop che sembra lento mentre il tuo traffico reale è a posto. Peggiore è quella invisibile: la congestione sul percorso di ritorno si manifesta come latenza che passerai un pomeriggio a cercare nella direzione in avanti.
Misura sempre entrambe le direzioni
MTR dalla tua macchina all'istanza e MTR dal looking glass di quel sito verso il tuo indirizzo, idealmente in esecuzione contemporanea. Metà delle prove produce mezza risposta.
L'asimmetria da sola non è un difetto
Quasi ogni percorso su internet è asimmetrico e quasi tutti funzionano. Diventa un problema solo quando una direzione è congestionata, perde pacchetti o attraversa un box di filtraggio con stato.
Possiamo influenzare solo cosa torna
La nostra policy di routing controlla direttamente la direzione in uscita. Il percorso di ritorno cambia solo se annunciamo in modo diverso, consegniamo da un'altra parte o chiediamo gentilmente a un peer. Tutte e tre le cose sono possibili; nessuna è istantanea.
I middlebox stateful odiano l'asimmetria
Se si esegue un firewall che si aspetta di vedere entrambe le direzioni di un flusso e il percorso di ritorno smette di attraversarlo, si ottengono reset intermittenti che sembrano esattamente un guasto di rete. Controlla questo prima di incolpare qualcuno.
Presentare un reclamo di routing che venga preso in considerazione
La prima risposta mediana a un ticket è di 11 minuti. Una correzione del routing richiede più tempo, perché qualcun altro deve essere d'accordo.
- 01
Escludi la tua stessa istanza
Controlla carico, connection tracking, contatori dell'interfaccia dell'istanza stessa e se qualche regola di filtro tua sta scartando traffico. Qualcosa come un rapporto su cinque finisce qui, e finisce più velocemente se guardi prima tu.
- 02
Raccogli entrambe le direzioni
Almeno 300 cicli MTR dal tuo lato e 300 dal looking glass in quel sito, eseguiti nella stessa finestra temporale. Allega il permalink piuttosto che uno screenshot; ci servono i numeri, non un'immagine di essi.
- 03
Timestamp corretto
UTC o offset esplicito. "Questa mattina" descrive un momento per te e un intervallo di undici ore per noi, e correlare i dati di flusso a questo è un'indovinello.
- 04
Di' cosa è cambiato e quando
È sempre stato così, o è iniziato martedì. Continuo, o tra le 20:00 e le 23:00 ora locale. Questa singola frase di solito decide se stiamo guardando a un cambio di peering o alla congestione serale di qualcuno.
- 05
Invialo al supporto
Invia una mail a [email protected] o apri un ticket nel pannello. Qualsiasi cosa che si riveli un vero problema di percorso viene inoltrata al team di rete nella stessa ora, e ti viene detto cosa abbiamo chiesto all'altra rete.
Cosa possiamo fare: reindirizzare, de-preferenziare un transito, chiedere a un peer di indagare, o spostarti in un sito con una rotta migliore. La congestione all'interno di una rete che non tocchiamo è al di là di tutte e quattro le opzioni, e in quel caso ti instradiamo aggirando il problema piuttosto che passare una settimana ad avere ragione.
Domande sul looking glass
Per sessanta secondi alla volta, sì. Il token esiste per evitare che l'host diventi la sorgente di flood di qualcuno, non per razionare una misurazione onesta. Test prolungati richiedono la tua istanza su entrambe le estremità.
Non dovrebbe, e se lo fa vorremmo saperlo. L'host di test si trova sulla stessa VLAN ed eredita la stessa policy. Una differenza genuina di solito significa una policy per-prefix applicata al tuo indirizzo, che merita un ticket.
Non sul looking glass pubblico. Chiedi in un ticket con un prefisso specifico e una ragione, e otterrai la risposta, incluso quale upstream stiamo preferendo per esso e perché.
Entro i limiti di velocità, sì; i test sono in uscita e innocui a quel volume. Usarlo come sorgente di misurazione per un target che non controlli va bene. Come componente di qualcosa di più grande, no.
Trenta giorni, poi scadono insieme all'output memorizzato. Allegalo a un ticket mentre ancora risolve, o incolla il testo, che preferiamo comunque.
Esegui il test, poi scegli la città
La latenza che misuri tu batte quella pubblicata da qualcun altro. Una volta che i numeri hanno senso, l'indice delle posizioni ha lo stock, l'uplink e la capacità di filtraggio per ogni sito.