Réseau CDN : performances

Comment un CDN améliore-t-il les temps de chargement ?

Pratiquement tous les internautes ont bénéficié des avantages qu'offre un réseau de diffusion de contenu (CDN). La plupart des entreprises technologiques, notamment des sociétés telles que Google, Apple et Microsoft, utilisent des réseaux CDN pour réduire la latence lors du chargement des contenus de pages web.

Dans un CDN, les serveurs sont généralement placés aux points d’échange entre différents réseaux. C'est principalement au niveau de ces points d’échange Internet (IXP) que les différents fournisseurs d’accès Internet se connectent les uns aux autres pour mutualiser l’accès aux ressources présentes sur leurs différents réseaux. En plus des IXP, un CDN comporte des serveurs dans des datacenters situés un peu partout dans le monde, là où le trafic est intense et à des emplacements stratégiques, afin que le trafic soit acheminé le plus rapidement possible.

Un des principaux avantages d’un CDN réside dans sa capacité à diffuser du contenu rapidement et efficacement. Les optimisations des performances qu’offre un CDN se répartissent en trois catégories :

1. Réduction de la distance – réduit la distance physique entre un client et les données demandées
2. Optimisations matérielles/logicielles – améliore les performances de l’infrastructure côté serveur, par exemple, avec des disques SSD et un système d’équilibrage de charge performant
3. Réduction des transferts de données – utilise des techniques permettant de réduire la taille des fichiers, afin d’accélérer les chargements de page initiaux

Pour comprendre les avantages que présente l’utilisation d’un CDN, examinons le déroulement d'un transfert de données client/serveur normal, sans déploiement de CDN.

Quelle est la différence de temps de chargement avec et sans CDN ?

Imaginons qu’une personne à New York ait besoin d’accéder à un site web hébergé sur un serveur à Singapour. La distance physique qui sépare ces lieux est importante, et correspond à environ 15 300 km.

Si un serveur hébergeant le contenu d'un site web (le serveur d’origine) est situé à Singapour, chaque requête pour chaque ressource d’une page web doit parcourir la distance de New York à Singapour, et inversement. À l'instar d’un vol international avec de nombreuses correspondances en cours de route, chaque requête doit transiter par une série de routeurs pendant son lointain voyage du point A au point B.

Si vous souhaitez observer un exemple réel du nombre de connexions (sauts) différentes que doit effectuer votre ordinateur pour atteindre un service web particulier depuis votre emplacement actuel, explorez l’utilitaire traceroute sur un ordinateur de bureau.

Puisque la requête envoyée depuis New York à Singapour doit transiter par chaque site de routeur le long du trajet, le temps (latence) augmente à la fois en raison de la distance totale et du temps que met chaque routeur à traiter la requête. Lorsque le serveur d’origine traite la requête et répond au client ayant émis la requête, il renvoie les informations, qui transitent par une séquence similaire de routeurs avant de revenir à New York. La mesure de cet aller-retour complet est appelée, en jargon des télécommunications, RTT (« round trip time », ou temps d’aller-retour). En laissant pour l’instant de côté les problématiques de bande passante disponible et d’éventuels encombrements du réseau, examinons un exemple de facteurs de latence.

À titre d’illustration, considérons les données suivantes :

• Il faut 250 ms pour qu’une requête soit acheminée de New York à Singapour.
• L’établissement d’une connexion TCP/IP ajoute trois instances de 250 ms de latence.
• La page web nécessite cinq ressources uniques comprenant des images, des fichiers JavaScript et la page web elle-même.

Évaluons le temps de chargement approximatif de cette page web :

• 750 ms : la connexion TCP/IP est établie entre le client à New York et le serveur d’origine à Singapour.
• 250 ms : la requête HTTP pour la page web est acheminée de New York à Singapour.
• 250 ms : l’auteur de la requête à New York reçoit une réponse du serveur d’origine à Singapour, avec un code d’état 200 et la page web avec toutes les ressources supplémentaires nécessaires.
• 250 ms : chacune des cinq ressources est demandée par le client situé à New York.
• 1500 ms : les cinq ressources sont diffusées de manière asynchrone au client depuis le serveur d’origine situé à Singapour.

Dans cet exemple simple, le temps de transit total nécessaire au chargement de cette page web est d’environ 3 000 ms.

Comme vous pouvez le constater, chaque requête et chaque réponse envoyées parcourent la totalité du trajet entre le client à New York et le serveur d’origine à Singapour. À mesure que les sites web deviennent plus vastes et nécessitent un plus grand nombre de ressources, la latence entre le point A et le point B continue d’augmenter.

Revoyons maintenant l’exemple du contenu hébergé à Singapour et servi à un client web à New York ; cette fois, cependant, le site web de Singapour utilise un CDN avec un serveur à Atlanta, qui contient une copie mise en cache du site web statique :

• Il faut 50 ms pour acheminer une requête de New York à Atlanta.
• L’établissement d’une connexion TCP/IP ajoute trois instances de 50 ms de latence
• La page web nécessite cinq ressources uniques comprenant des images, des fichiers JavaScript et la page web elle-même.

Évaluons le temps de chargement approximatif de cette page web avec le CDN :

• 150 ms : la connexion TCP/IP est établie entre le client à New York et le serveur de périphérie à Atlanta.
• 50 ms : la requête HTTP GET pour la page web est acheminée du client vers le serveur de périphérie.
• 50 ms : le client reçoit une réponse du cache du serveur de périphérie avec la page web, ainsi qu’une liste de toutes les ressources supplémentaires nécessaires.
• 50 ms : chacune des cinq ressources est demandée par le client.
• 800 ms : les cinq ressources sont diffusées de manière asynchrone au client depuis le serveur de périphérie.

Le temps de transit total nécessaire au chargement de cette page web est d’environ 1 100 ms.

Dans cet exemple, la réduction de la distance entre le client et le contenu génère une amélioration de la latence de 1 900 ms pour le contenu statique, ce qui représente une amélioration de près de 2 s du temps de chargement.

La réduction de la distance totale que doit parcourir tout le trafic nécessaire permet à chaque utilisateur accédant au site web de bénéficier d’une diminution du temps de chargement. Puisque les utilisateurs quittent très rapidement un site (rebond) lorsque les temps d’attente augmentent, cette amélioration offre une meilleure expérience utilisateur et augmente le temps de présence des utilisateurs sur la page.

Comment un CDN charge-t-il le contenu ? Qu’est-ce que la mise en cache ?

Comme nous l’avons précédemment indiqué, lorsqu’un client demande un fichier à un serveur d’origine, la requête doit normalement effectuer un aller-retour vers ce serveur, puis inversement. Un CDN améliore la latence en extrayant des fichiers de contenu statique du serveur d’origine sur le réseau CDN distribué selon un processus appelé mise en cache. Certains CDN possèdent des fonctionnalités avancées qui permettent également la mise en cache sélective de contenus dynamiques. Une fois les données mises en cache, le CDN sert le contenu au client depuis le datacenter le plus proche du réseau CDN.

Après une négociation TCP, la machine cliente transmet une requête HTTP au réseau du CDN. Si le contenu n’a pas encore été mis en cache, le CDN télécharge d’abord le contenu depuis le serveur d’origine en transmettant une requête supplémentaire entre le serveur d’origine et le serveur de périphérie du CDN.

Voici les quatre étapes d’une mise en cache type sur un CDN :

1. Lorsque l’utilisateur demande une page web, la requête de l’utilisateur est acheminée vers le serveur de périphérie le plus proche du CDN.
2. Le serveur de périphérie transmet alors au serveur d’origine une requête pour le contenu demandé par l’utilisateur.
3. Le serveur d’origine répond à la requête du serveur de périphérie.
4. Enfin, le serveur de périphérie répond au client.

La valeur liée à la proximité d’un CDN par rapport au client se fait sentir après que la requête initiale adressée au serveur d’origine a déjà été effectuée. Lorsque les données ont été mises en cache depuis le serveur d’origine sur le CDN, chaque requête ultérieure du client n’est acheminée que jusqu’au serveur de périphérie le plus proche. Par conséquent, si le serveur de périphérie le plus proche est moins éloigné que le serveur d’origine, la latence peut être réduite et le contenu servi beaucoup plus rapidement.

Il est important de garder à l’esprit que le temps nécessaire au téléchargement des ressources et au traitement des requêtes et des réponses n’est actuellement pas inclus ; pour l’instant, seul est calculé le temps d’acheminement nécessaire pour transférer les informations entre ces deux sites. Parmi les autres facteurs de latence importants que nous allons examiner figurent la réduction des données, la vitesse des disques durs et l’encombrement du réseau.

Comment un CDN réduit-il les tailles de fichiers pour augmenter les vitesses ?

Afin d’améliorer les temps de chargement de pages, les CDN réduisent les volumes globaux de transferts de données entre les serveurs de cache du CDN et le client. La latence et la bande passante requise diminuent de pair avec la quantité globale de données transférées. Il en résulte des chargements de page plus rapides et des coûts de bande passante moindres. Deux éléments essentiels contribuent à ces réductions :

Minimisation – la minimisation est le processus consistant à réduire la taille des blocs de code en supprimant tous les composants qui aident les humains à comprendre ce qu’il se passe. Alors qu’un ingénieur doit séparer les idées en noms de variables sensés, en espaces et en commentaires pour rendre les blocs de code lisibles et gérables, les ordinateurs peuvent exécuter le code en dépit de la suppression de ces caractères.

Voici le même bloc de code avant et après minimisation :

Avant minimisation : huit lignes de code

Après minimisation : réduit à une ligne de code unique

L’extrait de code ayant été réduit de huit lignes à une ligne unique, la taille globale du fichier a également diminué. Le transfert du fichier demande donc moins de temps, ce qui réduit la latence et contribue à accélérer le chargement du contenu.

Compression de fichiers – la compression des fichiers est essentielle pour réduire la latence et la consommation de bande passante requise lors du transfert de données via Internet. GZip est une méthode courante de compression, considérée comme une pratique exemplaire à utiliser lors du transfert de pages web. De nombreux fournisseurs de CDN ont activé GZip par défaut. Quelle est l’importance des économies réalisées grâce à la compression GZip ? En règle générale, la taille des fichiers compressés est inférieure d’environ 50 à 70 % à la taille initiale du fichier.

Quel matériel peut utiliser un CDN pour améliorer la rapidité ?

En ce qui concerne l’optimisation des équipements du CDN, l’utilisation de disques SSD à la place des disques durs traditionnels (HDD) présente un avantage considérable : les disques SSD peuvent ouvrir les fichiers jusqu’à 30 % plus rapidement que les disques durs traditionnels, et sont plus résistants et fiables.

Un disque dur traditionnel ressemble à un tourne-disque : il est constitué d’un disque métallique circulaire rotatif comportant un revêtement magnétique permettant le stockage des données. Une tête de lecture/écriture montée sur un bras accède aux informations du disque pendant sa rotation. Ce processus est mécanique, et son efficacité varie en fonction de la vitesse de rotation du disque. Avec l’avènement des disques SSD, les anciens modèles de disques durs sont moins fréquemment utilisés, bien qu’ils soient encore produits et largement présents dans de nombreux systèmes informatiques.

Un disque dur SSD est également une forme de stockage persistant, mais son fonctionnement est assez similaire à celui des clés USB ou des cartes mémoire que l’on trouve communément dans les appareils tels que les appareils photo numériques. Il ne comporte aucune pièce mobile. Si un disque dur traditionnel est en rotation et le système est secoué, le disque dur peut « sauter » et provoquer des erreurs de lecture/écriture, voire entraîner un temps d’arrêt. L’accès aux fichiers fragmentés est un autre avantage important des disques SSD. La fragmentation des fichiers est une situation dans laquelle différentes parties d’un fichier se trouvent à différents emplacements sur le disque, ce qui se traduit par un ralentissement de l’accès aux disques durs. Puisqu’un disque SSD peut accéder efficacement à des emplacements mémoire non contigus, la fragmentation n’altère pas ses performances.

Sur les premiers CDN les données étaient stockées sur des disques durs. Désormais, avec certains services de CDN, la totalité de la mise en cache côté périphérie peut être effectuée sur des disques SSD. L’inconvénient des disques SSD tient à leur prix. Un disque SSD peut être jusqu’à 5 fois plus coûteux qu’un disque dur traditionnel. Cela explique pourquoi certains services CDN évitent souvent d’utiliser des disques SSD et optent plutôt pour la technologie plus ancienne. La solution CDN de Cloudflare utilise, quant à elle, exclusivement des lecteurs SSD.