Avant de commencer
Définissez l’adresse et le protocole à tester, les réseaux représentatifs et les horaires. Notez la date, le fuseau, l’opérateur, le type de connexion et les réglages du test. Distinguez le site web, le port d’administration et le service de jeu. Utilisez des tests de faible volume, autorisés et reproductibles ; une collecte de diagnostic ne doit pas devenir une charge supplémentaire.
Séparer RTT, variations et temps de traitement
Le RTT représente un aller-retour. Il ne donne pas directement le temps dans chaque sens, car les routes et traitements peuvent différer. Mesurer un délai dans un seul sens demande une méthode adaptée, notamment pour les horloges. Évitez de présenter la moitié d’un ping comme une mesure exacte du trajet aller.
Comparez plusieurs mesures plutôt que le meilleur résultat. Conservez le minimum, une valeur centrale et les valeurs élevées avec le nombre d’échantillons. Les variations et interruptions peuvent gêner davantage qu’un petit écart de moyenne. Séparez enfin le délai réseau du temps nécessaire au jeu pour simuler et répondre.
Tester le bon service et le bon protocole
Un test TCP sur HTTPS décrit ce point d’entrée, pas nécessairement le trajet du jeu UDP. Le serveur web, le proxy et le serveur de jeu peuvent utiliser des destinations ou traitements différents. Un ping ICMP fournit un autre point d’observation, avec ses propres règles et limites.
Associez les mesures à une connexion normale au service. Pour un jeu qui propose des statistiques réseau, conservez aussi ces relevés et leur contexte. Un équipement intermédiaire peut limiter ses réponses de diagnostic tout en transmettant le trafic : une ligne silencieuse dans une trace ne suffit pas à prouver une perte jusqu’au joueur.
Construire une référence avant l’incident
Mesurez à plusieurs horaires depuis les réseaux réellement utilisés. Gardez la même destination, le même protocole et la même méthode pour comparer. Une mesure depuis un centre de données ne représente pas automatiquement une connexion domestique, mobile ou Wi-Fi. Les tests d’un pays ne décrivent pas tous les opérateurs de ce pays.
Conservez les résultats bruts et les échecs, sans sélectionner uniquement les valeurs favorables. Ajoutez le nombre de tentatives et la période observée. Une référence courte indique un comportement à un moment donné ; elle ne constitue pas une garantie permanente de latence ou de disponibilité.
Comparer pendant une mitigation
Rapprochez les échecs et variations des événements réseau horodatés. Une mitigation peut modifier le chemin ou le traitement du trafic, mais il faut distinguer cette évolution d’une panne de route, d’un faux positif ou d’une charge applicative. Demandez au fournisseur quels événements et quelles adresses sont concernés.
Pour un tunnel, examinez aussi la MTU et les symptômes liés à la taille des paquets. Pour un proxy, vérifiez les délais et les connexions en aval. Ne changez pas plusieurs composants à la fois. Faites confirmer les flux légitimes avant de désactiver une règle qui participe à la protection.
Vérifier la charge du jeu en parallèle
Un serveur peut répondre vite au ping et traiter lentement ses joueurs. Regardez CPU, mémoire, disque, journaux et activité au même moment que le problème. La génération d’un monde, un script bloquant ou une base de données lente peut produire des retards sans dégradation de la route.
Quand le moteur dispose d’un outil compatible, profilez pendant le ralentissement. Pour Paper, un rapport spark peut aider à identifier le travail coûteux. Gardez des mesures bornées et une copie de la configuration avant les changements. Achetez davantage de ressources seulement si une limite observée justifie ce choix.
Présenter un diagnostic comparable
Préparez un tableau avec destination, protocole, opérateur, horaire, nombre d’échantillons et résultats. Ajoutez les messages du jeu, les mesures serveur et les modifications récentes. Distinguez les faits observés des hypothèses, puis demandez une comparaison des routes ou événements correspondants.
Après la correction, répétez la même méthode et vérifiez une session normale. Une seule mesure améliorée ne démontre pas que toutes les routes sont corrigées. Décrivez les marchés et connexions mesurés sans annoncer un ping garanti pour un pays entier ou confondre proximité géographique et qualité de routage.
Selon votre situation
| Situation | Prochaine vérification |
|---|---|
| Ping stable, jeu lent | Examiner le temps de simulation, les scripts et les ressources. Le ping seul ne mesure pas le travail de l’application. |
| Un opérateur est touché | Comparer depuis d’autres réseaux, garder les horaires et demander une vérification du trajet concerné. |
| Dégradation sous mitigation | Corréler les mesures avec les événements et les adresses protégées. Vérifier le protocole, les règles et le trajet sans désactiver globalement la sécurité. |
Sources officielles
Ces documents décrivent les protocoles et logiciels concernés. Les conditions de votre service et sa configuration restent à vérifier.