Après CS2 AG2 en 2026, faut-il recalculer la bande passante des serveurs communautaires ?

N’abaissez pas la capacité réseau de votre serveur communautaire CS2 sur la seule base des annonces d’Animgraph 2 : Valve n’a publié aucun taux d’économie directement applicable à un achat de bande passante. Si vous exploitez un serveur, migrez une communauté ou faites tourner plusieurs jeux sur la même machine, mesurez le trafic réel avant de modifier votre budget.

Cet article s’adresse aux administrateurs qui planifient une liaison ou une extension, aux responsables d’une migration et aux petites équipes qui doivent distinguer le trafic d’un serveur de celui de toute la machine.

Dernière mise à jour : 1 novembre 2026. Vérification fondée sur les annonces officielles de Valve concernant CS2, les graphiques d’activité de CS2 sur SteamDB et la documentation technique sur les compteurs réseau citée ci-dessous. L’activité du jeu ne permet pas, à elle seule, de déduire le débit nécessaire à un serveur communautaire.

Portée d’AG2 et limites des annonces

Valve a décrit Animgraph 2 comme une évolution visant notamment les coûts processeur et réseau associés aux animations. Les informations de la bêta publiées le 1 avril 2026 et les notes de mise à jour du 24 avril 2026 constituent les références à consulter pour comprendre le périmètre annoncé : présentation officielle de la bêta d’Animgraph 2 et mises à jour officielles de CS2.

Ces annonces ne donnent pas de pourcentage de réduction du trafic sortant d’un serveur communautaire, ni de conversion entre AG2 et un nombre de joueurs pris en charge. Elles ne justifient donc pas de retirer une marge de capacité dans un tableur d’achat, ni de choisir une liaison inférieure sans mesure.

Il faut aussi distinguer trois choses que l’on confond facilement :

• Le coût réseau des animations décrit par Valve concerne un aspect du fonctionnement du jeu. Il ne correspond pas nécessairement à l’intégralité des données échangées entre un serveur et ses clients.
• Le débit sortant mesuré sur l’interface d’un hôte regroupe les flux qui quittent cette interface, y compris ceux d’autres services si la machine en exécute.
• La qualité de connexion ressentie par les joueurs dépend aussi du chemin réseau, de la latence, de la perte de paquets et de la régularité du trafic. Une mesure de capacité disponible ne résume pas ces facteurs.

Des joueurs ont également discuté de la relation entre AG2 et le débit, comme le montre cette discussion communautaire sur l’optimisation de bande passante liée à AG2. Cette discussion atteste l’existence de la question ; elle ne constitue ni une mesure de serveur ni une preuve d’économie.

Enfin, les graphiques SteamDB consacrés à CS2 peuvent aider à vérifier que le jeu reste actif, mais l’activité globale du jeu ne dit pas combien de joueurs rejoindront votre serveur ni quel sera son trafic. Pour l’estimation, la donnée décisive reste celle de votre propre charge.

Conditions de mesure avant le débit

Une mesure isolée ne permet pas de comparer correctement deux périodes. Avant de relever des compteurs, établissez un contexte reproductible et conservez-le avec les données. Pour chaque observation, consignez :

• La version du serveur CS2 et la date de son déploiement.
• Le mode communautaire, la carte et les extensions ou réglages actifs.
• L’évolution du nombre de joueurs pendant la période, sans transformer cette observation en promesse de capacité.
• L’heure et la durée de l’échantillon, ainsi que les événements visibles, comme une rotation de carte ou une arrivée groupée de joueurs.
• Les autres services réseau présents sur la machine : autres serveurs de jeu, téléchargement de contenu, supervision ou accès d’administration.

Cette fiche ne sert pas à prédire un chiffre universel. Elle sert à comparer des conditions analogues. Si vous changez à la fois de version, de carte et de configuration réseau, vous ne saurez pas quelle modification explique l’écart observé. À l’inverse, en conservant les mêmes conditions autant que possible, vous pouvez attribuer une variation à une cause plausible et décider d’une nouvelle mesure.

La documentation du noyau Linux sur les statistiques d’interface décrit les compteurs et statistiques accessibles au niveau réseau. Pour une mesure exploitable, choisissez l’interface publique réellement utilisée par les joueurs ; lire un compteur sur une interface de boucle locale ou un pont virtuel ne répond pas à la même question.

Compteurs sortants et pics réellement observés

Le trafic entrant et le trafic sortant doivent être relevés séparément. Pour dimensionner la capacité qui transmet les données du serveur vers les clients, le débit sortant est généralement le point de départ le plus pertinent. Il ne faut toutefois pas ignorer l’entrée : elle aide à repérer une activité inhabituelle, une mise à jour en cours ou une différence entre périodes.

La formule de calcul est simple :

débit moyen sur la fenêtre = différence d’octets transmis × 8 ÷ durée de la fenêtre en secondes

Utilisez des compteurs d’octets cumulés, relevez leur valeur au début puis à la fin de chaque fenêtre et notez la durée exacte. L’unité obtenue est le bit par seconde ; exprimez-la ensuite dans une unité cohérente avec l’offre que vous comparez. Cette formule produit une moyenne sur la fenêtre, pas le maximum instantané à l’intérieur de celle-ci. Si les pics courts comptent pour votre décision, complétez le relevé par une supervision qui conserve des échantillons réguliers.

Sous Linux, une première vérification peut se faire avec :

ip -s link show dev <interface_publique>

Vous pouvez aussi lire le compteur transmis de l’interface :

cat /sys/class/net/<interface_publique>/statistics/tx_bytes

La sortie correspond à un total cumulé d’octets transmis depuis l’initialisation ou la remise à zéro du compteur. Elle n’indique pas, seule, le débit d’une partie. Notez la valeur avec l’heure, refaites la lecture après votre fenêtre d’observation, puis appliquez la formule. Les compteurs d’interface sortants sont également définis dans la norme de gestion des interfaces RFC 2863.

Exemple de relevé à compléter, sans valeur de mesure préremplie :

interface=<interface_publique>
debut_utc=<horodatage_debut>
tx_octets_debut=<compteur_initial>
fin_utc=<horodatage_fin>
tx_octets_fin=<compteur_final>
duree_secondes=<duree_mesuree>
debit_sortant=<calcul_en_bits_par_seconde>

Pour suivre l’évolution dans le temps plutôt que de faire des lectures manuelles, le guide de supervision de l’hôte avec Node Exporter explique comment exposer des métriques système. Les règles de comptage de nftables peuvent, de leur côté, aider à isoler des flux selon vos règles réseau. Vérifiez bien ce qui est compté : un compteur de règle peut suivre un sous-ensemble de trafic, tandis que le compteur de l’interface représente le total qui la traverse.

Pour suivre une communauté, ne retenez pas seulement la moyenne d’une session calme. Conservez plusieurs observations comparables, identifiez le pic récurrent et notez les pointes brèves à part. Une pointe de courte durée peut demander une investigation, sans pour autant représenter le besoin durable qui doit guider l’achat.

Phases de charge et trafic à ne pas confondre

Une partie stable n’a pas nécessairement le même profil qu’une rotation de carte, qu’un téléchargement ou qu’une période où plusieurs services sont sollicités ensemble. Traitez ces phases séparément au lieu de les fusionner dans une moyenne unique.

• Partie en cours : relevez les compteurs de l’interface et l’activité du serveur pendant une période représentative. Cette observation aide à définir le profil du jeu courant.
• Changement de carte ou de session : notez la durée et l’existence d’un pic distinct. Ne le classez pas automatiquement comme le débit soutenu d’une partie.
• Mise à jour ou distribution de fichiers : identifiez cette activité comme un transfert séparé. Si elle a lieu en même temps que les parties, indiquez-le dans le total de l’hôte.
• Autres jeux sur la même machine : mesurez leur fonctionnement simultané avec CS2. La somme des mesures isolées n’est pas nécessairement égale au maximum réellement observé lorsqu’ils tournent ensemble.
• Administration et supervision : consignez les connexions et tâches qui contribuent au trafic total, même si elles ne sont pas le trafic de jeu lui-même.

Votre fiche peut donc comporter les champs suivants : phase observée, service concerné, carte et mode, état de la communauté, compteur entrant, compteur sortant, durée, pic relevé et inclusion ou non dans le scénario d’achat. Cette structure évite de confondre une activité exceptionnelle avec une charge habituelle, tout en empêchant d’oublier une tâche récurrente qui partage la liaison.

Quand une machine héberge plusieurs serveurs, mesurez l’interface publique en parallèle des services individuels lorsque c’est possible. Des compteurs filtrés par port ou par règle peuvent distinguer des flux, mais ils ne remplacent pas la mesure globale : une décision de capacité doit aussi vérifier le trafic combiné réellement transmis par l’hôte.

Décision selon la mesure et la capacité

La comparaison ci-dessous relie le résultat de l’observation à l’action suivante. Elle n’infère ni un nombre de joueurs ni une économie attribuable à AG2. Le facteur de réserve doit être choisi selon votre tolérance aux pointes et les conditions de service que vous vérifiez.

Pour comparer les options disponibles chez OSFP Cloud, consultez la page de présentation des offres : elle indique les capacités réseau actuellement proposées, soit 250 Mbps, 1 Gbps et 2 Gbps, toutes annoncées sans limite de trafic. Ces valeurs sont des paliers de capacité, pas une promesse de nombre de joueurs ; la bonne option dépend de vos observations, du trafic combiné et de la marge que vous souhaitez conserver. Aucun prix ne peut être déduit de cette méthode : vérifiez le tarif applicable sur la page produit au moment de votre choix.

Vérification avant migration ou extension

Une migration ne doit pas être jugée sur une mesure prise avant le changement et une autre prise dans un contexte sans rapport. Reproduisez autant que possible la même version, le même mode, une carte comparable, une période d’activité similaire et le même périmètre de trafic. Notez également si des tâches annexes ou d’autres jeux fonctionnaient en parallèle.

Avant de basculer la communauté, préparez une fiche de référence et vérifiez les points suivants :

• Le compteur utilisé correspond bien à l’interface publique du serveur.
• Les octets entrants et sortants sont relevés séparément.
• L’horodatage et la durée de chaque fenêtre sont consignés.
• Le nombre de joueurs et ses variations sont notés, sans extrapolation vers une capacité garantie.
• Les mises à jour, rotations et autres services sont identifiés à part.
• Le débit calculé est distingué de la pointe instantanée ou des pics récurrents.

Après migration ou extension, refaites les relevés selon la même méthode et comparez les résultats. Une observation unique ne représente pas toutes les cartes, tous les événements ni tous les profils de communauté ; elle indique seulement ce qui s’est produit dans les conditions consignées. Pour préparer l’accès d’administration lors de cette opération, vous pouvez consulter les informations d’accès aux serveurs par ligne de commande.

Questions fréquentes sur la mesure

Les réponses ci-dessous précisent ce que l’annonce d’AG2 permet — et ne permet pas — de conclure, ainsi que les données nécessaires pour estimer une capacité réseau.

Choisir une capacité sur des données vérifiables

Pour une communauté CS2, la décision raisonnable n’est ni de réduire la liaison au nom d’AG2 ni de surdimensionner automatiquement l’hôte : il faut relever le trafic sortant dans des conditions documentées, séparer les phases atypiques et comparer les pics récurrents à la capacité disponible. Si votre installation actuelle est un environnement partagé, la contention entre voisins, une capacité CPU non dédiée et une facturation réseau moins lisible peuvent aussi compliquer l’interprétation des mesures. Pour une activité durable qui nécessite une capacité réseau connue et des ressources machine exclusives, la location d’un serveur physique AMD dédié auprès d’OSFP Cloud peut être plus adaptée ; vérifiez les options réellement proposées et retenez le palier qui correspond à vos relevés, sans faire d’AG2 un motif de réduction ou d’extension à lui seul.

Questions

La bande passante d’un serveur communautaire CS2 diminue-t-elle automatiquement après AG2 ?

Non. Valve évoque une évolution des coûts réseau liés aux animations, mais ne publie pas de pourcentage d’économie à appliquer aux serveurs communautaires. La capacité à réserver dépend de votre mode de jeu, des joueurs présents et du trafic sortant mesuré sur votre interface publique. Gardez votre dimensionnement jusqu’à disposer de mesures comparables après mise à jour.

Quelles données utiliser pour estimer le réseau d’un serveur communautaire CS2 ?

Relevez séparément les octets entrants et sortants, puis calculez les débits sur des fenêtres temporelles cohérentes. Notez en parallèle la version du serveur, la carte, le mode, les extensions actives et l’évolution du nombre de joueurs. Pour décider d’une capacité, examinez surtout le trafic sortant de l’hôte et ses pics répétés, pas une estimation fondée uniquement sur les places configurées.

Comment mesurer le pic sortant d’un serveur CS2 dédié sous Linux ?

Vous pouvez lire le compteur d’octets transmis de l’interface réseau avant et après une période d’observation, puis diviser la différence par la durée en secondes et convertir le résultat en bits par seconde. Faites la mesure pendant une partie représentative et conservez le compteur de l’interface publique. Un outil de supervision permet de garder l’historique et d’identifier les pics récurrents.

Comment calculer le trafic de plusieurs serveurs de jeu sur la même machine ?

Mesurez chaque service séparément si vous pouvez associer ses flux à un port ou à une règle de comptage, puis observez également le total de l’interface publique. Additionner les pics maximaux de chaque jeu donne une hypothèse prudente, mais ces pics peuvent ne pas être simultanés. Pour dimensionner l’hôte, comparez aussi des périodes où les services fonctionnent ensemble.