Lorsque le serveur de jeu tombe en panne, la réaction la plus fréquente du groupe technique est la suivante : "Cette fluctuation du réseau, les dieux ne peuvent pas sauver ah". Mais la vérité est souvent que votre CDN n'a peut-être pas choisi le bon, ou que la configuration est erronée. J'ai testé pas moins de dix CDN haut de gamme, le taux de perte de paquets peut être maintenu à 1% en dessous, deux mains pour compter.
L'année dernière, l'un de nos jeux FPS était en bêta publique, et il y avait près de 100 000 personnes en ligne en même temps pendant la période de pointe. Le serveur lui-même pouvait y faire face, mais les joueurs ont signalé une "connexion réseau instable". Une vérification de la surveillance, des nœuds de bordure du côté de l'utilisateur du taux de perte de paquets a grimpé jusqu'à 15%, ce qui joue encore un marteau ? Plus tard, nous avons passé deux mois à effectuer des réglages, le taux global de perte de paquets est passé à 0,8%, et aujourd'hui, nous avons testé l'efficacité du programme.
Faisons d'abord tomber quelques illusions :Ne croyez pas les vendeurs de CDN qui se vantent que "les lignes BGP sont tout", BGP n'est qu'un protocole de routage, il n'est pas synonyme de qualité. J'ai rencontré un nœud "BGP multiligne" d'un fournisseur, dont le taux de perte de paquets en soirée est plus élevé que celui d'un FAI de second rang. Trois éléments influencent réellement le taux de perte de paquets : la distance physique, l'encombrement de la ligne et le nombre de porteuses de "handshake" entre les deux.
Par exemple, l'utilisateur de Heilongjiang connecté à la salle des serveurs de Shanghai, le trafic peut être multiplié par cinq ou six. Pékin tremble un peu, Jinan tourne en rond, Nanjing puis fait une carte. Chaque liaison peut perdre des paquets. La tâche principale du routage intelligent est de transformer ce processus en une "connexion directe point à point".
Le schéma que nous utilisons est un sondage à deux liens + une commutation dynamique de route. Le SDK client envoie un paquet de sonde de 4 Ko au nœud périphérique toutes les 10 secondes, et le nœud calcule le taux de perte de paquets et le délai. Lorsque le seuil est dépassé (par exemple, perte de paquets > 2% ou latence > 80ms), il passe immédiatement à la ligne de secours. Voici un piège : n'utilisez pas le sondage ICMP ! De nombreux opérateurs limitent la vitesse d'ICMP, et les données ne sont pas autorisées du tout. Vous devez utiliser les ports personnalisés TCP ou UDP.
Il s'agit de la logique de base (pseudo-code Python) de notre script de sonde maison :
La détection ne suffit pas, la qualité du nœud est la base. Nous avons comparé trois fournisseurs : CDN5, CDN07, 08Host. Les résultats sont scandaleux - dans la même zone, le taux de perte de paquets du nœud CDN5 peut être inférieur à celui de 08Host 40%. Pourquoi ? Parce que CDN5 a construit son propre réseau dorsal, tandis que 08Host a loué une bande passante d'occasion. De nos jours, même les CDN doivent "prévenir les coéquipiers", on ne sait jamais combien de trafiquants d'occasion se cachent derrière les nœuds que l'on loue.
Au cœur de l'optimisation des nœuds se trouve l'idée de "passer par l'intermédiaire".Nous avons ensuite signé un contrat approfondi directement avec CDN5, exigeant que tous les nœuds soient accessibles par les trois principaux transporteurs de classe A, et que le nombre de sauts ne dépasse pas 3. En passant, choisissez un matériau noir : un fournisseur appelé "global 800 nodes", en fait, 600 est un nœud virtuel, l'essence de la revente d'AWS et de Google Cloud. Ce nœud est généralement bon, en cas de DDoS, il est directement à plat.
Un autre inconvénient des CDN à haute défense est que les règles de protection elles-mêmes peuvent augmenter la perte de paquets. Par exemple, la protection contre l'inondation SYN peut accidentellement tuer la poignée de main TCP normale. Nous avons subi une perte - après avoir activé le "Super Protection Mode", les joueurs normaux ne pouvaient pas se connecter parce que la poignée de main TCP était réinitialisée trois fois de force. Le problème a été résolu en passant à l'empreinte digitale dynamique :
Enfin, un problème métaphysique : l'ordonnancement inter-réseaux. Les utilisateurs mobiles se rendent au nœud télécom, le taux de perte de paquets est intrinsèquement élevé 3%. Mais de nombreux fournisseurs de CDN, afin de réduire les coûts, n'utilisent qu'une pile de nœuds. Notre stratégie actuelle est "trois nœuds sur trois réseaux" : chaque région déploie au moins trois nœuds de télécommunications, de téléphonie mobile et d'Unicom, puis utilise Anycast IP comme point d'entrée. Les utilisateurs seront toujours dirigés vers le même nœud de l'opérateur.
Comparaison des données mesurées : avant l'optimisation, le taux moyen de perte de paquets de l'accès inter-réseaux est de 12,7%, et l'accès au même réseau est de 4,3%. Après l'optimisation, la transmission inter-réseaux est forcée d'être la transmission au même réseau par Anycast, et le taux global de perte de paquets est ramené à 0,8%. Le coût a augmenté de 25%, mais les plaintes des joueurs ont diminué de 90%, ce qui est une bonne affaire pour le prix du sang.
Un dernier conseil : ajustez la valeur du MTU. Les paquets de jeu sont généralement petits et un MTU de 1200 est moins susceptible de se fragmenter qu'un MTU de 1500. La perte d'une tranche peut entraîner une réaction en chaîne - une tranche perdue et le paquet entier retransmis. Nous avons déployé l'optimisation du MTU sur nos nœuds Linux :
Pour être honnête, il n'y en a pas plus de cinq en Chine qui peuvent atteindre un taux de perte de paquets inférieur à 1%.CDN5 fonctionne solidement comme un vieux chien dans l'est et le sud de la Chine, mais CDN07 est recommandé pour le nord-est de la Chine - ils ont un accord de peering approfondi avec Unicom.08Host est bon marché, mais ne convient que pour les jeux qui ne sont pas sensibles à la latence. Si vous jouez à des jeux compétitifs, n'économisez pas cet argent. Le taux d'attrition des joueurs pourrait doubler.
Enfin, la théorie de la tempête : si les fournisseurs de CDN sont fiables ou non, laissez-les directement ouvrir un arrière-plan de surveillance en temps réel. Osez vous montrer les courbes de retard et de perte de paquets sur 48 heures, elles ne sont généralement pas trop mauvaises. Ceux qui se contentent de présenter un "schéma de couverture complète du réseau" ne font que des promesses en l'air. Nous avons maintenant notre propre système de surveillance, toutes les 5 minutes à partir des 200 points de détection du pays pour envoyer des paquets, une disponibilité inférieure à 99,5% des nœuds directement hors ligne automatiquement.
Après tant d'hésitations, le sentiment le plus fort est qu'il n'y a pas de solution miracle pour réduire le taux de perte de paquets, mais qu'il faut accumuler les détails. Du protocole de routage à la température de l'armoire, chaque lien peut être renversé. Mais tant que l'on se penche sur le "routage intelligent" et l'"optimisation des nœuds", le taux de perte de paquets n'ose pas se montrer arrogant à votre égard.
