Mesurez-le vous-même
Chaque chiffre de latence sur ce site provient de nos propres sondes, ce qui est exactement le genre d'affirmation que vous ne devriez pas prendre au pied de la lettre. Le looking glass s'exécute depuis les 34 sites, ne nécessite pas de compte, et répond à la seule question qui compte : à quoi ressemble réellement le chemin entre vous et cette ville en ce moment ?
Construire la commande
Choisissez un site et un outil. Ces commandes s'exécutent depuis votre machine, vers nos hôtes de test publics, ce qui est la seule mesure qui vous renseigne sur votre propre chemin.
mtr -rwzbc 100 lg-ams-01.paragonvps.comUn fichier de 1 Go de données aléatoires incompressibles, pour mesurer le débit plutôt que votre compresseur.
Exécutez chacune de ces commandes trois fois à des heures différentes avant de tirer une conclusion. Un seul traceroute pendant la fenêtre de maintenance de quelqu'un d'autre n'est pas une preuve.
Ce que c'est, et ce que ce n'est pas
Un hôte sonde à chaque site, sur le même VLAN que la production, derrière le même filtrage.
Le looking glass est un petit hôte dans chaque site qui exécute des tests en votre nom et affiche la sortie brute. Il se trouve sur le même réseau que les instances clientes et derrière le même filtrage de périphérie, donc ce qu'il mesure est ce que vous obtiendriez. Pas de chemin de test optimisé, pas d'uplink séparé, pas de coin tranquille du rack.
Ce n'est pas un benchmark et ce n'est pas un outil marketing. Certains résultats sont peu flatteurs : Sydney vers n'importe où coûte cher en millisecondes, et Johannesburg règle encore son transit. Ces chiffres sont là parce que les cacher serait inutile quand tout le monde peut exécuter le test.
Les 34 sites, tout le temps
Y compris les sites en précommande. Johannesburg répond aux sondes depuis avant d'avoir une seule instance payante dessus.
Pas de compte, pas d'inscription
Conforme au reste du service. Le seul test qui nécessite quelque chose de votre part est iperf3, et cela nécessite un jeton uniquement pour empêcher la machine d'être utilisée comme source d'inondation.
Limité en débit, délibérément
Un test à la fois par adresse source et quatre tests par minute. Un looking glass est un joli vecteur d'amplification si l'opérateur n'y a pas pensé.
Les résultats sont à vous
La sortie est en texte brut avec un permalien qui vit trente jours. Collez-le dans un ticket, ou dans une dispute avec l'équipe réseau de quelqu'un d'autre.
Ce que vous pouvez exécuter
Cinq tests, choisis parce qu'ils répondent à différentes questions. Tous les exécuter prouve peu ; choisir le bon règle généralement la question en une minute.
Commencez par MTR, pas par ping
Un seul ping ne renseigne que sur un instant donné. Trois cents cycles MTR indiquent si la route est mauvaise, parfois mauvaise, ou bonne et que vous avez simplement eu de la malchance.
Utilisez d'abord le fichier de test pour le débit
Un téléchargement de 1 Go en HTTPS reproduit ce que font la plupart des charges de travail réelles. S'il est lent alors qu'iperf3 est rapide, le problème vient du contrôle de congestion ou des middleboxes plutôt que de la capacité.
Le PMTU (Maximum Transmission Unit de chemin) mérite quatre-vingt-dix secondes
Une part surprenante des tickets « le site se charge mais les téléchargements volumineux restent bloqués » se termine ici, généralement à cause d'un tunnel oublié entre vous et nous.
| Test | La question à laquelle il répond | Limites |
|---|---|---|
| Ping ICMP | Est-il joignable, et quel est le temps aller-retour en ce moment | Jusqu'à 100 paquets par exécution |
| Traceroute (ICMP et UDP) | Quels sauts le chemin aller emprunte-t-il depuis ce site | 30 sauts maximum, 3 sondes par saut |
| MTR | Perte et latence par saut dans le temps au lieu d'un instantané | Jusqu'à 500 cycles, environ 8 minutes |
| Cible iperf3 | Quel débit vous pouvez réellement obtenir vers ce site | Jeton du panneau, 60 secondes, jusqu'à 4 flux |
| Fichier de test | Une réponse en débit sans installer quoi que ce soit | 100 Mo et 1 Go en HTTPS |
| Sonde MTU de chemin | Si quelque chose au milieu absorbe les gros paquets | Rapporte la plus grande taille qui survit |
Lire la sortie sans la mal interpréter
La sortie de traceroute n'est pas une image de votre trafic. C'est un ensemble de réponses de routeurs qui avaient mieux à faire, et la lire comme un graphique de latence produit des conclusions fausses et assurées.
La plupart des plaintes de routage que nous recevons sont correctes sur le symptôme et erronées sur le saut.
Les sauts intermédiaires exagèrent
Un routeur qui répond à une sonde traceroute le fait sur son plan de contrôle, qui est occupé et traite l'ICMP comme la priorité la plus basse qu'il possède. Lorsqu'un saut affiche 180 ms et le suivant 14 ms, c'est que le premier routeur était occupé, pas le chemin devant lui.
Seule la dernière ligne compte
Une perte qui apparaît au sixième saut et disparaît au septième est une limitation du taux de réponse, pas une perte de trafic. Lorsqu'elle commence au sixième saut et se poursuit jusqu'à la destination, envoyez-nous la sortie.
Le reverse DNS est un indice
Les codes d'aéroport dans les noms de sauts sont souvent obsolètes depuis des années. Traitez-les comme une indication de l'intention de celui qui a nommé l'interface, jamais comme une preuve de géographie.
MPLS masque le milieu
Les chemins traversant un cœur commuté par étiquettes peuvent sembler trois sauts plus courts qu'ils ne le sont en réalité. La latence est toujours là ; seule l'honnêteté sur son origine manque.
La physique fixe le plancher
Amsterdam à Singapour fait environ 168 ms et aucun peering ne pourra améliorer cela de manière significative. Si votre mesure est proche de notre chiffre publié, le chemin fonctionne correctement et la réponse est un second site plutôt qu'un ticket.
Les routes asymétriques, là où vit la confusion
Un traceroute mesure le chemin aller et rien d'autre. Chaque nombre qu'il contient inclut cependant le trajet retour de la réponse de ce saut, et le trajet retour peut prendre une route entièrement différente à travers la planète.
Le trafic de nous vers vous et le trafic de vous vers nous sont des décisions distinctes prises par des réseaux distincts. Nous choisissons ce qui part ; les réseaux intermédiaires choisissent ce qui revient. La plupart des opérateurs échangent le trafic à la première occasion, donc votre chemin de retour quitte souvent votre fournisseur dans une ville différente de celle où notre chemin y est entré.
La conséquence visible est un saut qui semble lent alors que votre trafic réel va bien. Pire est la conséquence invisible : la congestion sur le chemin de retour se manifeste sous forme de latence que vous passerez un après-midi à chercher dans le sens aller.
Mesurez toujours les deux directions
MTR depuis votre machine vers l'instance, et MTR depuis le looking glass de ce site vers votre adresse, idéalement en même temps. La moitié des preuves produit une demi-réponse.
L'asymétrie en soi n'est pas un défaut
Presque tous les chemins sur Internet sont asymétriques et presque tous fonctionnent. Cela ne devient un problème que lorsqu'une direction est congestionnée, perd des paquets ou traverse une boîte de filtrage qui garde un état.
Nous ne pouvons influencer que ce qui revient
Notre politique de routage contrôle directement la direction sortante. Le chemin de retour ne change que si nous annonçons différemment, échangeons ailleurs, ou demandons gentiment à un pair. Les trois sont possibles ; aucun n'est instantané.
Les middleboxes avec état détestent l'asymétrie
Si vous exécutez un pare-feu qui attend de voir les deux directions d'un flux et que le chemin de retour cesse de le traverser, vous obtiendrez des réinitialisations intermittentes qui ressemblent exactement à une panne réseau. Vérifiez cela avant de blâmer qui que ce soit.
Déposer une plainte de routage qui aboutit
Le délai médian de première réponse sur un ticket est de 11 minutes. Une correction de routage prend plus de temps, car quelqu'un d'autre doit être d'accord.
- 01
Éliminez votre propre instance
Vérifiez la charge, le suivi de connexion, les compteurs d'interface de l'instance elle-même et si une règle de filtrage de votre côté ne fait pas tomber le trafic. Environ un rapport sur cinq s'arrête ici, et cela s'arrête plus vite si vous vérifiez d'abord.
- 02
Collectez les deux directions
Au moins 300 cycles MTR de votre côté et 300 depuis le looking glass de ce site, exécutés dans la même fenêtre. Joignez le permalien plutôt qu'une capture d'écran ; nous avons besoin des chiffres, pas d'une image des chiffres.
- 03
Horodatez correctement
UTC ou décalage explicite. « Ce matin » décrit un moment pour vous et une plage de onze heures pour nous, et corréler les données de flux avec cela relève de la supposition.
- 04
Dites ce qui a changé et quand
Toujours été comme ça, ou commencé mardi. Continu, ou entre 20h00 et 23h00 locales. Cette seule phrase décide généralement si nous regardons un changement de peering ou la congestion du soir de quelqu'un.
- 05
Envoyez-le au support
Envoyez un e-mail à [email protected] ou ouvrez un ticket dans le panneau. Tout ce qui s'avère être un vrai problème de chemin est escaladé à l'équipe réseau dans l'heure, et vous êtes informé de ce que nous avons demandé à l'autre réseau.
Ce que nous pouvons faire : réacheminer, dépréférencier un transit, demander à un pair d'enquêter, ou vous déplacer vers un site avec un meilleur itinéraire. La congestion à l'intérieur d'un réseau que nous ne touchons pas dépasse ces quatre options, et là nous vous contournons le problème plutôt que de passer une semaine à avoir raison.
Questions sur le looking glass
Pendant soixante secondes à la fois, oui. Le jeton existe pour empêcher l'hôte de devenir une source d'inondation pour quelqu'un, pas pour rationner une mesure honnête. Un test soutenu veut votre propre instance aux deux extrémités.
Cela ne devrait pas être le cas, et si cela arrive, nous aimerions le savoir. L'hôte de sonde se trouve sur le même VLAN et hérite de la même politique. Une différence réelle signifie généralement une politique par préfixe appliquée à votre adresse, ce qui vaut un ticket.
Pas sur le looking glass public. Demandez dans un ticket avec un préfixe spécifique et une raison, et vous obtiendrez la réponse, y compris quel amont nous préférons pour cela et pourquoi.
Dans les limites de débit, oui ; les tests sont sortants et inoffensifs à ce volume. L'utiliser comme source de mesure pour une cible que vous ne contrôlez pas est acceptable. Comme composant de quelque chose de plus grand, non.
Trente jours, puis ils expirent avec la sortie stockée. Attachez-le à un ticket pendant qu'il fonctionne toujours, ou collez le texte, ce que nous préférons de toute façon.
Exécutez le test, puis choisissez la ville
La latence que vous avez mesurée vaut mieux que la latence publiée par quelqu'un. Une fois que les chiffres ont du sens, l'index des emplacements indique le stock, l'uplink et la capacité de filtrage pour chaque site.