Guide Anti-DDoSPublié le 2026-05-07Temps de lecture : 11 min
DDoS PPS vs Gbps : pourquoi le nombre de paquets compte
Comprendre pourquoi une attaque DDoS peut être dangereuse avec peu de Gbps mais beaucoup de PPS, et comment dimensionner routeurs, firewalls, serveurs et plateforme Anti-DDoS.
Gbps mesure le volume
Le Gbps indique le volume à transporter ou à éliminer avant saturation du lien.
PPS mesure la pression paquet
Le PPS montre combien de décisions paquet les équipements doivent prendre chaque seconde.
Le dimensionnement exige les deux
Un bon dimensionnement combine débit, taille des paquets, queues NIC, CPU et filtrage amont.
Le Gbps est le chiffre le plus visible dans les discussions DDoS, mais le PPS explique souvent pourquoi un service tombe. Une attaque peut sembler “petite” en bande passante et pourtant saturer le traitement paquet, les files NIC, le firewall ou la logique de routage.
Une équipe qui achète de l’Anti-DDoS doit lire les deux métriques. Le Gbps indique la capacité consommée ; le PPS indique combien de décisions paquet doivent être prises chaque seconde. Un design crédible garde de la marge sur les deux.
Modèle de protection
Où Peeryx intervient
Peeryx analyse séparément le volume et la pression paquet afin de choisir le bon point de filtrage : transit protégé, serveur dédié, tunnel ou proxy gaming.
Le Gbps mesure la quantité de données par seconde. Le PPS mesure le nombre de paquets par seconde. En DDoS, ces deux valeurs peuvent évoluer séparément : les gros paquets créent du volume, les petits paquets créent de la pression de traitement.
Une attaque à 5 Gbps en très petits paquets peut être plus difficile pour un serveur qu’une attaque à 50 Gbps en paquets plus gros, car chaque paquet déclenche parsing, file d’attente, compteurs, ACL ou décision d’état.
Pourquoi les PPS changent le design
Les PPS comptent parce que routeurs, firewalls, files NIC et kernels ont tous des limites de traitement paquet. Une fois atteintes, la latence augmente, la perte apparaît et les sessions légitimes échouent même si l’uplink n’est pas plein.
Pour le gaming, cela ressemble à du lag. Pour l’hébergement, à des VPS instables. Pour un client transit, à une pression CPU imprévue sur un équipement dimensionné uniquement en bande passante.
Les solutions possibles
Le dimensionnement doit combiner vitesse de port, capacité de filtrage, limites PPS, layout des queues et soulagement amont. Regarder uniquement la bande passante donne une fausse sécurité.
Le filtrage haute PPS gagne avec des drops très tôt, des chemins rapides simples, l’aide FlowSpec ou ACL amont quand utile, et une séparation claire entre mitigation volumétrique et logique service.
PPS et Gbps mesurent deux pressions différentes : le volume de données et le nombre de décisions paquet à traiter. Le bon modèle dépend du mode d’entrée du trafic, de la précision des filtres et de la relivraison propre vers la production.
Design opérationnel pour DDoS PPS vs Gbps
Peeryx traite Gbps et PPS comme deux indicateurs de risque différents. Le volume doit être réduit avant de remplir les liens ; le bruit haute PPS doit être traité avant de brûler le CPU de l’endpoint protégé.
Cette lecture sert au transit IP protégé, aux serveurs dédiés protégés et aux proxies gaming, car chaque modèle a un goulot différent et un chemin de retour propre différent.
Un client voit seulement 8 Gbps sur ses graphes, mais son firewall devient instable. Le vrai problème est 12 Mpps de petits paquets UDP. Acheter un port plus gros ne suffit pas : il faut filtrer plus tôt avec moins de travail stateful.
Un autre client reçoit 80 Gbps en paquets plus gros. Ici, le port est le premier goulot : la capacité amont et le shaving de trafic deviennent prioritaires.
Erreurs fréquentes
La première erreur est d’annoncer seulement des Tbps en ignorant les Mpps. La deuxième est de tester avec de gros paquets synthétiques et croire que le résultat s’applique aux attaques réelles.
La troisième est de placer un firewall stateful devant tout. Ces équipements sont utiles, mais en haute PPS ils peuvent devenir exactement le goulot que l’attaquant cherche à atteindre.
Pourquoi choisir Peeryx
Cette partie de « DDoS PPS vs Gbps » précise ce qui change réellement la décision : le risque de faux positif, point de filtrage, tolérance aux faux positifs et mode de relivraison.
Livraison niveau opérateur
Livraison niveau opérateur : ce point relie « DDoS PPS vs Gbps » à la marge CPU et NIC, avec un filtrage utile et un retour propre.
Réseau et gaming
Réseau et gaming : ce point relie « DDoS PPS vs Gbps » au retour du trafic propre, avec un filtrage utile et une livraison maîtrisée.
Clarté opérationnelle
Clarté opérationnelle : ce point relie « DDoS PPS vs Gbps » au volume réellement transporté, avec un filtrage utile et une livraison maîtrisée.
L’Anti-DDoS sert-il seulement pendant les grosses attaques ?
Oui. Le PPS peut saturer routeurs, firewalls ou CPU bien avant que le graphique Gbps paraisse spectaculaire.
Puis-je protéger un serveur existant sans le déplacer ?
Oui, mais seulement si handoff, files d’attente, CPU et filtrage sont dimensionnés pour le packet rate autant que pour les Gbps.
Le gaming nécessite-t-il une approche différente ?
Oui. Les backends gaming souffrent vite de pression paquet, jitter et pertes de query même avec un volume raisonnable.
Faut-il choisir transit protégé ou serveur protégé ?
Utilisez le transit protégé pour vos préfixes ; choisissez VPS/dédié protégé si vous voulez aussi héberger l’edge exposé.
Conclusion
Comprendre pourquoi une attaque DDoS peut être dangereuse avec peu de Gbps mais beaucoup de PPS, et comment dimensionner routeurs, firewalls, serveurs et plateforme Anti-DDoS.
La bonne conclusion est opérationnelle : la mitigation doit rester mesurable, explicable et adaptée au service exposé. Le protocole, la latence, le point de filtrage et la relivraison propre comptent autant que le volume annoncé.
Ressources
Lectures liées
Pour approfondir le sujet, voici d’autres pages et articles utiles.
Envoyez à Peeryx le service à protéger, le mode de livraison souhaité et vos contraintes de latence. Nous pourrons proposer une architecture concrète, avec le point de filtrage, le retour du trafic propre et les limites opérationnelles clairement identifiés.
