Votre serveur est-il proche de IBM Cloud ?

Il mesure, depuis la machine où il tourne, la latence vers chaque région de 22 fournisseurs : 392 régions au total. Pour chaque région : la médiane, le minimum, le P90, la gigue (écart moyen entre deux mesures successives) et la perte, ainsi qu’un niveau : T0 jusqu’à 30 ms, T1 jusqu’à 80, T2 jusqu’à 150, T3 jusqu’à 250, T4 au-delà.

Chaque région est représentée par un endpoint public que le fournisseur y exploite, comme une API ou un stockage objet : on mesure donc le chemin réseau vers cette région, pas une machine virtuelle à l’intérieur.

• Handshake TCP (par défaut) : le temps d’ouvrir une connexion vers le port HTTPS de la région. Un aller-retour réseau sans travail du serveur, la comparaison la plus juste entre régions.
• HTTPS : une requête sur une connexion ouverte et réutilisée, chronométrée jusqu’aux en-têtes de réponse. C’est ce que voit une app, le même chiffre que Me2Cloud ; certains fournisseurs ajoutent du temps serveur, environ 100 ms sur le looking glass de Vultr.
• ICMP : le ping classique. Certains réseaux donnent moins de priorité à l’ICMP, qui peut alors dépasser TCP, et Naver Cloud n’y répond pas. Il faut root ou CAP_NET_RAW.

Les cartes de latence et les looking glasses mesurent depuis leurs propres datacenters, et Me2Cloud depuis votre navigateur à la maison. Quand la question porte sur les échanges d’un serveur avec les clouds (un serveur d’application et sa base, l’origine d’un CDN, une cible de sauvegarde, un second fournisseur), le chemin part du serveur et seul un test depuis celui-ci y répond.

Le code est sur GitHub sous licence MIT ; chaque version liste ses sommes SHA-256 et porte une provenance de build GitHub, vérifiable avec gh attestation verify. L’installateur télécharge la build de votre système, la vérifie et la copie dans /usr/local/bin.

En plus de la mesure, chaque exécution récupère la liste des endpoints sur ce site (cette requête sert à compter les exécutions, par version et système seulement), demande à Cloudflare et ident.me depuis quel réseau elle tourne, et stocke le lien complet sur s.1ms.dog pour en faire un lien court. Le résultat contient les chiffres par région, la ville et le fournisseur, jamais l’adresse IP. --long-link garde le résultat hors de tout serveur, et --offline n’envoie aucune requête en dehors de la mesure.

Chaque hôte reçoit une mesure à la fois avec une pause de 250 ms, au plus quatre hôtes d’un même fournisseur sont mesurés en même temps, et un hôte est abandonné après trois échecs d’affilée. Une exécution par défaut envoie dix handshakes TCP à chaque région, comme ouvrir dix fois un site web public.

Un lien partagé s’ouvre ici avec la ville et le fournisseur du serveur, la méthode de mesure et l’heure. Un test en IPv4 et IPv6 propose une bascule entre les deux dans la barre du haut. Les couleurs des niveaux sont celles du terminal, et le graphique place chaque région selon sa médiane.

Les liens indiquent la liste d’endpoints avec laquelle ils ont été faits, et ce site garde toutes les listes qu’il a servies : les anciens liens s’ouvrent toujours après l’ajout de régions.

Me2Cloud fait le même test dans votre navigateur, depuis votre propre ligne à la maison ou au bureau. VPS2Cloud le fait sur un serveur. Les deux utilisent la même liste d’endpoints et les mêmes niveaux, donc les résultats se comparent directement ; « Tester depuis mon navigateur » sur un résultat partagé ouvre Me2Cloud avec les mêmes fournisseurs.