Récemment, j'ai aidé un ami à résoudre le problème d'une panne de serveur, et j'ai découvert un phénomène très intéressant : manifestement, sur le CDN de haute défense, la station source est encore trois jours après le trafic. Après une demi-journée de vérification, j'ai découvert que leur configuration de retour à la source est simplement pour le serveur "creuser la fosse" - le trafic d'attaque est transporté par le CDN, mais retour à la politique de source mis en place des erreurs, mais laisser la station source est le trafic normal + pénétration de la mémoire cache a frappé une surprise.
De nos jours, même les CDN à haute défense doivent "prévenir les coéquipiers". Vous pensez que si vous achetez un service de marque, vous pouvez être assuré que la configuration par défaut de CDN5 pour le retour à la source de la fréquence est ridiculement élevée, que les règles de mise en cache de CDN07 renverront même des demandes dynamiques - ces détails ne sont pas réglés, l'équivalent d'une porte dérobée pour l'attaquant. J'ai testé une plateforme de commerce électronique, après avoir ajusté la stratégie de retour à la source, le coût de la bande passante a directement chuté de 40%, la charge du serveur source du pic de 80% à 30% en dessous.
La nature de la bande passante de retour est un "trou noir" en matière de coûtsLe CDN est une partie très importante du système, et c'est une partie très importante du système. Beaucoup de gens pensent que le CDN se limite à l'accélération et à la protection, mais ignorer le lien de retour est le véritable endroit où l'on brûle de l'argent. En particulier dans le cas d'un trafic inattendu, une fois que le taux de réussite du cache du nœud CDN diminue, la demande de retour sera comme une avalanche qui submergera le serveur. Ne regardez pas les vendeurs de CDN annoncer une "protection illimitée", la bande passante de retour à la source est réelle par la facturation au volume - la facture de 08Host, le retour à la source des coûts du trafic peut représenter le coût total de 60%, ce chiffre est assez effrayant, n'est-ce pas ?
Commençons par démonter une idée reçue typique :Activation aveugle de la "mise en cache du chemin completVoici une liste des règles de mise en cache les plus courantes utilisées par les webmasters. Certains webmasters, pour gagner du temps, appliquent directement les règles de mise en cache par défaut du CDN, ce qui a pour résultat que même le statut de connexion de l'utilisateur et l'interface API sont mis en cache. Les données de l'utilisateur sont mélangées et l'authentification n'est pas valide. L'année dernière, une plate-forme financière a été victime d'une fuite de données, la cause principale étant que le CDN contient le cache des demandes de jetons et les renvoie à la source de nombreuses fois, ce qui équivaut à une clé insérée dans la porte et qui peut être prise.
Mon conseil :Remplacement du cache global par une politique de cache conditionnellePar exemple, ajouter la logique de jugement suivante à la couche Nginx. Par exemple, ajoutez la logique de jugement suivante à la couche Nginx pour permettre l'accélération uniquement pour les ressources statiques et le contenu cachable, les requêtes dynamiques n'étant résolument pas prises en compte :
Et pour couronner le tout.Sélection du protocole de retour. Certaines équipes essaient de gagner du temps en laissant le CDN utiliser HTTP pour le retour à la source, mais le client du CDN est HTTPS - tout lien dans la chaîne intermédiaire est détourné et les données sont nues. J'ai testé la configuration par défaut de CDN07, et le protocole de retour hérite en fait du protocole du client, alors que CDN5 est obligé d'être configurable. Il est fortement recommandé d'activer "HTTPS full encryption", même si le certificat source est auto-signé, c'est toujours mieux que du texte en clair.
Optimisation de la bande passante centrée sur l'amélioration du taux de réussite du cacheLa première est que le taux de réussite du cache n'est que de 62%. Pour donner un exemple : un site vidéo initialement avec les paramètres par défaut du CDN5, le taux de réussite du cache n'est que de 62%, et le trafic quotidien vers la source est de près de 3TB. Par la suite, trois ajustements ont été effectués : le premier est basé sur la mise en cache hiérarchique du type de fichier (mise en cache du fichier vidéo pendant 30 jours, mise en cache du fragment de page pendant 2 heures), le deuxième est d'ouvrir la segmentation de la demande Range vers la source, et le troisième est de mettre en place la mise en cache de la page 404 pendant 5 minutes afin d'empêcher la pénétration du site. Après ajustement, le taux de réussite a grimpé à 91%, le trafic de retour à la source a été directement réduit à 800GB/jour.
Nous partageons ici un modèle de configuration testé sous pression et vérifié pour la plupart des sites web :
N'oubliez pas.Prétraitement Edge Computing. Aujourd'hui, la version avancée de 08Host prend déjà en charge l'exécution de JavaScript en périphérie, ce qui permet de placer la compression d'images et la minimisation HTML de ces opérations gourmandes en ressources processeur à la périphérie du traitement. Avant de s'occuper d'un site de forum, la conversion WebP des images a été transférée vers le nœud CDN, la bande passante de la station source a immédiatement chuté de 70%, même la charge du CPU a chuté d'un demi-ordre de grandeur.
En parlant de stratégies anti-attaque.Ne croyez pas que la "protection intelligente" peut tout régler.La première chose à faire est d'obtenir les informations dont vous avez besoin pour retourner à la source. De nombreuses attaques CC simuleront le comportement normal de l'utilisateur pour augmenter progressivement la fréquence des demandes, et à ce moment-là, si la stratégie de retour est trop lâche, le trafic d'attaque contournera le stockage lent et atteindra directement la station source. Il est recommandé de mettre en place un mécanisme de contestation hiérarchique dans la couche CDN : les demandes à faible fréquence sont libérées directement, les contestations JavaScript à fréquence moyenne sont déclenchées et les IP à haute fréquence sont obligées de retarder la réponse. Cet ensemble de règles a été testé sur la requête de camouflage 98% bloquée par CDN07.
Un autre conseil est deTirer parti des caractéristiques distinctives des fournisseurs de CDNPar exemple, CDN5 est très efficace pour optimiser le streaming vidéo. Par exemple, CDN5 est extrêmement bien optimisé pour le streaming vidéo, prenant en charge le pré-tirage des tranches et le taux de code adaptatif à la source ; 08Host est bon pour la planification globale, peut ajuster dynamiquement le nœud source en fonction de la charge de la station source. L'utilisation mixte de plusieurs fournisseurs de services, bien que la configuration soit complexe, permet vraiment d'éviter un point unique de goulot d'étranglement - j'utilise CDN5 pour gérer les ressources statiques dans le projet financier, 08Host pour transporter le trafic API, cette optimisation permet à elle seule d'économiser quelques milliers de dollars par mois en coûts de bande passante.
Un dernier rappel des pièges à éviter :Suivi des métriques pour voir à travers trois couches. Il ne suffit pas de regarder le taux de réussite de la console du CDN, il faut aussi combiner l'analyse du journal de la station source avec les caractéristiques de la demande de la source. Il y a eu un cas où le taux de réussite du CDN de 85% était normal, mais où la charge de la station source était élevée. Il s'est avéré par la suite qu'un crawler demandait de manière insensée des pages de marchandises froides, et que les règles de mise en cache configuraient des erreurs qui renvoyaient chaque demande à la source. L'ajout d'une règle "404 page cache 5 minutes" a instantanément résolu le problème.
En fin de compte, un CDN de haute défense n'est pas un coffre-fort prêt à l'emploi. Derrière la stratégie de retour se cachent la dynamique du cache, l'optimisation du protocole et la psychologie des attaques (oui, les attaquants étudient également vos habitudes de configuration). Il est recommandé de procéder à un audit trimestriel du retour à la source : capturez les journaux de la station source pour analyser les demandes de retour à la source TOP, utilisez des outils de test de pression pour simuler un trafic en rafale et mettez à jour les règles de cache pour les adapter aux changements commerciaux. Ces choses ne se font pas en place, acheter un CDN plus cher est aussi un confort psychologique.
Consultez maintenant votre console CDN - utilise-t-elle toujours la configuration par défaut ? Ajustez rapidement le délai de retour à la source de 30 à 5 secondes, supprimez le paramètre Query de la clé de cache et ajoutez un indicateur "non mis en cache" à la page de connexion. Toutes ces petites choses peuvent être les éléments clés qui permettront à votre serveur de résister à la prochaine tempête de trafic.
