Un truc qui me fascine : le recours massif à un CDN… Sans trop savoir pourquoi ni vérifier son paramétrage ni évaluer le gain économique réel ? J'ai l'impression qu'il s'agit d'une frénésie, de mode, de suivisme, pas de décisions rationnelles. Je vais tenter de développer ce ressenti.
Même les dino s'y sont mis. Gandi (l'espace client). Un hébergeur qui ne sait pas héberger ses propres JavaScript et CSS ? Le noyau Linux (docs.kernel.org, bugzilla.kernel.org). L'IETF (site web vitrine et certains outils comme le suivi des documents ‒ datatracker ‒). La discussion des normes techniques d'Internet chez Cloudflare… Le RIPE (site web vitrine). Ces personnes sont capables de monter des architectures techniques aussi chiadées qu'Atlas, que RIPEstat / RIS, ou que des référentiels pour gérer les ressources Internet rares (adresses IP, numéros d'AS, racine RPKI), mais plus d'héberger un simple site web ? Qui va croire que ces sites web reçoivent une plus forte affluence qu'avant alors qu'ils sont très techniques et mêmes inconnus de nombre d'informaticiens ?
J'ai déjà râlé sur Debian et OpenStreetMap.
Il y a ceux qui recours à un CDN alors que leurs concurrents encaissent quasi deux fois plus de visiteurs qu'eux sans CDN. Exemple : Les Jours (12 000 abonnés en 2021) a recours à un CDN alors qu'Arrêt sur images (22 000 en 2021) n'en utilise pas. On peut mettre ça sur le compte aussi bien d'un site web mal conçu (gourmand en ressources) que d'une fréquentation tout au long d'une journée différente que d'un arbitrage délibéré ("on préfère dépenser la thune sur autre chose ‒ salaires, investissements, etc. ‒, ce CDN réduit notre facture d'hébergement conventionnel").
Il y a ceux qui ont la puissance de calcul pour génerer les pages web dynamiques de leur site web, mais pas pour diffuser quelques images, documents PDF, etc. alors que les ressources statiques se mettent très facilement en cache, aussi bien côté serveur (Varnish, HAProxy, etc.) que client (entêtes HTTP Cache-Control et Expires, désactiver ETAG, etc.). Exemple : Next Inpact.
Il y a les incohérents qui ne recourent pas à un CDN sur toutes leurs pages alors qu'on peut pourtant prédire qu’elles reçoivent la même quantité de trafic et que leur tenue de la charge est tout aussi nécessaire pour le fonctionnement global du service. Exemple : le fisc français. Le portail d’authentification de l'espace web pour les particuliers et le tableau de bord après authentification, sans lesquels l’accès au service (et donc les démarches administratives) est impossible, ne sont pas derrière un CDN…
Dans leurs réponses, les CDN incluent des entêtes HTTP additionnels (curl -D - -so <URL> ;) ). On peut y lire le nom du serveur qui a traité la requête web, qui, très souvent, indique sa localisation géographique. On peut aussi y lire si le CDN a servi une copie du contenu qu'il détenait ou s'il le récupére, en temps réel, à chaque demande, auprès de l'hébergeur final, auquel cas il a servit à rien (le serveur final a mouliné) et il a même fait perdre du temps (trajet client -> CDN -> hébergeur final + retour au lieu de client -> hébergeur + retour).
C'est ainsi que l'on constate que toutes les requêtes pour les pages web (le texte) de Mediapart, de L'informé ou de sites web officiels français gérés par la DILA (Légifrance, Journal-Officiel, Service Public, Vie-Publique, etc.) parviennent à leur hébergeur final (cf. entête HTTP « x-cache: MISS »). Cloudflare permet de configurer la mise en cache des pages dynamiques, mais Numerama ou Les Jours n'ont pas effectué cette configuration, donc toutes les requêtes pour leurs pages web doivent être traitées par leur hébergeur (cf. entête HTTP « cf-cache-status: DYNAMIC »). Intérêt du CDN ? À leur décharge, la mise en cache de pages dynamiques contenant des données personnelles (Mediapart : identifiant dans le menu horizontal supérieur) n'est pas triviale (ben oui, il ne faut pas servir une page contenant les données persos d'une autre personne… Et mettre en cache X versions d'une page pour X abonnés, ça revient au même que de se passer de cache).
Il y a les champions qui cumulent un hébergeur Google Cloud et un CDN Fastly. Comme si Google ne disposait pas de ressources suffisantes ni d'une excellente connectivité de son réseau à travers le monde ni d'une capacité à encaisser les attaques par déni de service… Exemple : L'informé. Faisons l'hypothèse que Fastly coûte moins cher que de la ressource supplémentaire Google Cloud et que l'utilisation de Fastly permet la montée en charge d'un nouveau journal, mais je prends les paris que le CDN demeurera après la montée en charge (qui est un prétexte parmi d'autres) parce que ça marche, parce qu'on a oublié, parce qu'on s'en fiche le public nous aime comme ça, parce qu'on a toujours fait comme ça, blablabla.
Alors, oui, un CDN ne sert pas qu'à mettre en cache. Il peut aussi filtrer des attaques informatiques (par déni de service, applicatives, etc.) plus efficacement que d'autres prestataires (typiquement les gros hébergeurs) car il a accès à la requête web, donc à plus d'infos pour arbitrer, et peut-être pour moins cher qu'une prestation spécialisée vu les parts de marché des CDN. On ne peut donc pas totalement préjuger de la volonté de ceux qui y ont recours. Même si on me fera difficilement croire que le petit journal ou l'IETF ou le RIPE croulent sous des attaques permanentes.
Ces choix concentrent le trafic web dans les mains de quelques acteurs (dépendance, fiabilité, concurrence ?) et appauvrissent les compétences (qui sait construire, configurer finement, et maintenir une plate-forme d'hébergement web digne de ce nom ? Qui sait construire et maintenir un CDN maison ? Qui peut concurrencer, techniquement, les gros CDN ricains ?). Évidemment, ces quelques acteurs consignent qui (adresse IP) a consulté telle page web précise (c'est l'URL demandée ou des entêtes HTTP supplémentaires) à telle date.