CDN ?

Ce billet est destiné à vous faire partager une étude de cas d’un site internet rencontrant des problématiques assez spécifiques, et liées à l’usage d’un « CDN ».
Certains sont très friands des CDN, car la promesse est intéressante : réduire le temps de chargement autour du globe, optimiser le site internet hébergé.
Le principe d’un CDN est alors de servir les visiteurs au plus proche de leur localisation physique : Etats Unis, Japon (…)

Dans la réalité, l’intérêt peut parfois être limité, et surtout l’usage contre-productif.
Un CDN aura sans nul doute un intérêt pour un site international, statique, avec une cible commerciale répartie à plusieurs points -très éloignés- du globe.
En effet, il va très souvent agir comme « cache » des données statiques et éventuellement délivrer plus rapidement les médias comme les images pour un visiteur basé à des milliers de kms.

Mais! il est toujours bon de mesurer les inconvéniants.
D’une part, le contenu dynamique, lié à MySQL ou PHP sera localement délivré. La latence sera donc identique car elle dépend du serveur physique où est stocké le site internet. D’autre part, des effets néfastes sur la fiabilité peuvent exister.

Il ne faut pas oublier que rajouter un CDN, c’est rajouter un intermédiaire, soit un point de défaillance possible du visiteur au serveur !
Si le serveur CDN est défaillant, votre site hébergé ne fonctionnera plus. Malheureusement sans que l’hébergeur « final » ne puisse agir.

Quand vous utilisez un CDN, les requêtes vues par les serveurs d’hébergement vont êtres avec la ou les adresses IP du service que vous utilisez comme intermédiaire.
Ceci n’est au premier abord pas dérangeant : les services CDN les plus connus bénéficient automatiquement d’une conversion de l’adresse IP vue vers celle du visiteur pour la génération de vos stats, les traitements sur votre site web, etc.
Néanmoins, et en frontal, l’IP du CDN reste bien celle traitée.

Aussi, et si votre site est relativement visité, subit des attaques, ou des crawls massifs/anormaux (visites de moteurs de recherches) vous pouvez perturber négativement les flux.

Pourquoi un CDN peut-il perturber un site web ?

Un exemple reste le plus parlant :

de****i.com-ssl_log:965:141.101.8*.*** – – [19/Jun/2018:09:25:52 +0200] « GET (….) 200
de****i.com-ssl_log:970:141.101.8*.*** – – [19/Jun/2018:09:25:52 +0200] « GET (….) 200
de****i.com-ssl_log:2068:108.162.23*.*** – – [19/Jun/2018:10:54:03 +0200] « GET (….) 200 « – » « Googlebot-Image/1.0 »
de****i.com-ssl_log:2069:108.162.24*.*** – – [19/Jun/2018:11:50:45 +0200] « GET (….) 200 « – » « Mozilla/5.0 (compatible; bingbot/2.0; +http://www.bing.com/bingbot.htm) »
de****i.com-ssl_log:2070:108.162.24*.*** – – [19/Jun/2018:11:50:45 +0200] « GET (….) 200 « – » « Mozilla/5.0 (compatible; bingbot/2.0; +http://www.bing.com/bingbot.htm) »
de****i.com-ssl_log:2071:108.162.24*.*** – – [19/Jun/2018:11:50:45 +0200] « GET (….) 200 « – » « Mozilla/5.0 (compatible; bingbot/2.0; +http://www.bing.com/bingbot.htm) »
(….)
de****i.com-ssl_log:2082:108.162.24*.*** – – [19/Jun/2018:11:50:45 +0200] « GET /admin690 503 (….)
(….)
de****i.com-ssl_log:2092:108.162.24*.*** – – [19/Jun/2018:11:50:45 +0200] « GET (….) 503 « – » « Mozilla/5.0 (compatible; bingbot/2.0; +http://www.bing.com/bingbot.htm) »
de****i.com-ssl_log:2093:108.162.24*.*** – – [19/Jun/2018:11:50:45 +0200] « GET (….) 503 « – » « Mozilla/5.0 (compatible; bingbot/2.0; +http://www.bing.com/bingbot.htm) »
de****i.com-ssl_log:2094:108.162.24*.*** – – [19/Jun/2018:11:50:45 +0200] « GET (….) 503 « – » « Mozilla/5.0 (compatible; bingbot/2.0; +http://www.bing.com/bingbot.htm) »
de****i.com-ssl_log:2095:108.162.24*.*** – – [19/Jun/2018:11:50:45 +0200] « GET (….) 503 « – » « Mozilla/5.0 (compatible; bingbot/2.0; +http://www.bing.com/bingbot.htm) »
de****i.com-ssl_log:2096:108.162.24*.*** – – [19/Jun/2018:11:50:45 +0200] « GET (….) 503 « – » « Mozilla/5.0 (compatible; bingbot/2.0; +http://www.bing.com/bingbot.htm) »
de****i.com-ssl_log:2097:108.162.24*.*** – – [19/Jun/2018:11:50:45 +0200] « GET / HTTP/1.0 » 503 « https://www.de(….) » « Mozilla/5.0+(compatible; UptimeRobot/2.0; http://www.uptimerobot.com/) »
de****i.com-ssl_log:2098:108.162.24*.*** – – [19/Jun/2018:11:50:45 +0200] « GET (….) 503 « – » « Mozilla/5.0 (compatible; bingbot/2.0; +http://www.bing.com/bingbot.htm) »
de****i.com-ssl_log:2099:108.162.24*.*** – – [19/Jun/2018:11:50:45 +0200] « GET (….) 503 « – » « Mozilla/5.0 (compatible; bingbot/2.0; +http://www.bing.com/bingbot.htm) »

Les codes 200 sont des requêtes acceptées, les 503 refusées.

Attention : Nous parlons ici d’une couche technique préalable au serveur web de traitement ; avant les modules de conversion IP CDN <> IP Visiteur !

Comment comprendre ces logs ?

C’est un site ecommerce, relativement simple, et assez peu visité.
Il se produit alors l’évènement suivant : les requêtes sont assez éclaircies dans les logs et passent par des IP du CDN différentes en temps normal.
Puis et à 11h50 : des centaines de requêtes, d’une même IP du CDN, arrivent au serveur. Ceci, à la même seconde !

Alors et logiquement, le serveur rajoute un rate-limit, et détecte cela comme une tentative de DoS basique.
On voit alors, dans le flux des requêtes : un accès au backoffice d’un célèbre CMS, ainsi qu’un agent d’uptime bloqués en erreur 503.

Cette erreur est alors légitime, normale et correspond à l’activation de la protection logique du serveur.
Il faut alors rester concret : le fait que toutes les requêtes proviennent d’une même IP CDN est relativement rare… mais cela peut arriver.
Le comportement de Bing est clairement anormal cette fois-ci, car et théoriquement les requêtes sont étallées sur la durée.

Néanmoins, dans le cas présent : des requêtes légitimes, en dehors de Bing, ont été bloqué légitimement du fait du CDN.
Résultat : Incompréhension, insatisfaction du client qui aura réceptionné une alerte de monitoring et une erreur dans son accès back office !

Un CDN est il nécessaire pour un site web ?

Est-ce préférable de garder un site sans intermédiaire, et donc sans CDN ?

Chacun trouvera « midi à sa porte » en fonction de ses propres besoins. Il faut cependant garder à l’esprit qu’un CDN peut être source d’incident.
Pour une application critique, nous déconseillons l’usage de prestataires extérieurs à l’hébergement.
Mais et si votre site peut se permettre de dépendre d’un tiers, et donc accepte l’ajout d’un point de défaillance, un CDN peut avoir un intérêt.

La réalité à ce jour est qu’une majorité ecrasante de sites n’a pas besoin d’avoir un CDN pour fonctionner de manière optimale !

Si vous souhaitez optimiser la vitesse de votre site internet, nous vous recommandons avant tout :
– De l’optimiser de base. De veiller à la bonne structure du site, à la compression des images (etc..)
– D’éventuellement, si vous êtes sur un CMS, d’exploiter les outils possibles : plugin de mise en cache, module Memcached, (etc…)

ou encore : Vous trouverez sur votre cPanel une fonction XtremCache permettant l’usage d’un cache agressif en amont de votre site internet.
Ce cache est géré à 100% par o2switch, et donc, permet d’intervenir et de contrôler sur les points de fonctionnement !