Qu’est-ce qu’un CDN (Content Delivery Network) ?

Les uti­li­sa­teurs ne peuvent pas savoir si les données d’un site pro­vien­nent di­rec­te­ment du serveur sortant ou bien d’un serveur miroir, car tout ce processus se déroule en arrière-plan. Ils peuvent en revanche constater de faibles temps de char­ge­ment.

Les deux com­po­sants les plus im­por­tants dans ce processus sont le système de ré­par­ti­tion (ou dis­tri­bu­tion) et le système d’ache­mi­ne­ment des demandes (Request-Routing System). Le système de ré­par­ti­tion transmet non seulement les contenus du serveur d’origine aux serveurs miroirs, mais il se charge également de leur actualité et de leur véracité. Deux pro­cé­dures sont pour cela possibles : soit le système de dis­tri­bu­tion envoie les données modifiées et nouvelles di­rec­te­ment vers tous les serveurs du Content Delivery Network, soit il envoie seulement un message informant que telles données se trouvent sur tel serveur miroir de manière à les rendre dis­po­nibles lors des demandes uti­li­sa­teurs. Pour que ces demandes d’uti­li­sa­teur par­vien­nent aux bons serveurs au bon moment, le Request-Routing System est activé. Ce dernier fait en sorte que les demandes soient re­di­ri­gées de manière optimale, et ceci en deux étapes.

Il s’agit dans un premier temps de trouver le serveur le plus adapté pour répondre à la demande uti­li­sa­teur. Pour répondre à cet objectif, le système d’ache­mi­ne­ment des demandes se base sur des in­di­ca­teurs spé­ci­fiques, calculés avec dif­fé­rentes méthodes de mesure. On peut dé­ter­mi­ner avec ces dif­fé­rents in­di­ca­teurs s’il s’agit de con­nexions du côté du client Web ou du serveur. Il est possible, grâce aux valeurs de mesure du côté du serveur, qui comptent la charge générale sur les pro­ces­seurs ou le nombre d’accès actifs sur le serveur, de dé­ter­mi­ner quel serveur miroir utiliser, soit celui ayant la plus faible charge. Au regard des pro­prié­tés de la connexion entre le client et le serveur, le Request-Routing-System détermine le serveur avec la meilleure connexion au client.  Parmi les facteurs clé, on compte entre autres le temps de latence, le taux de trans­mis­sion moyen, le taux de perte de paquets, mais aussi la proximité géo­gra­phique. Des in­di­ca­teurs côté client nous ren­seig­nent sur l’identité de l’uti­li­sa­teur ef­fec­tuant la demande. Le système les utilise par exemple s’il faut que les contenus soient délivrés en dif­fé­rentes qualités pour des clients standards et premium.

Par ailleurs, l’éva­lua­tion des dif­fé­rents in­di­ca­teurs dépend toujours des données demandées : la gé­né­ra­tion de contenus dy­na­miques s’effectue plutôt avec un serveur ayant de bons in­di­ca­teurs, tandis qu’une connexion stable entre client et serveur re­pré­sente le b.a.-ba de l’uti­li­sa­tion de médias en streaming.

Si le serveur cible est connu dans le CDN, l’étape suivante est la re­di­rec­tion de la demande via le Request-Routing-System. Il existe plusieurs procédés pour une telle re­di­rec­tion de demande, qui se dif­fé­ren­cient fon­da­men­ta­le­ment selon l’em­pla­ce­ment de la re­di­rec­tion, entre un serveur miroir, sur le client ou le réseau.

La re­di­rec­tion de la demande du client est une méthode simple à mettre en place : le client choisit le serveur miroir parmi une liste présentée. Elle présente toutefois l’in­con­vé­nient que le Content Delivery Network n’ait que peu d’influence sur l’at­tri­bu­tion des serveurs. Une re­di­rec­tion http 302 est également simple à mettre en ap­pli­ca­tion et est équipée de bonnes in­for­ma­tions sur le CDN. Le serveur de sortie répond dans ce cas par le code de statut http à la demande et informe le client du serveur miroir approprié, qui sera contacté au­to­ma­ti­que­ment pour d’autres demandes. Le principal in­con­vé­nient de ce procédé est la du­pli­ca­tion des con­nexions né­ces­saires.

La manière de re­di­rec­tion la plus fréquente est le Request-Routing basé sur le DNS (Domain Name System ou système de noms de domaine en français). La demande du client est transmise à un serveur DNS spécial au sein du Content Delivery Network, qui renvoie de son côté l’adresse IP d’un serveur miroir. Le plus grand dé­sa­gré­ment de ce procédé est que les con­sul­ta­tions répétées dans le DNS en ra­len­tis­sent l’accès.

Grâce à des serveurs dispersés partout dans le monde, vos clients peuvent bé­né­fi­cier de temps de char­ge­ment plus rapide et d’une plus petite ex­ploi­ta­tion de la capacité de la bande passante. En tant qu’ex­ploi­tant, vous avez aussi des avantages con­si­dé­rables en utilisant un réseau de diffusion de contenu. La charge de votre serveur Web est non seulement allégée par la re­di­rec­tion des demandes, mais la sécurité des données de la mémoire tampon est aussi augmentée. Ainsi, les attaques DDoS ne peuvent pas atteindre le serveur de sortie. Quelques prérequis sont cependant né­ces­saires pour cela. Vous devez tenir les données sensibles telles que les données d’uti­li­sa­teurs ou les mots de passe à l‘écart du CDN, car celles-ci pré­sen­tent un risque d’attaque plus important, in­dé­pen­dam­ment du fait que cela implique des conflits fréquents dans la pro­tec­tion des données. L’at­tri­bu­tion de contenus évacués d’un CDN à votre propre nom de domaine permet d’empêcher la pro­pa­ga­tion d’une po­ten­tielle cy­be­rat­taque sur un autre élément du site Web. L’énu­mé­ra­tion suivante résume les avantages d’un réseau de diffusion de contenu :

• Les éléments statiques comme les pages HTML, les images, les feuilles de style, les documents ou scripts côté client sont sau­ve­gar­dés dans la mémoire cache du serveur miroir et ne doivent plus être chargés depuis leur serveur Web par la suite. Cela permet de ménager le serveur, mais aussi de proposer des temps de char­ge­ment plus courts à vos uti­li­sa­teurs. En con­sé­quence, vous pro­fi­te­rez d’un taux de rebond réduit et d’un meilleur ré­fé­ren­ce­ment sur les moteurs de recherche ;

• La faible uti­li­sa­tion du serveur et des ap­pli­ca­tions im­pli­quées protège le serveur de surcharge, de dommages ou de dé­fail­lances éven­tuelles. Cela a des con­sé­quences positives sur le matériel dont on a besoin pour l‘hé­ber­ge­ment ;

• Vous pouvez décider vous-même quels éléments statiques clients vous pouvez charger à partir du serveur vers le Content Delivery Network. Si vous ne trans­fé­rez par exemple que les images de votre Blog, celles-ci peuvent être chargées pa­ral­lè­le­ment, ce qui ac­cé­lè­rera les temps de char­ge­ment ;

• Ies sites Web profitent de cet envoi de données via un CDN pour le streaming de musiques et de vidéos, car de grandes quantités de données doivent être déplacées en peu de temps. Cela vaut aussi pour les re­trans­mis­sions en live sur Interne ;

• Les hausses du nombre de visiteurs ou encore les pics de visites sont maîtrisés fa­ci­le­ment.  La recherche de serveurs miroirs aux charges plus légères par un Request-Routing-System s’avère très rentable, en par­ti­cu­lier si vous proposez des fichiers en té­lé­char­ge­ment ou si vous exploitez une boutique en ligne ;

• Vous ne rac­cour­cis­sez pas seulement les temps de char­ge­ment, mais vous diminuez également la charge sur la bande passante, avec laquelle sont liés les char­ge­ments de contenus ,

• La sécurité de votre serveur et donc de ses données et des ap­pli­ca­tions utilisées est augmentée avec un Content Delivery network, car les attaques sont reconnues à temps et aussitôt  dé­tour­nées.