Comprendre le fonctionnement d'un serveur de jeu

Un serveur de jeu est une machine qui exécute en continu la simulation d'un monde partagé et arbitre ce que voient les joueurs connectés. Comprendre sa boucle interne, la façon dont il consomme la mémoire, le processeur et la bande passante, permet de diagnostiquer un ralentissement au lieu de le subir. Voici comment tout cela s'articule concrètement.

Comment fonctionne un serveur de jeu : la boucle de simulation

Dans la quasi-totalité des jeux multijoueurs modernes, le serveur est autoritaire : c'est lui qui détient la vérité. Ton client envoie des intentions (« j'avance », « je tire »), le serveur les valide, applique la physique, met à jour l'état du monde, puis renvoie à chaque client une vue filtrée de ce qu'il doit afficher. Ce modèle évite une grande partie de la triche côté client, mais il concentre toute la charge sur une seule machine.

Le tick : l'unité de temps du monde

Le serveur ne calcule pas en continu, il avance par pas discrets appelés ticks. À chaque tick, il traite les paquets reçus, déplace les entités, gère les collisions, la faim, la pousse des cultures, l'IA des mobs, les événements scriptés, puis diffuse les mises à jour.

Jeu	Cadence de simulation typique	Charge dominante
Minecraft (Java)	20 TPS (50 ms par tick)	Mono-thread, entités et chunks chargés
Rust	~30 Hz réseau	Entités persistantes, taille de carte, RAM
ARK / ARK Ascended	~30 ticks/s	Dinos, structures, sauvegarde disque
FiveM	Variable selon scripts	Ressources Lua, base de données
Valheim	~30 Hz	Zones actives, physique des objets

Quand un tick prend plus de temps que sa fenêtre théorique, le serveur ne peut pas rattraper : il ralentit le temps de jeu. Sur Minecraft, tu passes de 20 TPS à 14 TPS et tout devient élastique (mobs qui glissent, blocs qui reviennent, coups qui ne portent pas). Ce n'est pas de la latence réseau, c'est de la saturation CPU. La distinction est fondamentale pour le diagnostic.

Ces mécanismes sont particulièrement lisibles sur le jeu le plus documenté du genre : si tu veux voir comment ces paramètres sont dimensionnés en pratique, la page hébergeur Minecraft de Fly-Serv détaille les configurations disponibles, et tous nos serveurs de jeu reprennent la même logique matérielle.

Ce que le serveur envoie réellement

Le serveur n'envoie pas le monde entier à chaque joueur. Il applique une logique de pertinence : distance de vue, zones actives, entités visibles. C'est pour cela qu'un paramètre comme view-distance ou le nombre de zones simultanément simulées influe autant sur la charge : il multiplie mécaniquement le volume de calcul et de paquets par joueur connecté.

RAM, CPU et stockage : les trois goulots d'étranglement

Le processeur, ressource la plus critique

La plupart des moteurs de jeu exécutent leur boucle principale sur un seul thread. Concrètement, un processeur à 32 cœurs cadencés à 2,1 GHz sera moins efficace qu'un 8 cœurs à 4,5 GHz pour maintenir un tick rate stable. C'est la raison pour laquelle les architectures Ryzen à haute fréquence sont privilégiées pour la simulation de monde : ce qui compte, c'est le temps mis à terminer un tick, pas le nombre de tâches parallèles.

Les tâches secondaires (compression réseau, génération de terrain, sauvegardes, requêtes SQL sur FiveM) partent en général sur d'autres threads. D'où l'intérêt d'avoir plusieurs cœurs disponibles, mais avec la fréquence comme critère prioritaire.

La mémoire vive : quantité utile ≠ quantité maximale

Une erreur classique consiste à allouer toute la mémoire disponible à la machine virtuelle Java. Sur un serveur Minecraft, une allocation excessive rallonge les cycles du ramasse-miettes et provoque des micro-freezes réguliers. Un réglage sain :

java -Xms6G -Xmx6G \
  -XX:+UseG1GC \
  -XX:MaxGCPauseMillis=200 \
  -XX:+ParallelRefProcEnabled \
  -XX:+DisableExplicitGC \
  -jar server.jar nogui

-Xms et -Xmx identiques évitent les redimensionnements du tas. Sur des jeux compilés en natif (Rust, ARK, Palworld, Soulmask), la mémoire est consommée directement par les entités persistantes et la taille de carte : la seule variable de réglage est le nombre de joueurs, la taille du monde et la durée de vie des objets au sol.

Ressource	Symptôme quand elle manque	Comment le vérifier
CPU (fréquence)	TPS en baisse, monde au ralenti	Commande /tps, timings, spark
RAM	Freezes périodiques, crash « out of memory »	Logs GC, htop, graphiques du panel
Disque	Lag pendant les sauvegardes, chargement lent	iostat -x 1
Réseau	Rubber banding, désynchronisation	ping, mtr, perte de paquets

Le stockage : pourquoi le NVMe change la donne

Un monde de jeu s'écrit sur disque en permanence : sauvegardes automatiques, régions modifiées, journaux, base de données. Sur ARK ou Rust, une écriture périodique de plusieurs centaines de mégaoctets peut geler la simulation si le stockage n'absorbe pas les entrées/sorties assez vite. Le SSD NVMe réduit ce temps de blocage à un niveau que les joueurs ne perçoivent plus. Sur un stockage mécanique, la même opération se traduit par un gel de plusieurs secondes toutes les quinze minutes.

Latence, tick rate et perception du lag

Décomposer le trajet d'un paquet

La latence affichée en jeu est un aller-retour (RTT) qui additionne plusieurs éléments : le temps de traitement côté client, la traversée du réseau, l'attente dans la file du serveur, le temps de calcul du tick, puis le retour. Un serveur saturé à 12 TPS ajoute mécaniquement du délai même si le réseau est parfait.

Pour distinguer les deux causes, teste depuis la machine du joueur :

# Latence brute et perte de paquets
ping -c 20 ton-serveur.exemple.fr

# Trajet complet, saut par saut
mtr -rwc 50 ton-serveur.exemple.fr

# Vérifier que le port de jeu répond
nc -vzu ton-serveur.exemple.fr 27015

Une latence stable à 45 ms avec 0 % de perte est excellente. Une latence à 25 ms avec 3 % de perte donnera une expérience bien pire : les paquets perdus obligent le client à extrapoler, ce qui produit les fameux téléportations arrière.

Le rôle de la localisation géographique

La vitesse de la lumière dans la fibre impose un plancher incompressible d'environ 1 ms pour 100 km, doublé pour l'aller-retour, auquel s'ajoutent les équipements traversés. Une communauté majoritairement française gagne concrètement à être servie depuis une infrastructure en France plutôt que depuis l'autre côté de l'Atlantique, où le plancher dépasse déjà 80 ms.

Interpolation et compensation de lag

Les moteurs compensent une partie du délai côté client : interpolation entre deux états reçus, prédiction du mouvement local, réconciliation quand le serveur corrige. C'est pourquoi un tick rate plus élevé n'améliore pas seulement la précision : il réduit l'intervalle à interpoler, donc l'écart entre ce que tu vois et ce que le serveur calcule. Sur les jeux de tir comme Rust, la différence est immédiatement perceptible.

Configuration, mods et administration d'un serveur de jeu

Les paramètres qui coûtent le plus cher en performance

Avant d'ajouter des ressources matérielles, passe en revue les réglages qui multiplient la charge. Sur un fichier server.properties Minecraft :

view-distance=8
simulation-distance=6
max-players=40
entity-broadcast-range-percentage=80
sync-chunk-writes=false
network-compression-threshold=512

Passer view-distance de 12 à 8 réduit la surface simulée d'environ 55 %. Sur ARK, ce sont les taux de reproduction et le nombre de structures par tribu ; sur Serveur Rust, la taille de carte et la densité d'entités ; sur Serveur Valheim, le nombre de zones actives simultanément.

Mods et plugins : la première cause de chute de TPS

Un plugin mal écrit qui parcourt tous les blocs d'une région à chaque tick suffit à faire tomber un serveur correctement dimensionné. Avant d'accuser le matériel, profile :

• Minecraft : spark profiler start puis spark profiler stop pour identifier les méthodes coûteuses.
• FiveM : resmon 1 en console pour repérer les ressources dépassant 0,5 ms.
• ARK / Rust : désactive les mods un par un et observe la variation de la charge processeur.

La règle de terrain : n'installe jamais plus de deux ou trois nouveaux modules à la fois, sinon le diagnostic devient impossible.

Panel, sauvegardes et journaux

Un panel comme Pterodactyl centralise la console en direct, l'accès aux fichiers, les redémarrages planifiés, l'installation de modpacks et la gestion de sous-utilisateurs pour ton équipe de modération. C'est aussi là que tu lis les journaux, seul endroit où un crash raconte vraiment ce qui s'est passé. La documentation officielle Pterodactyl détaille la logique des allocations et des limites de conteneur.

Côté sauvegardes, applique la règle simple : une sauvegarde automatique fréquente, plus une copie manuelle avant toute mise à jour majeure ou changement de mod. Restaurer prend cinq minutes, reconstruire une base détruite prend un mois de motivation à ta communauté.

Hygiène de sécurité pour un administrateur

La protection anti-DDoS volumétrique est traitée en amont au niveau de l'infrastructure. Le reste dépend de toi :

• Mot de passe RCON long et unique, jamais partagé sur Discord.
• Whitelist active pendant les phases de test ou d'événement privé.
• Mises à jour du jeu et des plugins suivies, surtout après une faille publiée.
• Comptes de modération séparés, avec les permissions strictement nécessaires.

Si tu administres toi-même une machine Linux pour y faire tourner tes instances, les bases restent identiques :

# Authentification par clé plutôt que par mot de passe
ssh-keygen -t ed25519 -C "admin-jeu"
ssh-copy-id -i ~/.ssh/id_ed25519.pub admin@ip-machine

# Pare-feu minimal
ufw default deny incoming
ufw allow 22/tcp
ufw allow 25565/tcp
ufw enable

# Protection contre le bruteforce SSH
apt install fail2ban -y
systemctl enable --now fail2ban

Vérifie ensuite l'état du service et lis ses journaux avec systemctl status et journalctl -u nom-du-service -f. D'autres guides pratiques sont regroupés sur le Blog Fly-Serv.

Méthode de diagnostic en cinq étapes

1. Mesure d'abord. Note le TPS, la charge processeur, la mémoire utilisée et le ping avant toute modification.
2. Sépare réseau et calcul. TPS bas = problème de simulation. TPS bon mais joueurs qui lagguent = problème réseau ou client.
3. Profile la simulation. Identifie la ressource ou l'entité responsable plutôt que d'augmenter la mémoire au hasard.
4. Change une variable à la fois. Distance de vue, puis mods, puis limites d'entités.
5. Documente. Garde une trace des réglages appliqués et de leur effet, cela évite de refaire deux fois le même test.

Cette discipline règle la majorité des ralentissements sans toucher au matériel. Le complément utile reste la lecture de la documentation du jeu concerné : le wiki Minecraft sur server.properties reste la référence pour comprendre chaque clé de configuration.

Ce qu'il faut retenir

Un serveur de jeu tient sur trois piliers : une fréquence processeur suffisante pour terminer chaque tick à temps, une mémoire correctement dimensionnée, et un réseau proche des joueurs avec peu de perte de paquets. Les réglages du monde et la qualité des mods pèsent souvent plus lourd que le matériel. Mesure, isole, ajuste, sauvegarde : c'est tout le métier d'administrateur.

FAQ

Pourquoi mon serveur affiche un bon ping mais lagge quand même ?

Parce que le lag ne vient pas du réseau mais de la simulation. Si le tick rate chute (par exemple 12 TPS au lieu de 20 sur Minecraft), le monde avance au ralenti même avec 20 ms de latence. Vérifie la charge processeur, profile tes plugins avec spark ou resmon, puis réduis la distance de simulation et le nombre d'entités actives.

Faut-il privilégier beaucoup de cœurs ou une fréquence élevée ?

La fréquence, dans la grande majorité des cas. La boucle principale de la plupart des moteurs tourne sur un seul thread : un cœur rapide termine son tick plus tôt qu'un cœur lent, quel que soit le nombre total de cœurs. Les cœurs supplémentaires servent aux tâches annexes (sauvegardes, compression réseau, requêtes base de données).

Combien de mémoire allouer pour éviter les freezes ?

Alloue ce dont ton monde a réellement besoin, pas le maximum disponible. Trop de mémoire allouée à la JVM allonge les pauses du ramasse-miettes. Fixe -Xms et -Xmx à la même valeur, surveille les logs GC, et augmente par paliers de 1 à 2 Go seulement si tu observes des saturations répétées.