Sur cette page
À retenir
- Relever les deux dimensionsLes Gbit/s mesurent des bits par seconde ; les paquets/s comptent les paquets traités.
- Préciser la frontière de mesureUn compteur d’octets IP, un compteur de trames Ethernet et une estimation sur le lien ne sont pas interchangeables.
- Conserver les preuves avec le chiffreTaille des trames, sens, fonctions actives et pertes observées permettent d’interpréter le résultat.
Deux compteurs décrivent des demandes différentes
Les Gbit/s expriment un débit de bits, les paquets/s un nombre de paquets par unité de temps. Le lien transporte des octets, mais le transfert et le filtrage effectuent aussi du travail par paquet : analyse, recherches, files, compteurs et suivi d’état. La taille des paquets compte donc dans la comparaison de deux trafics.
Notez l’intervalle et le sens de chaque valeur. Un pic de réception sur une seconde ne se compare pas directement à une moyenne sur cinq minutes des deux sens. Un agrégat de plusieurs liens peut compter plusieurs fois le même trafic. Avant d’attribuer un incident à la capacité, déterminez ce que compte le graphique.
Une faible bande passante n’exclut pas une limite de traitement des paquets. Un débit élevé ne prouve pas non plus que le CPU est la limite. Corrélez les débits avec les pertes, la pression sur les files et le comportement applicatif à la frontière concernée.
Convertir avec une définition explicite de la trame
Le calculateur Peeryx utilise une longueur de trame Ethernet incluant le FCS, puis ajoute 20 temps-octets pour le préambule, le délimiteur de début et l’intervalle entre trames. Avec cette convention : PPS = bits/s ÷ [8 × (octets de la trame + 20)].
C’est un calcul de débit sur le lien pour une taille donnée, pas le débit utile applicatif ni le résultat d’un essai matériel. Un compteur IP peut omettre les en-têtes Ethernet et le FCS. Une capture peut aussi omettre le FCS ou refléter des mécanismes de déchargement matériel. Appliquer la formule à un compteur non expliqué n’en fait pas une mesure.
Les tags VLAN, l’encapsulation et le mélange de tailles modifient le comptage. Placez la définition à côté du chiffre et utilisez une distribution représentative pour planifier le trafic réel. Une taille moyenne unique peut masquer de courtes périodes dominées par de petits paquets.
Deux exemples hypothétiques aux calculs reproductibles
Il s’agit d’exemples de calcul, pas d’incidents clients ni de performances Peeryx mesurées. À 10 Gbit/s, des trames Ethernet de 64 octets occupent chacune 84 temps-octets selon cette convention : environ 14,88 millions de trames par seconde. Au même débit binaire, des trames de 1 518 octets occupent 1 538 temps-octets et représentent environ 0,81 million de trames par seconde.
Le flux de petites trames contient donc environ 18,3 fois plus de trames au même débit sur le lien. Cela ne prédit pas une multiplication identique du CPU : implémentation, fonctions, distribution du trafic et matériel interviennent. Cela montre pourquoi un chiffre de bande passante ne suffit pas à comparer les charges.
Autre comparaison hypothétique : 12 millions de trames de 64 octets par seconde représentent 8,064 Gbit/s sur le lien avec cette convention. Si un graphique affiche autre chose, comparez d’abord échantillonnage, sens et frontière de comptage. N’inventez pas une limite d’équipement pour faire coïncider deux compteurs différents.
| Débit hypothétique sur le lien | Trame Ethernet avec FCS | Trame plus 20 temps-octets | Débit théorique |
|---|---|---|---|
| 10 Gbit/s | 64 octets | 84 temps-octets | 14,88095 Mpps |
| 10 Gbit/s | 1 518 octets | 1 538 temps-octets | 0,81274 Mpps |
| 100 Gbit/s | 64 octets | 84 temps-octets | 148,80952 Mpps |
Localiser la première limite du chemin
Comparez utilisation amont, pertes d’interface physique, compteurs des files NIC, ressources de transfert et symptômes applicatifs sur le même intervalle. Si les paquets se perdent avant l’hôte, un réglage applicatif ne peut pas les récupérer. Si une file sature alors que le lien a de la marge, un port plus rapide ne corrigera pas forcément cette file.
La moyenne CPU peut masquer une répartition inégale. Examinez les données par cœur ou par file et identifiez le chemin de réception utilisé. RSS et les autres mécanismes Linux répartissent différemment le travail ; leur modification doit correspondre au pilote, à la carte virtuelle ou physique et à l’application. Plus de files n’améliore pas automatiquement le résultat.
Les nouvelles connexions, fragments et paquets déclenchant une politique coûteuse peuvent exercer une pression que le seul débit de paquets décrit mal. Conservez les fonctions actives et les caractéristiques du trafic dans le relevé d’incident. Une valeur obtenue sans filtrage n’est pas une capacité de filtrage.
Placer la mitigation là où elle peut soulager la limite
Si le lien amont est la limite, le trafic doit être réduit avant ce lien pour conserver une capacité utilisable. Le filtrage local peut avoir un autre rôle, mais il ne fait pas traverser un lien saturé aux paquets. Le transit protégé et la déviation à la demande ont leurs propres conditions de livraison et d’activation.
Si le traitement des paquets est la limite, identifiez le travail évitable et les besoins du trafic légitime. Un filtrage précoce, une politique plus simple ou une autre répartition peuvent aider, sous réserve d’une recette mesurée. Une règle qui supprime beaucoup de paquets peut aussi éliminer du trafic légitime si elle est trop large.
Defense Fabric est un logiciel pour des équipements compatibles contrôlés par l’opérateur ; sa licence et ses ports déclarés ne constituent pas un benchmark Mpps universel. Le serveur, les fonctions actives et le chemin réseau déterminent ce qu’il faut valider. Distinguez cela de la capacité réseau mutualisée d’un fournisseur.
Rédiger un plan de test interprétable
Réservez les benchmarks de surcharge à un environnement isolé et autorisé. Le RFC 6815 limite explicitement l’utilisation des méthodes RFC 2544 en production. L’observation habituelle d’un service et une recette applicative autorisée n’ont pas le même objectif que pousser un équipement jusqu’à la perte.
Conservez les versions matérielles et logicielles, le sens, les trafics envoyé et reçu, les tailles ou leur distribution, la diversité des flux, les politiques actives, la durée et les pertes. Joignez les résultats applicatifs aux compteurs. Précisez ce qui n’a pas été testé, notamment les dépendances d’hôte, de lien et de bascule.
Un résultat reproductible étaye une configuration précise dans des conditions définies. Un débit de port affiché, un essai bref et une conversion théorique autorisent des conclusions plus limitées. Gardez ces distinctions visibles lors d’un achat ou d’un dimensionnement.
Éviter les conclusions que les compteurs ne permettent pas
- Ne comparez pas un débit d’octets IP à une estimation Ethernet sur le lien sans réconcilier les frontières.
- N’additionnez pas réception et émission pour présenter le total comme une capacité de transfert dans un seul sens.
- Ne déduisez pas les performances sur petits paquets d’un test sur gros paquets, ni celles du filtrage d’un transfert sans filtre.
- Ne présentez pas un exemple calculé comme un incident client observé ou une performance logicielle mesurée.
- Ne supposez pas qu’un port plus rapide résout une saturation de file, de table d’état ou d’application.
Questions sur le débit de paquets et la capacité de protection
Un chiffre Mpps plus élevé signifie-t-il toujours une meilleure protection ?
Seules des mesures comparables permettent de le conclure. Vérifiez tailles et mélange du trafic, sens, fonctions, pertes et conditions. Un plafond théorique sur le lien et une capacité de filtrage mesurée répondent à des questions différentes.
Peut-on convertir les Gbit/s en Mpps sans taille de paquet ?
Pas en une valeur unique pertinente. Il faut une taille ou une distribution et une convention de comptage explicite. Si la distribution réelle est inconnue, utilisez une plage de tailles utiles.
Le calculateur mesure-t-il mon serveur ?
Non. Il effectue un calcul transparent à partir de vos saisies. La capacité du serveur et du filtrage exige des mesures distinctes, avec une configuration et des critères de recette définis.
