Je viens de traiter un problème en ligne avec un client, la tension artérielle a failli ne pas monter. Vous dites qu'une bonne station de commerce électronique, un grand jour à la maison soudainement l'écran blanc, l'utilisateur fou des plaintes. Une vérification, un bon gars, le CPU de la station source a directement grimpé à 100%, le pool de connexion de la base de données est plein. La cause première ? Une page de produit populaire a été crawler une deuxième demande des milliers de fois, chaque demande pénètre le CDN, directement de retour à la base de données de requête de source. Comment ce top ah est-il possible ? Le CDN à haute défense est évidemment suspendu, l'attaque est évitée, mais la vitesse ? La performance ? De l'argent dépensé en vain ! Le problème réside dans le fait que la stratégie de mise en cache n'est pas configurée correctement - soit une mise en cache intégrale, soit une mise en cache dynamique intégrale, sans faire le processus de différenciation.
J'ai vu trop d'équipes considérer le CDN de haute défense comme un simple “bouclier de trafic”, pensant que tant que l'ensemble peut être à la fois sûr et rapide. En fait, c'est une grave erreur. La valeur fondamentale du CDN haute défense, la moitié de la protection de la sécurité, l'autre moitié se trouve précisément dans le système de gestion du trafic.Conception correcte du cacheLe cache est un bon moyen de faire face à l'afflux de trafic. S'il est bien configuré, le cache peut non seulement supporter le pic de trafic, mais aussi vous permettre d'être touché lorsque l'utilisateur est complètement insensible et de continuer à naviguer ; s'il est mal configuré, l'attaque est évitée, mais l'utilisateur normal ne peut pas utiliser la carte, et la station source peut également être blessée par erreur.
Pourquoi le cache de votre CDN est-il toujours erroné ? Quatre-vingt pour cent d'entre eux ne comprennent pas le terme “séparation statique et dynamique”. Le contenu statique (images, CSS, JS, polices, etc.) et le contenu dynamique (interfaces API, données de session utilisateur, tarification en temps réel) sont fondamentalement deux types de créatures, mais vous utilisez le même ensemble de règles de mise en cache pour les traiter, cela ne peut-il pas se produire ? Le contenu statique devrait être mis en cache jusqu'à la mort, tandis que le contenu dynamique devrait être soigneusement contrôlé ou même complètement contourné.
Remarquez ici leimmuablequi indique au navigateur : ce fichier ne changera jamais dans votre vie, vous pouvez donc le lire à partir du cache local sans même envoyer de requête conditionnelle. Dans la pratique, cette méthode est extrêmement efficace pour réduire le nombre de requêtes en double et augmenter la vitesse.
Le plus grand casse-tête est le contenu dynamique. Par exemple, la page des détails du produit, la plupart du contenu est statique (description du produit, images), mais une petite partie du contenu est dynamique (quantité en stock, pseudonymes des utilisateurs). Tout mettre en cache, les données vont expirer ; ne pas mettre en cache, la station source est soumise à une forte pression. C'est ici que nous devons offrir mon préféré “Cache partiel”(Edge Side Includes) ou le plus moderne “informatique de pointe”Programme up.
Prenons l'exemple de CDN07, sa fonction de bordure est très utile. Vous pouvez écrire un simple morceau de logique JS pour lancer des sous-demandes de contenu dynamique uniquement au niveau du nœud de bordure, les fusionner et les renvoyer à l'utilisateur :
De cette manière, le corps principal de la page est mis en cache pendant 10 minutes, tandis que les modules dynamiques sont récupérés en temps réel sur demande. Cela réduit la pression sur la station source et garantit la disponibilité en temps réel des données de base.
Veillez à définir les facteurs susceptibles d'affecter les modifications de contenu dans le cadre de la clé de mise en cache. Par exemple :
mais veillez àExclusion des facteurs qui n'affectent pas le contenuIl est important de mettre en place des paramètres de suivi, tels que User-Agent (à moins que vous ne produisiez un contenu différent pour le mobile et le PC), ou un paramètre de suivi (tel que utm_source). Sinon, vous mettrez en cache un nombre incalculable de copies de la même ressource, et le taux de réussite de la mise en cache ne fera que chuter.
Il existe un autre scénario particulier pour les CDN à haute défense :Stratégie de mise en cache en cas d'attaques CC. Lorsque le CDN reconnaît qu'une URL fait l'objet d'un nettoyage sauvage, vous pouvez définir une règle spéciale : mettre en cache la réponse à cette URL pendant une courte période (disons 10 secondes). Ne vous fiez pas à ces 10 secondes, cela signifie que pour toutes les requêtes adressées à cette URL dans les 10 secondes, le nœud CDN renverra directement le contenu mis en cache et ne retournera pas du tout à la source. Ce “bouclier” de 10 secondes est suffisant pour que le module de sécurité du CDN puisse déterminer et bloquer les IP malveillantes. J'ai utilisé cette astuce sur 08Host pour résister avec succès à une attaque CC contre l'interface de recherche, le site source n'a même pas reçu de requête.
Enfin, n'oubliez pas le réchauffement et l'effacement du cache. Même la meilleure stratégie doit s'accompagner de mesures de soutien. La vitesse de l'interface de rafraîchissement de l'API de 08Host est la plus rapide que j'aie jamais utilisée, et après avoir appelé le nœud 95%, elle peut invalider le cache en 3 secondes, contrairement à d'autres fournisseurs qui doivent attendre une demi-heure.
Ceci étant dit, le résultat est le suivantTestez, testez et testez encore.. Après avoir fait correspondre les règles, assurez-vous de vérifier l'en-tête Cache-Control avec curl ou votre navigateur pour vous assurer que le cache a été atteint comme prévu. Observez le rapport sur le taux de réussite du cache sur la console CDN pendant un moment, s'il est inférieur à 90%, il doit y avoir de la place pour l'optimisation.
La stratégie de mise en cache n'est pas permanente, elle doit suivre les changements de l'entreprise. Mais tant que vous maîtrisez le principe de base “contenu statique en cache longue durée, contenu dynamique en contrôle fin, paramètres de clé de cache raisonnables”, vous ne risquez pas de vous tromper. N'oubliez pas que le CDN à haute défense n'est pas seulement un pare-feu, il devrait être la couche la plus importante de votre accélérateur d'architecture de performance. S'il est bien configuré, l'expérience de l'utilisateur monte en flèche ; s'il est mal configuré, l'argent est dépensé et critiqué. De nos jours, même les CDN doivent “prévenir les coéquipiers” - pour empêcher ceux qui ne comprennent pas la configuration chaotique de leur propre personnel ah.
