Sur cette page
À retenir
- La distance n’explique pas toutLa politique BGP et la qualité des upstreams comptent autant que la géographie.
- Le chemin retour compteLe trafic propre peut entrer par un chemin et revenir par un autre, créant de l’asymétrie.
- La mitigation doit rester procheUn scrubbing trop éloigné protège la disponibilité mais peut dégrader l’expérience.
Définition du problème
Le problème est que la latence est souvent réduite à un argument marketing : “faible latence”, “réseau premium” ou “Europe optimisée”. En réalité, le chemin d’un paquet résulte d’une politique. Un fournisseur peut être proche physiquement mais mal connecté à un FAI utilisateur. Un autre peut être plus loin mais disposer d’une meilleure route et de moins de congestion.
BGP ne choisit pas par défaut le chemin le plus faible en latence. Il choisit selon des attributs et politiques : local preference, AS path, MED, communautés et décisions opérateur. Deux utilisateurs dans le même pays peuvent donc atteindre le même service protégé par des chemins différents.
L’Anti-DDoS ajoute une couche. Le trafic peut être attiré vers un PoP de mitigation, filtré, puis relivré au client par tunnel ou cross-connect. Si le PoP est mal situé ou si le retour est inefficace, le service reste en ligne mais semble instable, surtout pour les jeux et applications temps réel.
Pourquoi c’est important
La latence compte commercialement parce que l’utilisateur ne juge pas l’élégance de la route. Il ressent le délai, la gigue et la perte. Un joueur FiveM voit de la désynchronisation. Un utilisateur VoIP entend des coupures. Un client API voit des timeouts. Un client hébergement accuse le fournisseur même si le vrai sujet est un chemin transit.
Elle compte aussi pendant les attaques. Certains fournisseurs redirigent tout le trafic protégé vers un scrubbing center éloigné seulement lorsque la mitigation démarre. Cela crée un saut de latence au pire moment. Les meilleurs designs gardent le chemin de mitigation prévisible et proche du chemin naturel quand c’est possible.
Pour un opérateur, la latence est aussi un signal de coût. Une mauvaise route augmente l’usage backbone, l’overhead tunnel et les tickets support. Mesurer depuis le PoP fournisseur ne suffit pas ; la mesure utile part des vrais réseaux utilisateurs vers le service protégé et revient.
Les solutions possibles
La première solution est de choisir des PoP proches de la base utilisateur et bien connectés aux grands réseaux. Un PoP n’est utile que si l’écosystème de transit autour est solide.
La deuxième est le monitoring de routes par ASN et région. Un ping moyen depuis un serveur ne suffit pas. Il faut savoir comment Orange, Free, Bouygues, Deutsche Telekom, Telefonica, Vodafone ou d’autres atteignent réellement le préfixe protégé.
La troisième est le design du handoff. GRE, IPIP, VXLAN et cross-connect ont chacun des implications différentes. Un tunnel se déploie vite mais ajoute encapsulation et dépendance aux chemins underlay. Un cross-connect est plus propre mais exige une présence datacenter.
La quatrième est le traffic engineering BGP. Communautés, local-pref, annonces sélectives et plus spécifiques peuvent améliorer les chemins, mais doivent être testés. Du simple AS path prepending aléatoire règle rarement la latence.
- Marseille et protection DDoS : évaluer le chemin réseau
Relier latence et positionnement des PoP en Europe.
Cas concret ou exemple d’usage
Un serveur de jeu hébergé dans le sud de la France peut avoir une excellente latence vers les utilisateurs français mais des chemins plus variables vers l’Europe centrale selon les upstreams. Si la protection DDoS force tout le trafic via un PoP nord-européen, certains utilisateurs voient un délai supplémentaire même si l’attaque est filtrée.
Un meilleur design garde l’entrée proche du chemin naturel quand c’est possible et utilise transit protégé ou tunnels sans détour inutile. Pour certains clients, un cross-connect ou une VM routeur proche est préférable à un long tunnel à travers l’Europe. Pour d’autres, le tunnel est acceptable car la vitesse de déploiement compte plus.
La décision doit reposer sur des mesures : latence de base par ASN, perte, gigue, volume entrant et comportement pendant mitigation. Sans ces mesures, “faible latence” n’est qu’un slogan.
Erreurs fréquentes
- Juger la latence avec un seul looking glass ou speed test.
- Ignorer le chemin retour après relivraison du trafic propre.
- Croire qu’anycast donne automatiquement la meilleure latence à tous les utilisateurs.
- Choisir un scrubbing center éloigné seulement pour sa capacité annoncée.
- Oublier l’overhead tunnel et la qualité de l’underlay.
- Ne pas séparer latence normale et latence sous mitigation.
FAQ
L’Anti-DDoS ajoute-t-il toujours de la latence ?
Pas forcément. Un chemin de mitigation bien placé peut rester proche de la route naturelle. Un scrubbing mal placé peut ajouter un délai visible.
La distance physique est-elle le facteur principal ?
Elle compte, mais la politique BGP, la qualité des upstreams et la congestion peuvent compter autant.
GRE est-il mauvais pour la latence ?
GRE n’est pas le problème en soi. Ce sont l’underlay, le MTU, l’encapsulation et le routage retour qui comptent.
