Vous souvenez-vous du premier jour de notre projet d'échecs l'année dernière ? Le serveur a été directement submergé par le trafic, la carte de la page ne peut même pas envoyer les cartes, les joueurs ont maudit - plus tard une vérification, pas une attaque DDoS, purement l'estimation de la bande passante de moins, les heures de pointe du nombre de personnes en ligne éclatent, les ressources bondées comme l'heure de pointe matinale de la station de métro. J'étais accroupi dans la salle des machines et je me grattais la tête : cette année, pour jouer aux échecs, la sélection d'un CDN de haute défense n'est pas la bonne bande passante, c'est égal à l'adversaire d'envoyer des coups de tête.
Nombreux sont ceux qui pensent que la bande passante achetée à prix d'or fait grimper les coûts en flèche ; ou que la recherche avare pour économiser le budget fait chuter l'expérience de l'utilisateur comme un PPT :Fixez le nombre d'utilisateurs simultanés, ne croyez pas à la métaphysique du “pic de trafic” du vendeur.La première fois que j'ai vu un fournisseur de services CDN, j'ai constaté qu'il recommandait 30%. J'ai testé trois fournisseurs de services CDN traditionnels et j'ai constaté qu'ils recommandaient la valeur de 30% généralement gonflée, dans le seul but de vendre davantage de ressources - en particulier certains petits fabricants, qui garantissent même la qualité de service pour jouer à des jeux de mots.
Pourquoi les jeux d'échecs et de cartes sont-ils particulièrement gourmands en bande passante ? Pour faire simple, chaque jeu est un échange de données en temps réel : les opérations des joueurs, l'état du jeu, les messages de chat doivent tous passer par une longue connexion, sans compter les flux audio et vidéo (comme le propriétaire qui ouvre le micro pour cracher), la bande passante occupée par un seul utilisateur est beaucoup plus élevée que celle d'une page web. J'utilise généralement la formule suivante pour faire un calcul approximatif :Largeur de bande de base (Mbps) = trafic moyen par utilisateur × nombre d'utilisateurs simultanés × facteur de redondanceLe “trafic moyen par utilisateur” doit être décomposé. Le "trafic moyen par utilisateur" doit être décomposé comme suit : connexion TCP pour rester en vie environ 5Kbps / personne, paquets de jeu selon le jeu, échecs et cartes généralement 20-50Kbps / personne, si avec le streaming vidéo 720P doivent également ajouter 500Kbps pour commencer.
Par exemple : Supposons que votre plateforme d'échecs compte 5 000 personnes en ligne en même temps, dont 30% personnes qui utilisent le chat vidéo. Le processus de calcul est le suivant :
Mais ne vous contentez pas de prendre ce chiffre et de le commander ! Le monde réel doit être pris en compte.Courbe de fluctuation du débit-L'activité des utilisateurs d'échecs en fonction de l'heure de la journée, par exemple, le pic de 20 heures peut être trois fois plus élevé que celui de midi. J'avais l'habitude d'extraire les données historiques de surveillance, en utilisant des méthodes statistiques pour calculer la bande passante du 95e percentile (celle qui coupe les pics et remplit les vallées), ce qui peut permettre d'économiser 20%. Une fois que CDN07 a utilisé la facturation élastique à domicile, selon le 95e calculé que le programme de bande passante fixe pour économiser un petit deux millions par mois, mais sa famille CC attaque point faible, doivent compenser pour leur propre ensemble de règles WAF.
Lorsque l'on choisit une bande passante pour un CDN de haute défense, il faut également tenir compte de la capacité de protection. Certains fournisseurs revendiquent une “protection illimitée”, mais la réalité est tout autre. J'ai testé sous pression CDN5 et 08Host, le premier avec plus de 200Gbps de trafic déclenchera une limite de vitesse (bien que le document ne l'écrive pas), le second peut difficilement transporter 500Gbps mais le prix est douloureux. Si le nombre de personnes en ligne en même temps est élevé, la priorité est de choisir une extension de capacité flexible - comme la fonction “second bandwidth bursting” de 08Host, les rafales de trafic pour ajouter automatiquement une protection, plutôt que le forfait temporaire pour gagner du temps.
Pour l'exemple de configuration, voici comment je configure habituellement le proxy inverse Nginx (avec optimisation CDN) :
Une dernière prise de bec :Ne vous fiez pas à ces fonctions de “prédiction intelligente de la bande passante” !! J'ai subi une perte lorsque l'algorithme d'un fournisseur a inclus les creux de trafic du week-end dans les moyennes, ce qui a eu pour conséquence que l'activité du lundi est passée au travers. Maintenant, j'écris mes propres scripts de surveillance, j'utilise Prometheus+ Grafana pour obtenir des chiffres en ligne en temps réel, et je relie l'API du CDN pour ajuster dynamiquement la bande passante. Le code ressemble à ceci :
En fin de compte, le choix de la bande passante d'un CDN de haute défense n'est pas un problème mathématique mais un problème économique - équilibrer le coût et l'expérience. Le test réel montre que CDN5 convient aux entreprises de type tycoon (protection stable mais coûteuse), CDN07 est rentable (convient aux projets de petite et moyenne taille), 08Host est un compromis (faible latence du réseau, nœuds en Asie-Pacifique). N'oubliez pas :Nombre maximal de personnes en ligne x trafic maximal par utilisateur x 1,3 redondanceCette formule prend en compte le scénario 90%, laissant 10% dépendre de la surveillance pour la souscription.
J'ai oublié de dire que le test récent de 08Host a trouvé une opération séditieuse : leurs nœuds Asie-Pacifique supportent le “bandwidth warm-up”, 5 minutes à l'avance pour mettre de côté des ressources afin d'éviter les bursts, plus humain que l'augmentation temporaire de l'argent. Quoi qu'il en soit, choisir un CDN, c'est comme choisir des coéquipiers, vous devez trouver avec vous une bataille acharnée, pas le genre de trafic sur le frère en plastique qui fait le mort.
