Comprendre la latence réseau : où passent les millisecondes

La latence réseau est le temps que met un paquet pour atteindre sa destination et revenir, le temps d'aller-retour (RTT), en millisecondes. Quatre éléments la composent : la distance parcourue par le signal, la route choisie par les réseaux, les files d'attente où il patiente, et les allers-retours qu'ajoutent les protocoles des couches supérieures. Seul le premier est fixé par la physique. Ce guide les examine tour à tour, avec de vraies mesures prises depuis nos serveurs de Falkenstein (Allemagne) et de Gravelines (France) le 7 octobre 2026.

De quoi se compose un aller-retour

Composante	De quoi il s'agit	Ordre de grandeur
Propagation	Dans la fibre optique, la lumière se propage à environ 200 000 km/s, les deux tiers de sa vitesse dans le vide : 1 ms d'aller-retour par 100 km de câble	Moins de 1 ms dans une ville, 60 à 90 ms pour traverser l'Atlantique, 160 ms ou plus vers l'autre bout du monde
Sérialisation	L'émission des bits d'un paquet sur le lien : 1 500 octets prennent 12 µs à 1 Gbit/s	Négligeable, sauf sur les liens lents : 1,2 ms par paquet plein à 10 Mbit/s
File d'attente	L'attente dans le tampon d'un routeur ou d'un modem quand un lien est chargé	Nulle sur un chemin au repos, des centaines de millisecondes quand un tampon se remplit
Traitement	Le routeur qui décide où envoyer le paquet	Des microsecondes sur le matériel actuel

On croit souvent que « chaque saut ajoute quelques millisecondes ». C'est faux : relayer un paquet prend des microsecondes. Quand les temps d'un traceroute augmentent d'un saut à l'autre, c'est la distance, ou une file d'attente, ou un routeur lent à répondre à la sonde alors qu'il relaie tout le reste à pleine vitesse.

La distance fixe un plancher

L'aller-retour le plus court possible correspond à la distance orthodromique (à vol d'oiseau) parcourue à la vitesse de la lumière dans la fibre. Les vrais câbles ne suivent jamais l'orthodromie, et les vraies routes empruntent rarement le câble le plus court. Voici l'écart entre nos mesures et ce plancher (moyenne de 60 à 100 sondes par destination, avec mtr) :

Origine → destination	Distance	Plancher dans la fibre	Mesuré	Rapport
Gravelines → Cloudflare 1.1.1.1 (Paris)	237 km	2,4 ms	4,9 ms	2,0×
Falkenstein → Cloudflare 1.1.1.1 (Francfort)	265 km	2,6 ms	5,9 ms	2,3×
Gravelines → New Jersey	5 779 km	57,8 ms	71,7 ms	1,2×
Falkenstein → New Jersey	6 462 km	64,6 ms	86,4 ms	1,3×
Falkenstein → Singapour	9 994 km	99,9 ms	165,5 ms	1,7×
Falkenstein → Tokyo	9 134 km	91,3 ms	273,6 ms	3,0×
Falkenstein → Sydney	16 220 km	162,2 ms	341,2 ms	2,1×

Sur de courtes distances, les coûts fixes (équipements, derniers mètres de câblage, temps de réponse de la destination) dominent : le rapport paraît mauvais alors que les valeurs absolues sont minuscules. Sur de longues distances, c'est la route qui compte. Tokyo est à trois fois son plancher parce que les paquets n'y vont pas directement : le tracé quitte l'Europe sur le réseau d'Arelion, atteint Singapour à 169 ms, puis Tokyo à 246 ms. Dans notre étude de la latence cloud depuis 33 villes, il fallait au mieux 351 ms de Johannesburg à São Paulo, pour un plancher de 74 ms : les paquets passaient par l'Europe.

Même destination, deux routes

Le même hôte Vultr du New Jersey, mesuré à la même minute depuis nos deux serveurs :

Depuis Falkenstein (Hetzner, AS24940)
  5. AS201011 ae12-499.nbg40.core-backbone.com      0.0%   100    3.2   3.0   2.7   3.3   0.1
  6. AS201011 ae7-2093.nyk10.core-backbone.com      0.0%   100   86.6  86.7  86.5  87.0   0.1
 11. AS20473  108.61.149.182.vultrusercontent.com   0.0%   100   86.2  86.4  85.9 107.1   2.1

Depuis Gravelines (OVHcloud, AS16276)
 10. AS16276  be102.lon-drch-sbb1-nc5.uk.eu         1.0%   100    3.8   3.7   3.5   4.1   0.1
 11. AS16276  nyc-ny1-sbb2-8k.nj.us                 0.0%   100   73.0  73.4  71.6  76.0   0.8
 13. AS???    nyiix.gi3-6.cr1.nyc1.choopa.net       0.0%   100   72.7  72.5  72.3  73.0   0.1
 17. AS20473  108.61.149.182.vultrusercontent.com   0.0%   100   71.7  71.7  71.5  73.0   0.2

Les 14,7 ms d'écart ne tiennent qu'à moitié à la distance (les planchers diffèrent de 6,8 ms). Le reste, c'est la route : depuis Gravelines, OVH achemine le trafic sur son propre réseau, via Londres, jusqu'à New York et le remet à Vultr à NYIIX, un point d'échange new-yorkais ; depuis Falkenstein, Hetzner le confie à Core-Backbone à Nuremberg, qui traverse l'Atlantique. Choisir un hébergeur, ou un opérateur, c'est aussi choisir ses routes.

Les files d'attente : la latence qui va et vient

La propagation ne change pas. Les files d'attente, si. Sur les chemins peu chargés ci-dessus, la dispersion mesurée aux destinations est restée entre 0,1 et 2,1 ms sur 100 sondes. Sur une connexion domestique, un seul gros envoi peut remplir le tampon du modem et ajouter des centaines de millisecondes à tout le reste : c'est le bufferbloat.

Pour le vérifier, lancez ping 1.1.1.1 et, pendant qu'il tourne, démarrez un gros envoi puis un gros téléchargement. Si les temps bondissent de 15 ms à 200 ms ou plus et retombent à la fin du transfert, c'est le tampon qui pose problème. La solution se trouve sur le routeur : une gestion intelligente des files d'attente (fq_codel ou CAKE, disponibles sur OpenWrt et sur beaucoup de routeurs récents), ou une limitation du débit du lien légèrement sous sa vitesse nominale.

Les protocoles multiplient les allers-retours

Une nouvelle connexion HTTPS paie plusieurs allers-retours avant que le premier octet de la page n'arrive : une résolution DNS si le nom n'est pas en cache, un pour la poignée de main TCP, un pour TLS 1.3 (deux pour TLS 1.2), et un pour la requête elle-même. En comptant quatre :

Aller-retour	4 allers-retours
6 ms (un serveur proche)	24 ms
86 ms (de l'Allemagne au New Jersey)	344 ms
341 ms (de l'Allemagne à Sydney)	1,4 s

Le même calcul vaut pour tout ce qui est séquentiel : une application qui envoie 20 requêtes l'une après l'autre à une base de données située à 80 ms attend 1,6 seconde. HTTP/2 et HTTP/3 réutilisent les connexions, TLS 1.3 et QUIC écourtent les poignées de main, et limiter les requêtes séquentielles réduit le reste.

À partir de quand c'est trop

Usage	Confortable	Perceptible
Appels audio et vidéo	Moins de 150 ms dans un sens, selon la recommandation UIT-T G.114	Au-delà, les interlocuteurs commencent à se couper la parole
Jeux en ligne rapides	Moins de 50 ms environ en aller-retour	Au-delà de 100 ms, la plupart des joueurs le ressentent
Pages web et API	Dépend du nombre d'allers-retours séquentiels	Chaque aller-retour supplémentaire s'ajoute au délai avant le premier octet

Mesurez-la vous-même

• ping -c 20 host : le minimum est votre plancher sur ce chemin, la moyenne votre latence habituelle, et mdev la gigue.
• mtr -rwz -c 100 host : à quel endroit du chemin le temps s'ajoute (voir comment lire un rapport mtr).
• Depuis plusieurs endroits : notre test de latence cloud mesure la latence de votre navigateur vers 36 régions d'AWS, OVHcloud, Vultr et Akamai, et TraceMapper trace la même route depuis plus de 30 points de mesure.

Ce que vous pouvez changer, et ce qui vous échappe

• La distance : uniquement en rapprochant le serveur des utilisateurs, ou en ajoutant une région ou un CDN. Dans notre étude sur 33 villes, Francfort servait à lui seul 14 villes en moins de 100 ms ; Francfort et Singapour ensemble, 27.
• La route : en choisissant un fournisseur dont le réseau et le peering conviennent à vos utilisateurs. Vous ne pouvez pas changer la politique de routage d'un autre réseau.
• Les files d'attente : une gestion intelligente des files à la maison et, dans un centre de données, des liens qu'on ne pousse pas à 100 %.
• Les allers-retours : réutilisation des connexions, TLS 1.3, cache DNS, moins d'appels séquentiels.

Pour la mise en pratique, voir comment réduire la latence réseau.