Perte de paquets
La perte de paquets correspond à des données qui n'arrivent jamais. Sous UDP, le jeu ne l'attend pas. Le client continue de faire des prédictions à partir du dernier état dont il dispose, de sorte que chaque mise à jour perdue prolonge la fenêtre dans laquelle il devine. La correction lors de la réception de la mise à jour suivante est plus importante et visible.
,
Que se passe-t-il lorsqu'un paquet de jeu est perdu ?
Un jeu multijoueur est un flux de petits paquets dans les deux sens. Le client du joueur envoie des commandes au serveur plusieurs fois par seconde, et le serveur renvoie des instantanés du monde. De nombreux jeux envoient un instantané par battement, et les serveurs d'Apex Legends battent 20 fois par seconde (Respawn, avril 2021). La perte de paquets signifie que certains de ces paquets n'arrivent jamais. Le protocole UDP ne les renvoie pas, et la partie ne se met pas en pause pour attendre, de sorte que le destinataire continue avec ce qu'il a appris en dernier.
Le coût de la perte dépend du paquet qui a disparu :
Un instantané perdu (du serveur au client). Le client n'a pas de nouvel état pour combler le vide. Il continue d'afficher le dernier état qu'il a reçu, ou devine la suite à partir de celui-ci, et les autres joueurs se téléportent là où ils se trouvent réellement lorsque l'instantané suivant arrive.
Une commande perdue (du client au serveur). Le serveur ne sait jamais que le joueur a appuyé sur une touche, il continue donc généralement à simuler le joueur avec la dernière commande qu'il a reçue. Le propre client du joueur a déjà agi en fonction de cette commande, il est donc corrigé lorsque la réponse du serveur arrive. Le document de mise en réseau de TRIBES II, par Mark Frohnmayer et Tim Gift, décrit cela comme une désynchronisation des copies du personnage du client et du serveur, avec une brève déformation visible (Modèle réseau de TRIBES II).
Dans les deux cas, un paquet perdu est un vide dans ce que le jeu sait, et le jeu comble ce vide avec une supposition. La taille de ces suppositions et la manière dont les jeux parviennent à les limiter font l'objet du reste de cette page. La correction elle-même est ce que couvre la désynchronisation.
En pratique - Aperçus du blog de Edgegap
Points clés de l'article
La latence a un plancher incompressible, et tout le reste s'y ajoute : Le temps de trajet physique entre deux machines est le délai minimal que tout jeu en ligne peut avoir. Le routage, le tickrate, le taux de rafraîchissement et le traitement s'y ajoutent tous. Le netcode ne peut pas supprimer ce délai. Il peut seulement décider où les joueurs le ressentent.
Le chemin le plus court est rarement le plus rapide : Une connexion directe en peer-to-peer semble être le trajet le plus court entre deux joueurs, mais les paquets traversent quand même les FAI des deux joueurs et les itinéraires que ces réseaux choisissent. Un serveur bien placé entre eux est souvent à la fois plus rapide et plus équitable.
La compensation de lag déplace le coût, elle ne l'efface pas : La compensation de lag rembobine le serveur pour que le tir d'un joueur à fort ping soit pris en compte, ce qui signifie que la cible peut être touchée après s'être mise à couvert. La seule vraie solution consiste à maintenir de faibles écarts de ping, ce qui en fait autant un problème de matchmaking et de placement de serveur que de netcode.
Le tickrate est un budget temps : Le tickrate d'un serveur définit le nombre de millisecondes dont il dispose pour simuler chaque étape du jeu. Des fréquences plus élevées réduisent le délai et améliorent la détection des tirs, mais consomment plus de CPU et de bande passante. Un serveur qui dépasse son budget saccade pour tout le monde dans la partie.
Deux choix distincts, et non un seul : L'endroit où le jeu s'exécute (peer-to-peer, relais ou serveur dédié) et la manière dont l'état est partagé (lockstep, rollback ou réplication d'état) sont des décisions indépendantes. N'importe quel modèle de synchronisation peut fonctionner sur n'importe quel modèle d'hébergement.
Quels paquets perdus un jeu renvoie-t-il, et lesquels ignore-t-il ?
Sous UDP, le protocole ne renvoie rien, c'est donc le jeu qui décide, un type de données à la fois. L'article de TRIBES II présente trois réponses courantes :
L'état est remplacé, pas renvoyé. Lorsqu'un paquet transportant l'état d'un objet est signalé comme perdu, le serveur ne renvoie pas le contenu de ce paquet. Il marque à nouveau les valeurs modifiées de l'objet comme non envoyées et transmet l'état actuel de l'objet à la prochaine occasion, à moins qu'un paquet ultérieur ne l'ait déjà transporté. L'article appelle cela l'approche du « Dernier État en Date » (Most Recent State) et indique qu'elle garantit uniquement l'arrivée de la dernière version.
Les événements sont renvoyés. Un coup de feu tiré ou un objet ramassé ne se produit qu'une seule fois, et l'instantané suivant ne le remplace pas. TRIBES II retransmet ces événements « garantis » et les traite dans l'ordre. Les événements marqués comme non garantis ne sont jamais retransmis.
Les entrées sont envoyées plus d'une fois. Chaque mouvement voyageait dans trois paquets consécutifs, de sorte qu'un mouvement n'était perdu que si trois paquets consécutifs étaient abandonnés. Chaque paquet provenant du client transportait les mouvements que le serveur n'avait pas encore confirmés.
La redondance a un coût, et l'article le souligne. Le premier TRIBES (1998) incluait chaque mouvement non acquitté dans chaque paquet, ce qui garantissait la livraison. Mais une perte de paquet élargissait la fenêtre, le paquet plus volumineux était plus susceptible d'être perdu, et la boucle s'auto-alimentait. TRIBES II a réduit le nombre de renvois pour y mettre fin.
Une fenêtre de saisie nécessite un plafond pour la même raison.
Comment les jeux vidéo masquent-ils une mise à jour perdue ?
Lorsque l'état vient à manquer, le client doit tout de même afficher quelque chose. L'explication de Modern Warfare 2019 d'Infinity Ward, telle que résumée dans l'article d'Edgegap sur le netcode de Call of Duty, décrit trois réponses, combinées pour chaque joueur en fonction de leur connexion :
La mise en mémoire tampon (buffering) maintient le client légèrement en retard par rapport aux dernières données, de sorte qu'un paquet retardé ne provoque pas de saccade. Le coût est le délai.
L'extrapolation suppose que le joueur continue de faire ce qu'il faisait. Le coût est un sursaut visible lorsqu'il change de direction.
La prédiction traite l'entrée extrapolée comme si le serveur l'avait confirmée. Le coût est une correction plus importante, et un excès de prédiction rend le jeu difficile à jouer sur une mauvaise connexion.
Chaque réponse transforme la perte en autre chose : un délai, une supposition ou une correction.
Overwatch protège plutôt le côté des entrées (inputs). Lorsque le serveur n'a plus d'entrées à simuler, il demande au client de simuler légèrement plus vite pendant un moment, afin que le tampon d'entrées du serveur se remplisse à nouveau avant que la perte ne provoque des erreurs de prédiction. Chaque paquet regroupe également toutes les entrées que le serveur n'a pas encore confirmées. Ces deux techniques sont issues de la conférence de Timothy Ford à la GDC 2017, résumée dans l'analyse approfondie d'Overwatch par Edgegap. Le coût se déplace à nouveau : un peu de bande passante et un léger décalage dans le timing.
L'interpolation et la prédiction côté client couvrent ces mécanismes en profondeur.
Pourquoi la répartition des pertes importe-t-elle plus que le pourcentage ?
Le pourcentage de perte indique combien de paquets ont disparu. Il n'indique pas comment ils ont disparu, et c'est pourtant cela qui détermine si un joueur le remarque.
Chaque système de défense couvre une interruption d'une certaine durée, ce qui importe est donc le nombre de paquets consécutifs perdus. Prenons un serveur qui envoie une mise à jour par tick à 20 ticks par seconde, le rythme de fonctionnement des serveurs d'Apex Legends (Respawn, avril 2021). Chaque mise à jour perdue ajoute 50 ms à l'interruption.
Ce qui est perdu | Interruption | Ce qui la couvre |
|---|---|---|
Un instantané (snapshot) | 50 ms | La mémoire tampon d'interpolation. Le moteur Source de Valve est configuré par défaut à 100 ms, ainsi une mise à jour perdue en laisse encore deux entre lesquelles effectuer la transition (Valve). |
Cinq instantanés consécutifs | 250 ms | Pas cette mémoire tampon. Le client conserve le dernier état ou extrapole, puis corrige lorsque la mise à jour suivante arrive. |
Un ou deux paquets d'entrée consécutifs | n/a | La redondance. TRIBES II envoyait chaque mouvement dans trois paquets consécutifs. |
Trois paquets d'entrée consécutifs | n/a | Non couvert. Les mouvements propres à ces paquets sont perdus, et la position du joueur est corrigée. |
Deux connexions peuvent toutes deux afficher une perte moyenne de 5 %. L'une perd des paquets de manière isolée, ce que les défenses ci-dessus absorbent généralement. L'autre les perd par rafales, ce qu'elles ne font pas. Le pourcentage est le même, mais l'expérience est différente.
Suivez donc la plus longue série de paquets perdus consécutifs pour chaque joueur, à côté de la moyenne. Ce seul chiffre montre si la perte est absorbée ou non. Les interruptions indiquées ici sont des estimations basées sur les chiffres cités.
Un taux de rafraîchissement plus élevé réduit chaque interruption, au prix d'une augmentation de la bande passante. Respawn a calculé que faire passer Apex de 20 Hz à 60 Hz triplerait cette dernière, la faisant passer d'environ 60 ko/s à 180 ko/s.
Un mot de notre sponsor (nous-mêmes !)
La majeure partie du lag provient de la distance, non du code. L'Edge Cloud d'Edgegap est un réseau distribué disposant de plus de 615 emplacements disponibles sur demande, garantissant que chaque partie se déroule au meilleur endroit possible pour ses joueurs. Des tests indépendants sur le trafic d'un studio en direct ont mesuré une baisse de 58 % du temps de trajet aller-retour moyen par rapport au cloud public.
Comment savoir où se situe la perte ?
Loss can start in four places, and the developer owns only one: the player's home network, their internet provider, the route between that provider and the data center, and the data center itself.
Respawn's 2021 deep dive found loss in several of them: on a player's provider network, on the link between a provider and its data center, and on return routes that differ from the outbound path. It also traced severe loss, across every game on a handful of servers, to one faulty network device in a data center, while the servers themselves were fine. Its own summary of most loss reports was that it is "probably not your fault", and usually not the developer's either (Respawn).
What separates the places is where the loss clusters. Loss that follows one player is their connection. Loss that follows one server, across many players, points at that host or its network. Loss that follows one provider, across many servers, points at the route.
Apex gave players a performance display in Season 6 that shows packet loss and choke as a percentage of packets per second. A player can report "10% packet loss, 300 ms latency" instead of "lag", and the developer gets numbers it can sort by player and server.
Two kinds of data answer different questions. Loss counters, per player and per server, show what did not arrive. A packet capture shows what each packet carried. Some netcode libraries record captures on the server: SnapNet's Unreal SDK writes them as JSON files that open in Chrome's tracing viewer, with segment widths proportional to the bits each entity and field uses (SnapNet documentation). That is bandwidth data, which is what tells you whether sending each input three times, or raising the update rate, is affordable. Their documentation advises capturing a few seconds at a time, because the files grow quickly.
L'avis d'Edgegap (ce n'est que notre opinion, à prendre avec des pincettes !)
La perte de paquets commence souvent en dehors de votre jeu, alors concevez votre système en conséquence et mesurez-la
La perte de paquets est souvent une caractéristique de la connexion, y compris du Wi-Fi et du matériel domestique, et le rôle du jeu est de faire avec. Les données de Respawn pointent dans la même direction : les réseaux des fournisseurs, la liaison vers le centre de données et un seul équipement défectueux.
Mesurez donc sa capacité à faire face. Enregistrez la perte par direction, ainsi que la plus longue série de paquets perdus consécutifs pour chaque joueur, et associez à chaque match l'emplacement de son serveur. Comparez la plus longue série avec ce que votre fenêtre de redondance et votre mémoire tampon peuvent couvrir. Si les séries s'y intègrent, la perte est absorbée. Si ce n'est pas le cas, élargissez les défenses ou vérifiez si la perte se situe sur un serveur ou un emplacement spécifique, ce qui correspond à du matériel sur lequel vous pouvez intervenir.
Edgegap ne publie pas de chiffres sur la perte de paquets, et aucun placement de serveur ne peut corriger le réseau domestique d'un joueur. Un trajet plus court offre à chaque joueur, y compris ceux en Wi-Fi, plus de marge pour les défenses, car un renvoi ou une correction coûte un aller-retour. Cela réduit également l'écart entre les joueurs : dans l'étude 1v1 d'Edgegap de 2020, le placement par match l'a réduit dans 66 % des cas, de 31 ms en moyenne (étude de cas 1v1).
,
