Connexion
Abonnez-vous

[Dossier] Internet, mode d’emploi : les CDN, quels sont leurs réseaux ? (partie 4)

Content De Naviguer ?

[Dossier] Internet, mode d’emploi : les CDN, quels sont leurs réseaux ? (partie 4)

Dans notre long dossier sur les coulisses d’Internet, nous avons expliqué les grandes routes empruntées pour les échanges de données entre les serveurs et les utilisateurs. Internet pourrait uniquement fonctionner sur ce principe (un client se connecte directement à un serveur), mais il existe une solution pour optimiser les routes et les ressources : le CDN.

Le 27 mars à 11h30

Avant d’attaquer les questions de peering et de points d’accès, faisons un pas de côté. Sur Internet, il existe des CDN (ou réseau de diffusion de contenu). Ils ne sont pas là pour créer du contenu (leur nom est d’ailleurs bien moins connu auprès du grand public), mais pour diffuser celui de tiers. Akamai, un CDN parmi beaucoup d’autres, se présente comme « un groupe de serveurs géographiquement distribués qui accélèrent la diffusion de contenu Web en le rapprochant de l'endroit où se trouvent les utilisateurs ».

Le CDN, comme la plupart des technologies utilisées sur Internet, n’est pas récent. Les premiers réseaux de diffusion de contenu sont apparues à la fin des années 1990.

Un CDN c’est un gros cache, sur plein de serveurs

Cloudflare, un autre CDN et concurrent d’Akamai, ajoute que « la popularité des services CDN ne cesse de grandir et, aujourd'hui, la majorité du trafic web est desservie par des CDN, y compris le trafic de sites majeurs tels que Facebook, Netflix et Amazon ». On peut aussi voir les CDN comme une sorte de cache, avec des fonctions supplémentaires selon les cas. Certains proposent par exemple des protections anti DDoS.

Il reste 76% de l'article à découvrir.

Déjà abonné ? Se connecter

Cadenas en colère - Contenu premium

Soutenez un journalisme indépendant,
libre de ton, sans pub et sans reproche.

Accédez en illimité aux articles

Profitez d'un média expert et unique

Intégrez la communauté et prenez part aux débats

Partagez des articles premium à vos contacts

Abonnez-vous

Commentaires (16)

votre avatar
Merci pour tout ça.

Questions ouvertes:
- Quand Google Netflix et surement d'autres installent leur machin (EDIT : chez les FAIs), qui paye ? (le courant, la bande passante, la place de rack).
- Est-ce que le FAI fait ça gratos parce qu'il économise assez de peering?
- Est-ce que c'est pas une forme de concurrence déloyale (accès privilégié, ...) envers des sites plus petits et une entorse à la neutralité du net ? (au sens de garantir un accès identique à toutes les ressources).
votre avatar
-Ca dépend des négociations à ce sujet.
-Même réponse. D'ailleurs pendant longtemps, Netflix n'avait pas de serveur chez Free (ce qui a provoqué pas mal de lenteurs Netflix chez les Freenautes) : Free voulait être payée une certaine somme pour ca, et Netflix refusait. Jusqu'à ce qu'un accord soit trouvé entre les 2, et règle ce différend.
-Non, il n'y a pas de refus d'accès ou de priorisation au sens technique du terme ici (et surtout pas plus que ce que feraient Cloudfare ou Akamai, qui sont neutres, par ex). Ca met juste en cache des ressources les plus demandées, ce qui permet une baisse du coût global pour les concernés.
votre avatar
Les conditions ne sont pas détaillées publiquement, mais les informations sur GGC sont là https://support.google.com/interconnect/answer/9058809
Google invite les FAI à les contacter et remplir un formulaire de contact. Une façon de dire que ce sont les FAI qui sont demandeurs de l'économie de bande passante (et de la vitesse pour leurs abonnés).
Il y a même la doc d'install des serveurs...
votre avatar
Question sur la phrase : "Quand la ressource (texte, image, vidéo…) est disponible sur un CDN, ce dernier la renvoie directement à l’utilisateur qui n’a ainsi pas besoin d’aller joindre le serveur. C’est plus rapide et plus économique en bande passante"

Si j'ai bien lu l'article (je ne suis du tout un spécialiste réseau, donc ce sont de vraies questions de béotien), on voit bien l'intérêt de la rapidité pour l'utilisateur "client" puisqu'on réduit la "distance" (j'utilise volontairement ce mot sachant qu'il est en partie impropre ici), en particulier pour le contenu statique, et pour le serveur, qui doit servir probablement un peu moins de requêtes puisque les CDN font tampon sur une partie du contenu.

Ce serait possible d'expliquer plus en détails en quoi cela permet d'économiser de la bande passante ?

D'ailleurs on connaît la répartition statique/dynamique chez un CDN, ce dernier n'ayant pas spécialement d'intérêt pour le dynamique si j'ai bien lu l'article là aussi ?
votre avatar
Au lieu d'aller chercher à chaque fois les ressources à l'autre bout de la planète, ca les garde en cache en local ou pas loin. C'est exactement comme quand on consomme des produits locaux au lieu de ceux venant d'Argentine : bien moins de transport à faire, et coût réduit.
votre avatar
Ça économise de la bande passante sur les liens de peering. Le contenu ne traverse l'atlantique (par ex.) qu'une seule fois, il est ensuite distribué localement (en local, ça ne change pas le traffic).
votre avatar
Quand tu es freenaute, si tu vas chercher des données chez Youtube, Netflix, FB ou whatever, ta requête va - de façon schématique - de chez toi sur le réseau de Free, puis passe peut-être par d'autres réseaux avant d'atteindre le serveur qui contient la ressource que tu veux.
Ce serveur envoie alors les données, qui passent par leur réseau, puis peut-être d'autres réseaux, avant de transiter sur le réseau de Free pour arriver sur ta machine.
Si la donnée se trouve sur le réseau de Free, tu économises de la bande passante vers l'extérieur. Cela reste sur le réseau "interne" de ton FAI. Sans compter que, avec d'autres systèmes de routage et commutation, quand plusieurs personnes demandent la même chose, au départ ça envoie une seule donnée, qui est dupliquée le plus tard possible. Deuxième économie de bande passante.
votre avatar
Comme Netflix, Google fournit tout le matériel : « Il vous suffit de fournir de l’espace rack, de l’alimentation, un clavier et un moniteur, ainsi qu’une connexion à votre réseau ».
N'est ce pas risqué d'avoir du matos américain contrôlé par une boîte américaine au coeur de son datacenter?
votre avatar
Bof.
votre avatar
Qu'il soit dans le datacenter ou ailleurs sur l'internet, le problème est à peu près le même.
votre avatar
Les CDN prennent la place des AS (Système autonome, voir la partie 3 de notre dossier) et annoncent donc les adresses IP à leur place, avec les routes correspondantes
Je comprends de cette phrase que quand je cherche un nom (google.com), je vais voir le DNS qui me retourne l'adresse IP américaine. Puis c'est le CDN qui "intercepte" ma requête http vers le serveur américain pour la rediriger vers un serveur en France. Ai-je bien compris ? Ce n'est pas le serveur DNS qui me renvoie l'adresse IP d'un serveur plus proche géographiquement ?
votre avatar
Il me semble que la formulation n'est pas parfaite. Pour moi, le CDN répond directement aux requêtes DNS à la place du site (google.com dans ton exemple) parce que le site a acheté le service au CDN. Après, c'est juste l'AS du CDN qui gere la partie routage.
votre avatar
Cela dépend fortement de l'offre CDN souscrite. En grande majorité, les services CDN sont anycastés sur Internet, plusieurs serveurs annoncent de partout les mêmes IPs sur le réseau Internet en BGP, et de ce fait les routeurs amènent les paquets au serveur le plus proche.
D'ailleurs on peut prendre un exemple de CDN anycast, https://1.1.1.1, lorsqu'on regardes sur https://ping.pe/1.1.1.1, on voit que la latence est inférieure à 2ms partout sur Terre. Alors que si l'on prend next.ink, https://ping.pe/next.ink on constate qu'il est localisé à Paris.
votre avatar
Non ce n'est pas ça, le site web va intégré ses images (vidéos...) avec un lien "akamai.net" plutôt qu'un lien local au serveur. Donc c'est toujours le CDN (akamai) qui est interrogé et répond après éventuellement être aller télécharger le média à la source si il ne l'avait pas encore mis en cache.
Un DNS menteur ne fonctionnerait pas : il est à la maille nom de domaine et inclus donc tout le contenu du serveur, alors que le CDN intervient à la maille du fichier.
Autre prob avec les DNS y'a des délais / caches de plusieurs jours : il faut plusieurs jours pour répercuter une nouvelle adresse IP d'un domaine, bien trop important pour un cache d'images / vidéos.

Concernant unicast : le dns répond toujours la même IP, c'est le routage qui peut orienter cette adresse unique a différents endroits du globe.
votre avatar
Question potentiellement débile -- le réseau c'est assez loin pour moi.

Y a-t-il (et si oui comment) une possibilité de gérer l'authentification client sur le CDN ?

Ça m'interroge à propos de l'articulation contenu statique / Netflix (dont j'imagine qu'il ne met pas les chunks vidéo en clair / sans authentification).

Si le contenu est statique / public, pas de soucis.

Contenu privé, à la rigueur, il est possible de chiffrer et de distribuer la clé aux clients légitimes par ailleurs, mais ça implique que la clé est partagée.

Mais pour du contenu sous DRM ? 🤯

Sauf si les serveurs Netflix chez le FAI vont au-delà et hébergent du code, pas juste de la data en cache ?
votre avatar
C'est vrai qu'une toute petite dimension modèle économique aurait été le bien venue.
Savoir qui paie (CDN et AS et autre) ça aide à savoir pourquoi et comment c'est organisé de cette façon !

Les FAI ont sait qui les payent :D

[Dossier] Internet, mode d’emploi : les CDN, quels sont leurs réseaux ? (partie 4)

  • Un CDN c’est un gros cache, sur plein de serveurs

  • Détour par l’Anycast

  • Des cas particuliers : l’exemple de Netflix et Google

  • Il est temps de préparer la suite avec les points d’échange

Fermer