Pourquoi le débit vers les serveurs UE est inférieur à Speedtest

Speedtest annonce 290 Mbit/s. Votre débit réel vers les serveurs de l'UE tourne plutôt autour de 38 Mbit/s. Un écart de près de huit fois ne passe pas inaperçu. Il tient presque toujours au long trajet international, pas à votre matériel ni à notre service.

En bref

Speedtest et une vraie connexion vers un serveur lointain mesurent deux choses différentes. Speedtest vérifie la capacité brute de votre ligne locale, sur un trajet très court. Le travail avec les serveurs de l'UE dépend de la latence et des liens internationaux traversés. Un bon score Speedtest prouve donc que votre ligne va bien. Le faible débit vers l'UE, lui, tient à la physique des liaisons longues et à la charge des réseaux de transit.

À quoi ressemble l'écart

Voici une même ligne mesurée deux fois, à quelques minutes d'écart. D'abord Speedtest, contre un serveur qu'il a choisi lui-même.

Deux détails de ce panneau expliquent presque tout le chiffre. La ligne "Connections" affiche "Multi", donc le chiffre additionne plusieurs flux. Et le serveur choisi se tient dans le même pays. Voici maintenant la même ligne contre les serveurs qui portent vraiment les webinaires, à l'étape "Speed" de notre testeur de connexion.

La réception chute de près de huit fois. L'émission, elle, glisse seulement de 26 à 16, une baisse bien plus douce. Aucun des deux chiffres ne signale une ligne en panne. Où part chacun, c'est le reste de l'article qui le montre.

Le second panneau se lit avec attention. "TO YOU" est ce que vous recevez, "FROM YOU" ce que vous envoyez. Vous animez le webinaire vous-même ? Alors le chiffre qui compte est "FROM YOU", car votre caméra, votre micro et votre écran montent tous vers nous. Un participant qui regarde seulement dépend de "TO YOU". Dans la mesure ci-dessus, 15,98 Mbit/s en émission font environ dix fois ce qu'il faut à un animateur.

Les intitulés sont donnés tels qu'ils s'affichent sur nos captures, en anglais. Dans une interface en français, les mêmes rubriques portent un nom français et occupent les mêmes places.

Ce que Speedtest mesure vraiment

Speedtest est bâti pour afficher le chiffre le plus haut possible. Son résultat ne reflète donc qu'en partie le travail avec des serveurs lointains.

• Il prend le serveur le plus proche. Speedtest retient le nœud à la plus faible latence, souvent dans le réseau de votre opérateur ou dans votre ville. Le trafic y va par un trajet court et ne touche aucun lien international.
• Il ouvre beaucoup de connexions à la fois. Speedtest lance plusieurs flux TCP d'un coup, de 4 à 16 en général, et additionne leurs débits. Il contourne ainsi la limite d'une connexion unique sur un long trajet, celle qu'explique la section suivante. Les vraies applications travaillent souvent sur un flux ou deux, et n'ont droit à aucun bonus.
• La latence est minime. Sur un trajet court, l'aller-retour, ou RTT, ne fait que quelques millisecondes, et TCP a le temps de monter au débit plein de la ligne.

Speedtest montre donc le débit de laboratoire de votre ligne. Ce que vous obtiendrez face à un serveur d'un autre pays, il ne le montre pas.

Le produit débit-délai et la fenêtre TCP

L'essentiel de l'écart tient à un seul mécanisme.

TCP envoie les données par fenêtres. L'émetteur pousse un bloc de données, puis attend la confirmation de son arrivée avant de continuer. Le débit maximal d'une connexion TCP unique suit une formule simple.

Débit = taille de la fenêtre / latence (RTT)

Pour remplir la ligne entièrement, la fenêtre doit valoir au moins le produit débit-délai, ou BDP.

BDP = débit × RTT

Prenons cette ligne à 290 Mbit/s et une latence d'environ 50 ms vers un serveur de l'UE.

BDP = 290 000 000 bit/s × 0,05 s = 14 500 000 bits = 1,81 Mo

Il faut donc près de 1,8 Mo de données en vol à chaque instant pour saturer la ligne. Un des deux côtés reste coincé sur une fenêtre limitée, les 64 Ko classiques sans mise à l'échelle ? Le plafond d'une connexion unique tombe alors à ceci.

Débit = 65 536 octets × 8 bit / 0,05 s ≈ 10,5 Mbit/s

Voilà pourquoi une connexion unique vers un serveur lointain plafonne entre 10 et 20 Mbit/s. Et cela même quand la ligne elle-même est prévue pour des centaines de mégabits. Sur un trajet court, avec un RTT de 2 ms, la même fenêtre donnerait plus de 260 Mbit/s. C'est pour cela que Speedtest ne voit jamais le problème. Plus la latence monte, plus l'effet est fort. Rien n'est cassé, le protocole se comporte simplement ainsi.

La latence et la physique des longues liaisons

La latence d'un long trajet s'additionne à partir de plusieurs postes. Certains ne s'enlèvent pas du tout.

La lumière parcourt la fibre optique à près de 200 000 km/s. C'est nettement moins vite que dans le vide, à cause de l'indice de réfraction du verre. Chaque millier de kilomètres ajoute environ 5 ms à l'aller, donc près de 10 ms sur l'aller-retour. Les vrais trajets suivent rarement une ligne droite, et dépassent donc la distance géographique.

Vient ensuite le délai de chaque nœud intermédiaire. Le routeur traite le paquet, le met en file, puis le transmet. Vers un serveur de l'UE, ces nœuds, les sauts, sont en général de 10 à 20. Chacun y ajoute sa part. Plus le RTT final monte, plus le plafond d'une connexion unique baisse, par la formule ci-dessus.

Les pertes de paquets et leur effet sur TCP

Même de faibles pertes sur un lien international taillent le débit final. TCP lit un paquet perdu comme un signe de congestion. Il ralentit donc, puis remonte le débit petit à petit. La relation tient dans l'équation de Mathis.

Débit ≈ MSS / (RTT × √p)

MSS est la taille maximale du segment, près de 1460 octets. RTT est la latence, et p la part des paquets perdus. Le débit baisse comme l'inverse de la racine carrée du taux de perte. Et il dépend directement de la latence.

En pratique, les chiffres font peur. À 50 ms de RTT avec un MSS ordinaire, 0,1 pour cent de perte tient déjà une connexion unique vers 7 Mbit/s. Un pour cent la descend autour de 2,3 Mbit/s, et deux pour cent sous 1,7 Mbit/s. Sur les longs trajets de transit, une perte de 1 à 2 pour cent aux heures de pointe reste banale. Là où elle atteint ce niveau, elle mord plus fort que la limite de fenêtre. Une route simplement lente le matin devient donc inutilisable le soir.

Le routage et le peering

Le chemin de votre trafic vers un serveur de l'UE n'a rien de direct. Il passe par une chaîne d'opérateurs et par le protocole de routage BGP. Celui-ci choisit une route sur des critères commerciaux et techniques, pas sur la distance la plus courte.

Plusieurs ennuis classiques en découlent. Une route peut traverser un pays tiers alors qu'un chemin plus court existe, ce qui monte la latence et le risque de perte. Le trafic franchit aussi les jonctions entre réseaux, donc les points de peering et les liens de transit. Une jonction saturée, c'est exactement là que le débit tombe. Le routage asymétrique est courant lui aussi, les paquets partant par un chemin et revenant par un autre, ce qui brouille le diagnostic. Enfin, la capacité internationale s'achète, et l'opérateur qui a acheté au plus juste en manque au pic.

La saturation des liens internationaux de votre opérateur

Le trafic local, dans la ville et dans le pays, garde de la marge chez la plupart des opérateurs. C'est pour cela que Speedtest vers un serveur proche affiche toujours un beau chiffre. Les liens internationaux coûtent plus cher et s'achètent en volume limité. Le soir, au pic, ils deviennent le goulet. D'où un débit vers l'UE qui bouge nettement au fil de la journée, pendant que le Speedtest local reste haut.

Les autres facteurs techniques

Au-delà des causes principales, quelques éléments pèsent encore sur le débit vers un serveur lointain.

Le MTU et la fragmentation. Si le MTU du trajet est plus petit que prévu, les paquets se fragmentent et l'efficacité baisse. Un PMTUD mal réglé, soit la découverte du MTU sur le chemin, mène à des trous noirs et à des transferts bloqués.

Le bufferbloat. Des tampons surdimensionnés sur les nœuds intermédiaires montent la latence sous charge. Ils embrouillent aussi les algorithmes de contrôle de flux de TCP, et le débit réel baisse encore.

Le lissage et la priorisation, autrement dit la QoS. Certains opérateurs brident ou rétrogradent volontairement le trafic international, ou un type précis de trafic. Cela se voit tout de suite sur votre débit.

Le surcoût des protocoles. Les en-têtes TCP, IP et de chiffrement prennent une part de la bande passante. Sur un trajet court, cela ne se voit pas. Avec les pertes et la latence d'un long trajet, la somme se remarque.

Votre propre environnement. Le Wi-Fi au lieu du câble, un routeur domestique surchargé, un antivirus ou un VPN sur l'appareil font tous baisser le débit réel. Écartez cela avant de chercher la panne au loin.

Pourquoi le matériel et le service ne sont pas en cause

Un bon score Speedtest prouve que votre matériel et votre ligne locale vont bien. Ils donnent le débit prévu. La chute face aux serveurs de l'UE vient d'ailleurs. Elle vient de la latence du long trajet et de la limite de fenêtre d'une connexion TCP unique. S'y ajoutent les pertes de paquets et l'état des liens internationaux de votre opérateur. Tout cela vit hors de notre service et hors de votre matériel, sur le segment entre votre opérateur et les opérateurs de dorsale.

Une remarque avant de courir après les chiffres. Un webinaire demande bien moins qu'un transfert de fichiers, donc 20 Mbit/s vers l'UE ne nous gênent pas du tout. Un animateur a besoin d'environ 1,6 Mbit/s en émission, ou 3,2 avec le partage d'écran. Un participant, lui, doit recevoir chaque intervenant à l'antenne, et prérequis techniques pose tous les chiffres. La stabilité compte ici plus que le débit brut. Si vos événements passent sans accroc, l'écart avec Speedtest est une curiosité, pas une panne.

Comment vérifier vous-même

Quelques contrôles désignent la cause.

• Lancez Speedtest à la main et choisissez un serveur en Allemagne ou en Finlande. Tous nos serveurs sont dans l'UE, en Allemagne, en France, aux Pays-Bas et en Finlande. Mais le trafic des webinaires, ce sont les machines allemandes et finlandaises qui le portent. Les néerlandaises et les françaises envoient les invitations aux événements à venir. Mesurer contre ces deux-là vous renseigne donc sur une route que vos webinaires n'empruntent jamais. L'Allemagne et la Finlande montrent le vrai débit sur la route utilisée en pratique, pas vers le serveur local le plus proche.
• Suivez la route. La commande tracert sous Windows, ou traceroute sous macOS et Linux, vers notre serveur donne la chaîne des nœuds avec la latence de chacun. Pour lire les pertes et la latence plus clairement, prenez l'utilitaire mtr, ou WinMTR sous Windows, et laissez-le tourner quelques minutes aux heures de pointe.
• Comparez une connexion et plusieurs. Un téléchargement multi-flux rapide face à un flux unique lent confirme la limite de fenêtre TCP sur le long trajet.
• Si vous en avez les moyens techniques, mesurez le débit vers le nœud lointain avec iperf3, d'abord sur un flux, puis sur plusieurs.

Notre testeur d'équipement mène aussi vers un test dédié à la qualité de l'internet, qui donne le débit, le ping et la gigue. Un moyen rapide de fixer l'état de votre ligne à un instant donné.

Que faire

Vos contrôles montrent une latence forte ou des pertes sur le segment international ? Allez voir votre opérateur avec du concret, soit la trace de la route et un relevé mtr, avec l'heure notée. Corriger la route ou élargir la connectivité internationale, c'est son travail. De notre côté, nous fournissons les adresses de nos serveurs pour un diagnostic ciblé et nous vous aidons à lire les résultats. Écrivez au chat en ligne et nous vous les envoyons.

Le fin mot

Un résultat Speedtest proche de 290 Mbit/s confirme que votre ligne va bien. La chute sous 40 Mbit/s vers les serveurs de l'UE est attendue. Elle tient à la latence du long trajet et à la limite de fenêtre d'une connexion TCP unique. S'y ajoutent les pertes de paquets et la charge des liens internationaux de votre opérateur. Ces causes vivent sur le réseau entre vous et nous, pas dans votre matériel ni dans notre service. Un simple diagnostic de route dira laquelle des quatre fait le dégât.

Questions fréquentes

Faut-il payer une ligne plus rapide pour régler cela ?

Non. Un webinaire demande bien moins qu'un transfert de fichiers, et 20 Mbit/s vers l'UE ne nous gênent pas du tout. Un animateur a besoin d'environ 1,6 Mbit/s en émission, ou 3,2 avec le partage d'écran, et prérequis techniques pose tous les chiffres. La stabilité compte ici plus que le débit brut. Si vos événements passent sans accroc, l'écart avec Speedtest est une curiosité, pas une panne.

Ma réception a chuté de huit fois, mon émission a à peine bougé. Laquelle compte ?

L'émission, si c'est vous qui animez. Votre caméra, votre micro et votre écran montent tous vers nous, et c'est le chiffre "FROM YOU". Un participant qui regarde seulement dépend de "TO YOU". La même mesure se lit donc autrement selon votre rôle à l'événement. Dans le relevé ci-dessus, l'émission glisse seulement de 26 à 16 Mbit/s, environ dix fois ce qu'il faut à un animateur.

Quel serveur Speedtest choisir pour une comparaison honnête ?

Un serveur en Allemagne ou en Finlande. Tous nos serveurs sont dans l'UE, en Allemagne, en France, aux Pays-Bas et en Finlande. Mais le trafic des webinaires, ce sont les machines allemandes et finlandaises qui le portent. Les néerlandaises et les françaises envoient les invitations aux événements à venir. Mesurer contre ces deux-là vous renseigne sur une route que vos webinaires n'empruntent jamais.

Y a-t-il là-dedans quelque chose que je peux régler moi-même ?

Commencez par votre bout. Le Wi-Fi au lieu du câble, un routeur domestique surchargé, un antivirus ou un VPN font baisser le débit réel. Tout est propre de ce côté et vos contrôles montrent encore de la latence ou des pertes sur le segment international ? La suite revient à votre opérateur. Allez le voir avec du concret, soit la trace de la route et un relevé mtr avec l'heure notée. Les adresses de nos serveurs pour un diagnostic ciblé, nous vous les donnons, écrivez simplement au chat en ligne.

Pourquoi la route est bonne le matin et inutilisable le soir ?

Les liens internationaux s'achètent en volume limité et deviennent le goulet au pic du soir. Le trafic local garde de la marge, et le Speedtest vers un serveur proche reste donc haut toute la journée. Les pertes de paquets suivent la même courbe, et 1 à 2 pour cent aux heures de pointe restent banales sur les longs trajets de transit. À 50 ms de RTT, un pour cent de perte tient une connexion unique autour de 2,3 Mbit/s. Voilà ce qui transforme une route simplement lente en route inutilisable.