Ce dont vous avez besoin (et ce qu'un CDN fait ici)
Vous avez un jeu — PC ou mobile — que les joueurs installent et maintiennent à jour : un client souvent lourd de plusieurs gigaoctets, des correctifs réguliers, et du contenu téléchargeable ou des bundles d'assets. Et vous avez un compte cdn.com.tr. C'est toute la liste. Vous n'avez pas à monter une flotte de serveurs de téléchargement ni à construire vous-même un réseau mondial.
Voici le périmètre exact d'entrée de jeu, car cela compte. Un CDN distribue tout ce que vos joueurs téléchargent et tout ce que votre jeu sert en HTTP : le client, les correctifs, le DLC, les bundles d'assets, ainsi que les réponses de votre API de jeu et de compte. Ce n'est pas un remplacement pour de vrais serveurs de jeu multijoueur en temps réel — la simulation faisant autorité, le matchmaking et le netcode UDP forment une couche séparée. Ce qui suit concerne le volet diffusion, qui pour la plupart des jeux est la partie la plus volumineuse, la plus en pics et la plus attaquée de l'opération.
Comment ça marche : de l'origine à la périphérie jusqu'au joueur
Un CDN conserve des copies en cache de vos fichiers sur des emplacements en périphérie répartis sur le réseau. Quand un joueur télécharge votre client ou un correctif, il est servi depuis la périphérie la plus proche plutôt que par un seul serveur qui pourrait être loin ou déjà surchargé. Votre origine — ou le stockage CDN qui héberge la build — n'est sollicitée que lorsqu'une périphérie n'a pas encore le fichier : la première requête réchauffe le cache, et toutes les suivantes sont servies localement.
C'est exactement le comportement recherché le jour du lancement ou lors de la sortie d'un gros correctif. L'afflux de téléchargements qui ferait fondre un serveur unique est réparti sur le réseau et répondu près de chaque joueur, tandis que votre origine reste calme derrière tout ça. Vous obtenez des téléchargements plus rapides pour les joueurs éloignés et une facture qui reflète un trafic de périphérie efficace en cache plutôt qu'une origine servant chaque octet à tout le monde.
Uploadez votre build vers le stockage CDN
Placez votre client et vos fichiers de correctifs directement sur le CDN afin de n'avoir aucun serveur de téléchargement à faire tourner. Depuis le panneau, utilisez la zone Fichiers pour uploader et organiser vos builds comme un gestionnaire de fichiers. Depuis le terminal, cdnctl uploade comme scp — et, c'est essentiel, vous placez chaque build sous une version dans le chemin afin qu'elle soit immuable et puisse être mise en cache de façon durable. Pour des pipelines d'équipe ou de nombreuses machines de build qui veulent des outils S3 et des clés d'accès, passez plutôt au stockage d'objets compatible S3 (cdnctl object-storage buckets create ...).
cdnctl login --email you@studio.com --password ...
cdnctl accounts use <account_uuid>
# la build entière, sous un chemin versionné (immuable)
cdnctl cp -r ./build/1.4.2 builds/1.4.2/
# un seul fichier de correctif incrémental
cdnctl cp ./patches/1.4.1-to-1.4.2.pak patches/1.4.1-to-1.4.2.pakCache et versioning qui ne servent jamais un correctif obsolète
L'astuce d'une distribution de jeu sûre, ce sont des URLs immuables et versionnées. Comme builds/1.4.2/client.pak ne peut jamais changer une fois publié, vous pouvez le mettre en cache en périphérie pratiquement pour toujours — les joueurs récupèrent chaque fichier exactement une fois. Quand vous sortez la 1.4.3, elle vit sur un tout nouveau chemin, donc il n'y a aucune copie obsolète à combattre ni de purge globale à attendre.
La seule chose qui change, c'est le petit manifeste indiquant quelle version est actuelle. Gardez-le sur une URL stable avec un cache court (ou purgez-le à la publication), et gardez chaque fichier de build immuable. Cette combinaison fait qu'un correctif entre en ligne dès que vous basculez le manifeste, tandis que vos gigaoctets de données de build restent en cache en permanence.
Cache-Control pour les builds versionnées vs le manifeste
# les fichiers de build versionnés ne changent jamais -> cachez-les durement
Cache-Control: public, max-age=31536000, immutable
# le manifeste qui pointe vers la version actuelle -> gardez-le frais
Cache-Control: public, max-age=60Connectez-le à votre launcher ou patcher
Votre auto-updater n'a pas non plus besoin de serveurs personnalisés. Hébergez un petit manifeste JSON sur le CDN listant la version actuelle et chaque fichier avec son chemin, sa taille et son hash. Au démarrage, le launcher récupère le manifeste depuis la périphérie la plus proche, compare les hashs avec ce que le joueur possède déjà, et ne télécharge que les fichiers modifiés — chacun depuis la périphérie, chacun reprenable via HTTP Range si la connexion coupe en cours de téléchargement.
C'est tout l'updater : un manifeste plus des fichiers versionnés, le tout servi depuis le CDN. Aucun backend de téléchargement à faire tourner, aucun bug de téléchargement partiel à traquer, et le même design fonctionne pour un launcher PC ou un jeu mobile récupérant des bundles d'assets et une config distante au premier lancement.
manifeste de version servi depuis le CDN
{
"version": "1.4.2",
"base_url": "https://cdn.yourgame.com/builds/1.4.2/",
"files": [
{ "path": "client.pak", "size": 4213374208, "sha256": "..." },
{ "path": "audio.pak", "size": 812934144, "sha256": "..." }
]
}Gérez les pics de lancement et le DDoS
Les jeux comptent parmi les choses les plus en pics et les plus attaquées d'internet : un lancement ou une soldes envoie tous les joueurs télécharger en même temps, et les jeux en ligne sont une cible DDoS de choix. Servir les téléchargements depuis la périphérie absorbe déjà le pic légitime, car le réseau y répond près des joueurs plutôt que via votre origine.
En plus de cela, placez le WAF CDN et la protection DDoS devant vos points de téléchargement ainsi que devant votre API de jeu et de compte, et ajoutez du rate limiting pour qu'aucun client seul ne puisse marteler une route de connexion ou de vérification de correctif. Votre véritable origine reste cachée derrière la périphérie, si bien que l'afflux de lancement comme une attaque atterrissent sur le réseau conçu pour les absorber, pas sur votre serveur. (Pour être clair sur le périmètre : ceci protège votre diffusion HTTP et votre API — atténuer les attaques contre des serveurs de jeu UDP en temps réel est une couche séparée et spécialisée.)
Ce que les studios livrent de cette façon
Livrez des clients de plusieurs Go et des correctifs fréquents depuis la périphérie avec reprise des téléchargements, plutôt qu'un serveur de téléchargement qui plie dès qu'un correctif sort.
Servez du contenu téléchargeable, des bundles d'assets et une config distante aux joueurs mobiles depuis une périphérie proche, pour un premier lancement et des mises à jour rapides partout dans le monde.
Adossez votre auto-updater à un manifeste hébergé sur le CDN et des fichiers versionnés — aucune infrastructure de téléchargement personnalisée, protégée par WAF et protection DDoS.
FAQ CDN pour les jeux
Le CDN héberge-t-il mon serveur de jeu en temps réel ?
Non, et c'est la frontière honnête. Un CDN distribue le téléchargement et le contenu de votre jeu : le client, les correctifs, le DLC, les bundles d'assets, et les réponses de votre API HTTP de jeu et de compte. Le netcode multijoueur en temps réel — serveurs de jeu faisant autorité, matchmaking et trafic UDP — est une couche séparée qu'un CDN ne remplace pas. Utilisez le CDN pour tout ce que les joueurs téléchargent et pour protéger et mettre en cache votre API.
Peut-il servir des fichiers client de plusieurs gigaoctets ?
Oui. Uploadez vos gros fichiers de build vers le stockage de fichiers CDN ou vers du stockage d'objets compatible S3 et servez-les depuis la périphérie. Les téléchargements supportent HTTP Range, donc les clients peuvent streamer et reprendre de très gros fichiers plutôt que de les redémarrer.
Comment les joueurs reçoivent-ils un correctif dès que je le publie ?
Versionnez chaque build dans son chemin (builds/1.4.3/...) afin qu'un nouveau correctif soit une toute nouvelle URL jamais mise en cache, puis mettez à jour le petit manifeste qui pointe vers la version actuelle. Il n'y a aucune copie obsolète à purger ni de vidage de cache global à attendre.
Que se passe-t-il si un téléchargement s'interrompt à mi-chemin ?
Les fichiers servis en périphérie supportent les requêtes HTTP Range, donc un launcher ou un navigateur reprend là où il s'est arrêté plutôt que de recommencer un téléchargement de plusieurs gigaoctets depuis le début.
En quoi cela aide-t-il le jour du lancement ou des soldes ?
L'afflux de téléchargements est répondu depuis des caches de périphérie répartis sur le réseau plutôt que par une seule origine, et le WAF CDN, la protection DDoS et le rate limiting protègent votre origine et votre API à la fois du pic légitime et des attaques.