En anti-DDoS, la capacité ne suffit pas. Il faut aussi comprendre la latence, le routage asymétrique, la relivraison du trafic propre et l’importance du Gbps comme du Mpps.
Mitigation adaptative et relivraison propre
Un réseau anti-DDoS crédible doit aussi maîtriser la latence et la qualité de livraison.
Il n’est pas forcément un problème si le cas d’usage et le retour de trafic sont bien pensés.
Le but n’est pas seulement de bloquer l’attaque, mais de livrer le trafic légitime correctement.
Une attaque faible en Gbps peut rester violente en paquets par seconde.
Dans le discours commercial anti-DDoS, on voit souvent les mêmes chiffres revenir : bande passante, capacité totale de mitigation, nombre de Tbps. Ces chiffres ont leur utilité, mais ils ne racontent pas à eux seuls la qualité réelle d’une protection.
Ce qui fait la différence en production, c’est aussi la manière dont le trafic légitime circule, la latence ajoutée, le choix d’un routage symétrique ou asymétrique, et la capacité à relivrer un trafic propre sans dégrader l’expérience du client final.
Un service peut techniquement rester “en ligne” tout en devenant inutilisable si la latence grimpe trop. C’est particulièrement vrai pour le jeu en ligne, les API sensibles au temps de réponse, les panels d’administration et certains flux transactionnels.
Un design anti-DDoS sérieux ne doit donc pas seulement absorber une attaque. Il doit aussi préserver un chemin raisonnable pour le trafic légitime, avec une logique réseau adaptée au service protégé.
Le routage asymétrique signifie en pratique que l’entrée et la sortie du trafic ne suivent pas exactement le même chemin. Dans un contexte anti-DDoS, cela peut être un choix très pertinent lorsqu’il permet d’entrer par la couche de mitigation et de sortir localement au plus proche de l’infrastructure du client.
Ce modèle peut réduire la latence de sortie, simplifier certains déploiements et éviter une migration complète. Il demande simplement d’être réfléchi correctement : retour de trafic, annonces, état des sessions et contraintes applicatives doivent être compris dès le départ.
Pratique quand le trafic doit entrer par la protection mais sortir plus directement vers Internet ou vers l’infra du client.
Intéressant quand on veut garder un chemin homogène ou répondre à des contraintes réseau spécifiques.
Le bon choix dépend du service protégé, de sa sensibilité à la latence et de la manière dont il est exploité.
La partie la plus importante n’est pas seulement le filtrage : c’est la qualité de la relivraison du trafic légitime après filtrage. Si le trafic propre est renvoyé vers le client d’une manière instable, trop complexe ou trop contraignante, l’architecture perd une partie de sa valeur.
Cross-connect, GRE, IPIP, VXLAN ou autres modes de delivery doivent être vus comme un prolongement direct de la mitigation. Le service final n’a de valeur que si le trafic propre arrive de manière exploitable en production.
Un acteur anti-DDoS ne peut pas regarder uniquement les Gbps. Certaines attaques restent modérées en bande passante mais extrêmement agressives en paquets par seconde, ce qui peut saturer des équipements, des files d’attente, des firewalls ou des stacks logicielles bien avant de saturer un lien.
Inversement, une attaque très lourde en bande passante mais plus faible en Mpps n’a pas le même effet sur tous les environnements. Lire correctement une attaque, c’est toujours regarder à la fois le volume, le rythme et la manière dont le trafic traverse le système.
Utile pour estimer la pression sur les liens et le risque de saturation amont.
Indispensable pour comprendre la charge réelle sur les équipements et les logiciels.
Protocoles, tailles de paquets, symétrie et répartition comptent autant que le volume brut.
Le bon filtrage dépend du profil exact de l’attaque, pas d’un seul indicateur.
Pour un serveur de jeu, quelques millisecondes de plus peuvent déjà être visibles. Pour un service web, la stabilité globale et la capacité à garder le frontend disponible priment souvent davantage. Pour un hébergeur ou une plateforme multi-services, l’enjeu est souvent de préserver la souplesse de livraison sans créer une architecture trop rigide.
C’est pour cela qu’une architecture anti-DDoS crédible doit être pensée comme une chaîne complète : entrée sur la mitigation, décisions de filtrage, choix du routage, puis relivraison du trafic propre.
Priorité forte sur la latence et sur la stabilité des flux pendant l’attaque.
Importance de la disponibilité, des temps de réponse et du maintien des sessions.
Besoin d’un modèle flexible, propre et réplicable sur plusieurs services.
Le bon design est souvent celui qui protège sans imposer une refonte complète.
La première erreur est de se focaliser uniquement sur des chiffres de capacité. La seconde est de traiter le routage asymétrique comme un défaut automatique. La troisième est d’oublier que la relivraison du trafic propre est aussi importante que le filtrage lui-même.
Non. Elle compte, mais elle ne remplace ni une bonne architecture de delivery ni une bonne maîtrise de la latence et du trafic légitime.
Non. Il peut être très pertinent si le design réseau est cohérent avec le service et le retour de trafic.
Parce que beaucoup d’équipements ou de logiciels peuvent souffrir d’une forte charge en paquets bien avant une saturation en Gbps.
Oui, car il conditionne la rapidité de déploiement, la stabilité de la prod et l’expérience réelle du client final.
Une offre anti-DDoS crédible ne se résume pas à une capacité de mitigation théorique. Elle se juge aussi sur la latence, sur le choix du routage et sur la manière dont le trafic propre est réellement relivré en production.
En pratique, les architectures qui inspirent confiance sont celles qui protègent l’infrastructure tout en respectant le trafic légitime et les contraintes d’exploitation du client.
Décrivez votre sensibilité à la latence, votre mode de routage actuel et votre environnement de production : nous pourrons vous orienter vers l’architecture la plus cohérente.
