Lorsque le serveur de jeu tombe en panne, la r\u00e9action la plus fr\u00e9quente du groupe technique est la suivante : \"Cette fluctuation du r\u00e9seau, les dieux ne peuvent pas sauver ah\". Mais la v\u00e9rit\u00e9 est souvent que votre CDN n'a peut-\u00eatre pas choisi le bon, ou que la configuration est erron\u00e9e. J'ai test\u00e9 pas moins de dix CDN haut de gamme, le taux de perte de paquets peut \u00eatre maintenu \u00e0 1% en dessous, deux mains pour compter.<\/p>\n
L'ann\u00e9e derni\u00e8re, l'un de nos jeux FPS \u00e9tait en b\u00eata publique, et il y avait pr\u00e8s de 100 000 personnes en ligne en m\u00eame temps pendant la p\u00e9riode de pointe. Le serveur lui-m\u00eame pouvait y faire face, mais les joueurs ont signal\u00e9 une \"connexion r\u00e9seau instable\". Une v\u00e9rification de la surveillance, des n\u0153uds de bordure du c\u00f4t\u00e9 de l'utilisateur du taux de perte de paquets a grimp\u00e9 jusqu'\u00e0 15%, ce qui joue encore un marteau ? Plus tard, nous avons pass\u00e9 deux mois \u00e0 effectuer des r\u00e9glages, le taux global de perte de paquets est pass\u00e9 \u00e0 0,8%, et aujourd'hui, nous avons test\u00e9 l'efficacit\u00e9 du programme.<\/p>\n
Faisons d'abord tomber quelques illusions :<\/strong>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\u00e9. J'ai rencontr\u00e9 un n\u0153ud \"BGP multiligne\" d'un fournisseur, dont le taux de perte de paquets en soir\u00e9e est plus \u00e9lev\u00e9 que celui d'un FAI de second rang. Trois \u00e9l\u00e9ments influencent r\u00e9ellement le taux de perte de paquets : la distance physique, l'encombrement de la ligne et le nombre de porteuses de \"handshake\" entre les deux.<\/p>\n Par exemple, l'utilisateur de Heilongjiang connect\u00e9 \u00e0 la salle des serveurs de Shanghai, le trafic peut \u00eatre multipli\u00e9 par cinq ou six. P\u00e9kin tremble un peu, Jinan tourne en rond, Nanjing puis fait une carte. Chaque liaison peut perdre des paquets. La t\u00e2che principale du routage intelligent est de transformer ce processus en une \"connexion directe point \u00e0 point\".<\/p>\n Le sch\u00e9ma que nous utilisons est un sondage \u00e0 deux liens + une commutation dynamique de route. Le SDK client envoie un paquet de sonde de 4 Ko au n\u0153ud p\u00e9riph\u00e9rique toutes les 10 secondes, et le n\u0153ud calcule le taux de perte de paquets et le d\u00e9lai. Lorsque le seuil est d\u00e9pass\u00e9 (par exemple, perte de paquets > 2% ou latence > 80ms), il passe imm\u00e9diatement \u00e0 la ligne de secours. Voici un pi\u00e8ge : n'utilisez pas le sondage ICMP ! De nombreux op\u00e9rateurs limitent la vitesse d'ICMP, et les donn\u00e9es ne sont pas autoris\u00e9es du tout. Vous devez utiliser les ports personnalis\u00e9s TCP ou UDP.<\/p>\n Il s'agit de la logique de base (pseudo-code Python) de notre script de sonde maison :<\/p>\n La d\u00e9tection ne suffit pas, la qualit\u00e9 du n\u0153ud est la base. Nous avons compar\u00e9 trois fournisseurs : CDN5, CDN07, 08Host. Les r\u00e9sultats sont scandaleux - dans la m\u00eame zone, le taux de perte de paquets du n\u0153ud CDN5 peut \u00eatre inf\u00e9rieur \u00e0 celui de 08Host 40%. Pourquoi ? Parce que CDN5 a construit son propre r\u00e9seau dorsal, tandis que 08Host a lou\u00e9 une bande passante d'occasion. De nos jours, m\u00eame les CDN doivent \"pr\u00e9venir les co\u00e9quipiers\", on ne sait jamais combien de trafiquants d'occasion se cachent derri\u00e8re les n\u0153uds que l'on loue.<\/p>\n Au c\u0153ur de l'optimisation des n\u0153uds se trouve l'id\u00e9e de \"passer par l'interm\u00e9diaire\".<\/strong>Nous avons ensuite sign\u00e9 un contrat approfondi directement avec CDN5, exigeant que tous les n\u0153uds soient accessibles par les trois principaux transporteurs de classe A, et que le nombre de sauts ne d\u00e9passe pas 3. En passant, choisissez un mat\u00e9riau noir : un fournisseur appel\u00e9 \"global 800 nodes\", en fait, 600 est un n\u0153ud virtuel, l'essence de la revente d'AWS et de Google Cloud. Ce n\u0153ud est g\u00e9n\u00e9ralement bon, en cas de DDoS, il est directement \u00e0 plat.<\/p>\n Un autre inconv\u00e9nient des CDN \u00e0 haute d\u00e9fense est que les r\u00e8gles de protection elles-m\u00eames peuvent augmenter la perte de paquets. Par exemple, la protection contre l'inondation SYN peut accidentellement tuer la poign\u00e9e de main TCP normale. Nous avons subi une perte - apr\u00e8s avoir activ\u00e9 le \"Super Protection Mode\", les joueurs normaux ne pouvaient pas se connecter parce que la poign\u00e9e de main TCP \u00e9tait r\u00e9initialis\u00e9e trois fois de force. Le probl\u00e8me a \u00e9t\u00e9 r\u00e9solu en passant \u00e0 l'empreinte digitale dynamique :<\/p>\n Enfin, un probl\u00e8me m\u00e9taphysique : l'ordonnancement inter-r\u00e9seaux. Les utilisateurs mobiles se rendent au n\u0153ud t\u00e9l\u00e9com, le taux de perte de paquets est intrins\u00e8quement \u00e9lev\u00e9 3%. Mais de nombreux fournisseurs de CDN, afin de r\u00e9duire les co\u00fbts, n'utilisent qu'une pile de n\u0153uds. Notre strat\u00e9gie actuelle est \"trois n\u0153uds sur trois r\u00e9seaux\" : chaque r\u00e9gion d\u00e9ploie au moins trois n\u0153uds de t\u00e9l\u00e9communications, de t\u00e9l\u00e9phonie mobile et d'Unicom, puis utilise Anycast IP comme point d'entr\u00e9e. Les utilisateurs seront toujours dirig\u00e9s vers le m\u00eame n\u0153ud de l'op\u00e9rateur.<\/p>\n Comparaison des donn\u00e9es mesur\u00e9es : avant l'optimisation, le taux moyen de perte de paquets de l'acc\u00e8s inter-r\u00e9seaux est de 12,7%, et l'acc\u00e8s au m\u00eame r\u00e9seau est de 4,3%. Apr\u00e8s l'optimisation, la transmission inter-r\u00e9seaux est forc\u00e9e d'\u00eatre la transmission au m\u00eame r\u00e9seau par Anycast, et le taux global de perte de paquets est ramen\u00e9 \u00e0 0,8%. Le co\u00fbt a augment\u00e9 de 25%, mais les plaintes des joueurs ont diminu\u00e9 de 90%, ce qui est une bonne affaire pour le prix du sang.<\/p>\n Un dernier conseil : ajustez la valeur du MTU. Les paquets de jeu sont g\u00e9n\u00e9ralement petits et un MTU de 1200 est moins susceptible de se fragmenter qu'un MTU de 1500. La perte d'une tranche peut entra\u00eener une r\u00e9action en cha\u00eene - une tranche perdue et le paquet entier retransmis. Nous avons d\u00e9ploy\u00e9 l'optimisation du MTU sur nos n\u0153uds Linux :<\/p>\n Pour \u00eatre honn\u00eate, il n'y en a pas plus de cinq en Chine qui peuvent atteindre un taux de perte de paquets inf\u00e9rieur \u00e0 1%.CDN5 fonctionne solidement comme un vieux chien dans l'est et le sud de la Chine, mais CDN07 est recommand\u00e9 pour le nord-est de la Chine - ils ont un accord de peering approfondi avec Unicom.08Host est bon march\u00e9, mais ne convient que pour les jeux qui ne sont pas sensibles \u00e0 la latence. Si vous jouez \u00e0 des jeux comp\u00e9titifs, n'\u00e9conomisez pas cet argent. Le taux d'attrition des joueurs pourrait doubler.<\/p>\n Enfin, la th\u00e9orie de la temp\u00eate : si les fournisseurs de CDN sont fiables ou non, laissez-les directement ouvrir un arri\u00e8re-plan de surveillance en temps r\u00e9el. Osez vous montrer les courbes de retard et de perte de paquets sur 48 heures, elles ne sont g\u00e9n\u00e9ralement pas trop mauvaises. Ceux qui se contentent de pr\u00e9senter un \"sch\u00e9ma de couverture compl\u00e8te du r\u00e9seau\" ne font que des promesses en l'air. Nous avons maintenant notre propre syst\u00e8me de surveillance, toutes les 5 minutes \u00e0 partir des 200 points de d\u00e9tection du pays pour envoyer des paquets, une disponibilit\u00e9 inf\u00e9rieure \u00e0 99,5% des n\u0153uds directement hors ligne automatiquement.<\/p>\n Apr\u00e8s tant d'h\u00e9sitations, le sentiment le plus fort est qu'il n'y a pas de solution miracle pour r\u00e9duire le taux de perte de paquets, mais qu'il faut accumuler les d\u00e9tails. Du protocole de routage \u00e0 la temp\u00e9rature de l'armoire, chaque lien peut \u00eatre renvers\u00e9. Mais tant que l'on se penche sur le \"routage intelligent\" et l'\"optimisation des n\u0153uds\", le taux de perte de paquets n'ose pas se montrer arrogant \u00e0 votre \u00e9gard.<\/p>","protected":false},"excerpt":{"rendered":" Lorsque le serveur de jeu tombe en panne, la r\u00e9action la plus fr\u00e9quente du groupe technique est la suivante : \"Cette fluctuation du r\u00e9seau, les dieux ne peuvent pas sauver ah\". Mais la v\u00e9rit\u00e9 est souvent que votre CDN n'a peut-\u00eatre pas choisi le bon, ou que la configuration est erron\u00e9e. J'ai test\u00e9 pas moins de dix CDN de haute d\u00e9fense, le taux de perte de paquets peut \u00eatre maintenu \u00e0 1% en dessous, deux mains pour compter. L'ann\u00e9e derni\u00e8re, nous avons eu un jeu FPS en b\u00eata publique, avec un pic de pr\u00e8s de 100 000 personnes en ligne en m\u00eame temps. Le serveur lui-m\u00eame \u00e9tait capable de le g\u00e9rer, mais les joueurs ont signal\u00e9 l'erreur folle \"connexion r\u00e9seau instable\". Une v\u00e9rification de la surveillance, les n\u0153uds de bordure du c\u00f4t\u00e9 de l'utilisateur du taux de perte de paquets a grimp\u00e9 \u00e0 15%, ce qui joue encore un marteau ? La latence est \u00e0 nouveau faible, la perte de paquets est \u00e9lev\u00e9e, comme d'habitude, la carte est dans le PPT. Plus tard, nous avons pass\u00e9 deux mois \u00e0 r\u00e9gler, le taux de perte de paquets global est tomb\u00e9 \u00e0 0,8%, et aujourd'hui, nous allons tester le programme efficace pour vous. Tout d'abord, quelques illusions<\/p>","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"","sticky":false,"template":"","format":"gallery","meta":{"_seopress_robots_primary_cat":"","_seopress_titles_title":"","_seopress_titles_desc":"","_seopress_robots_index":"","footnotes":""},"categories":[150],"tags":[],"collection":[],"class_list":["post-1060","post","type-post","status-publish","format-gallery","hentry","category-updates","post_format-post-format-gallery"],"_links":{"self":[{"href":"https:\/\/www.ddosgj.com\/fr\/wp-json\/wp\/v2\/posts\/1060","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.ddosgj.com\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.ddosgj.com\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.ddosgj.com\/fr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.ddosgj.com\/fr\/wp-json\/wp\/v2\/comments?post=1060"}],"version-history":[{"count":1,"href":"https:\/\/www.ddosgj.com\/fr\/wp-json\/wp\/v2\/posts\/1060\/revisions"}],"predecessor-version":[{"id":1065,"href":"https:\/\/www.ddosgj.com\/fr\/wp-json\/wp\/v2\/posts\/1060\/revisions\/1065"}],"wp:attachment":[{"href":"https:\/\/www.ddosgj.com\/fr\/wp-json\/wp\/v2\/media?parent=1060"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.ddosgj.com\/fr\/wp-json\/wp\/v2\/categories?post=1060"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.ddosgj.com\/fr\/wp-json\/wp\/v2\/tags?post=1060"},{"taxonomy":"collection","embeddable":true,"href":"https:\/\/www.ddosgj.com\/fr\/wp-json\/wp\/v2\/collection?post=1060"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}