High PPS Anti-DDoSPublié le 9 mai 2026Temps de lecture : 14 min
Comment gérer 100Mpps+ en mitigation DDoS sans saturer l’infrastructure
Gérer 100Mpps+ demande une architecture pensée pour le nombre de paquets, pas seulement pour les Gbps : détection rapide, filtrage précoce, capacité amont et relivraison propre.
Le PPS casse avant le Gbps
Un firewall ou un serveur peut tomber sous 100Mpps même si la bande passante semble encore disponible.
Filtrer tôt
Plus le drop est proche de l’entrée réseau, moins l’attaque consomme de CPU, mémoire et files d’attente.
Relivrer propre
Le vrai résultat attendu est un service joignable, pas seulement un graphe de trafic bloqué.
Gérer 100Mpps+ n’est pas le même problème que gérer une attaque de quelques dizaines de Gbps. À ce niveau, chaque paquet coûte du temps CPU, remplit des files, traverse des ACL, touche les buffers NIC et peut faire tomber un équipement avant même que le lien soit saturé. Un design Anti-DDoS sérieux doit donc raisonner en paquets par seconde, pas uniquement en bande passante marketing.
Pour un hébergeur, un serveur dédié exposé, un réseau BGP ou un service gaming, le PPS élevé est souvent plus dangereux qu’un gros volume simple. Une architecture capable de tenir 100Mpps+ combine capacité amont, règles précises, filtrage stateless très tôt, seuils automatisés et livraison de trafic propre vers la production.
Modèle de protection
Où Peeryx intervient
Peeryx aide à positionner la mitigation avant le goulot : transit IP protégé, tunnel, cross-connect, serveur dédié ou proxy gaming selon le service à protéger.
Une attaque 100Mpps+ envoie tellement de paquets que la limite n’est plus seulement le débit en Gbps. Le point faible peut devenir le nombre d’interruptions, de lookups, de compteurs, de règles stateful ou de paquets à parser par seconde.
Un lien 100G peut encore sembler avoir de la marge alors qu’un firewall, une VM routeur ou une pile Linux perd déjà des paquets. C’est pour cela qu’une défense basée uniquement sur la capacité de bande passante donne une fausse impression de sécurité.
Pourquoi c’est critique pour les ventes et la disponibilité
Lorsqu’un service tombe sous haute PPS, le client final ne voit pas “une attaque complexe”. Il voit un site indisponible, un serveur de jeu injouable, des timeouts ou un support qui ne répond plus assez vite.
Le PPS élevé augmente aussi le risque de faux positifs. Sous pression, beaucoup d’opérateurs appliquent des règles larges pour sauver l’infrastructure, mais ces règles peuvent bloquer des clients légitimes, casser UDP ou dégrader la latence.
Pour vendre du transit IP protégé, du serveur dédié Anti-DDoS ou de la protection gaming, il faut donc prouver que l’architecture comprend les limites PPS réelles, pas seulement afficher un chiffre en Tbps.
Les solutions possibles pour absorber 100Mpps+
La première solution est le filtrage amont : réduire le bruit avant que le trafic touche les ports ou machines du client. Cela peut passer par FlowSpec, règles ACL réseau, scrubbing ou capacité de transit protégée.
La deuxième couche concerne le filtrage local très rapide : XDP, eBPF, DPDK, VPP ou appliances spécialisées selon le contexte. Cette couche doit rester simple, mesurable et éviter tout état inutile sur le chemin chaud.
Enfin, la relivraison compte autant que le drop. GRE, IPIP, VXLAN, cross-connect ou router VM doivent être dimensionnés pour le trafic propre restant, avec une latence prévisible.
Filtrage amont
Réduire le PPS avant que le client ne reçoive le trafic.
Fast path local
Éviter l’état, les logs coûteux et les traitements inutiles sur le chemin chaud.
Handoff propre
Relivrer le trafic utile par le modèle le plus adapté.
Comment Peeryx aborde les attaques très haute PPS
Peeryx privilégie une approche où le trafic d’attaque est réduit avant d’atteindre la production du client. L’objectif est de dégrossir le volume et le PPS, puis de laisser passer le trafic légitime via un modèle de livraison clair.
Selon le cas, la protection peut être livrée en transit IP protégé avec BGP, via tunnel, cross-connect ou reverse proxy gaming. Le choix dépend de l’ASN, du service, de la latence cible et du contrôle réseau attendu par le client.
Pour les profils très exposés, la discussion doit inclure seuils PPS, seuils Gbps, ports critiques, comportement UDP/TCP et contraintes de retour du trafic.
Un serveur de jeu peut recevoir un flood de petits paquets UDP qui dépasse rapidement 100Mpps. Le débit en Gbps n’est pas toujours impressionnant, mais les joueurs subissent du lag, des déconnexions et des erreurs de connexion.
Une réponse correcte consiste à filtrer les paquets impossibles, limiter les sources anormales, réduire le bruit amont et relivrer uniquement le trafic cohérent vers le serveur ou le proxy. Le but est de préserver les sessions légitimes, pas de couper UDP globalement.
Erreurs fréquentes
La première erreur est de dimensionner uniquement en Gbps. La seconde est de laisser un firewall stateful voir tout le flood avant de le filtrer. La troisième est de croire qu’un serveur puissant compensera une topologie mal placée.
Une autre erreur consiste à confondre graphe de mitigation et qualité réelle : si le trafic propre revient avec trop de jitter ou de faux positifs, la protection ne répond pas au besoin commercial.
Ne regarder que les Gbps et ignorer les paquets par seconde.
Laisser un firewall stateful absorber la première vague.
Appliquer des règles trop larges qui cassent UDP ou les sessions légitimes.
Oublier la latence et le jitter après mitigation.
Pourquoi choisir Peeryx pour ce type de besoin
Peeryx se positionne sur les infrastructures qui doivent rester joignables sous attaque : transit IP protégé, serveurs dédiés, réseaux BGP et services de jeu.
L’intérêt est d’avoir une discussion technique claire avant l’incident : où filtrer, comment relivrer, quels seuils appliquer et comment éviter de casser le trafic légitime.
Transit d’abord
La protection agit avant le serveur, via transit IP protégé, tunnel ou cross-connect.
Gaming compris
Les contraintes UDP, FiveM, Minecraft et latence ne sont pas traitées comme du web générique.
Design lisible
Le client sait où le trafic entre, où il est filtré et comment le trafic propre revient.
Continuer la lecture
Ces ressources permettent de relier le sujet 100Mpps+ aux offres concrètes : transit, serveur dédié et reverse proxy gaming.
Questions fréquentes avant de dimensionner une protection haute PPS.
100Mpps est-il forcément une très grosse attaque en Gbps ?
Non. De petits paquets peuvent créer un PPS énorme avec un débit modéré. C’est précisément ce qui fatigue les équipements.
Un serveur dédié suffit-il pour tenir 100Mpps ?
Pas seul. Il faut surtout placer le filtrage au bon endroit et réduire l’attaque avant les goulots.
Le gaming est-il plus sensible au PPS ?
Souvent oui, car UDP, latence et jitter rendent les faux positifs très visibles.
Peeryx peut-il livrer le trafic propre par tunnel ?
Oui, selon le besoin : GRE, IPIP, VXLAN, cross-connect ou autre modèle adapté.
Conclusion
Gérer 100Mpps+ demande une architecture qui comprend les paquets par seconde, le coût CPU, le filtrage précoce et la relivraison propre. Un gros chiffre de capacité ne suffit pas.
Le bon modèle protège le service avant saturation, limite les faux positifs et garde une exploitation claire pendant l’attaque.
Ressources
Lectures liées
Pour approfondir le sujet, voici d’autres pages et articles utiles.
Peeryx peut vous aider à choisir le bon modèle de mitigation : transit IP protégé, serveur dédié, tunnel, cross-connect ou reverse proxy gaming selon votre exposition réelle.
