Как распространять игровые клиенты и патчи через CDN

Что вам нужно (и что здесь делает CDN)

У вас есть игра — на ПК или мобильная — которую игроки устанавливают и держат в актуальном состоянии: клиент, часто весом в несколько гигабайт, регулярные патчи и скачиваемый контент или пакеты ресурсов. И у вас есть аккаунт cdn.com.tr. Это весь список. Вам не нужно поднимать парк серверов раздачи или строить глобальную сеть самостоятельно.

Сразу обозначим честные границы, потому что это важно. CDN распространяет всё, что скачивают ваши игроки, и всё, что ваша игра отдаёт по HTTP: клиент, патчи, DLC, пакеты ресурсов, а также ответы игрового и аккаунтного API. Это не замена настоящим серверам мультиплеера в реальном времени — авторитетная симуляция, matchmaking и UDP-netcode находятся на отдельном уровне. Дальше речь пойдёт именно о доставке, которая для большинства игр является самой крупной, всплесковой и атакуемой частью операции.

Как это работает: от источника к edge и игроку

CDN хранит кэшированные копии ваших файлов в точках присутствия по всей сети. Когда игрок скачивает ваш клиент или патч, его обслуживает ближайший edge, а не один сервер, который может быть далеко или уже перегружен. К вашему источнику — или к CDN-хранилищу, где лежит сборка — обращаются только тогда, когда edge ещё не имеет файла: первый запрос прогревает кэш, а все последующие обслуживаются локально.

Это именно то поведение, которое нужно в день релиза или при выходе крупного патча. Поток скачиваний, который расплавил бы один сервер раздачи, распределяется по сети и обрабатывается близко к каждому игроку, пока ваш источник остаётся спокоен позади. Вы получаете более быстрые скачивания для удалённых игроков и счёт, который отражает эффективный кэшированный трафик edge, а не источник, отдающий каждый байт каждому.

Загрузите сборку в CDN-хранилище

Положите файлы клиента и патчей прямо на CDN, чтобы вам не пришлось держать сервер раздачи. В панели используйте раздел «Файлы», чтобы загружать и организовывать сборки как в файловом менеджере. В терминале cdnctl загружает файлы как scp — и, что важно, каждую сборку нужно класть под версией в пути, чтобы она была неизменяемой и кэшировалась намертво. Для командных пайплайнов или множества сборочных машин, которым нужны S3-инструменты и ключи доступа, переходите на S3-совместимое объектное хранилище (cdnctl object-storage buckets create ...).

cdnctl login --email you@studio.com --password ...
cdnctl accounts use <account_uuid>

# the whole build, under a versioned (immutable) path
cdnctl cp -r ./build/1.4.2 builds/1.4.2/

# a single incremental patch file
cdnctl cp ./patches/1.4.1-to-1.4.2.pak patches/1.4.1-to-1.4.2.pak

Кэш и версионирование, которые никогда не отдадут устаревший патч

Секрет безопасного распространения игр — неизменяемые версионированные URL. Поскольку builds/1.4.2/client.pak никогда не изменится после публикации, вы можете кэшировать его на edge практически вечно — игроки скачивают каждый файл ровно один раз. Когда вы выпускаете 1.4.3, он живёт по совершенно новому пути, так что нет ни устаревшей копии, с которой нужно бороться, ни глобального пурджа, которого нужно ждать.

Единственное, что действительно меняется, — это небольшой манифест, который указывает, какая версия текущая. Держите его по стабильному URL с коротким кэшем (или пуржите при публикации) и делайте каждый файл сборки неизменяемым. Именно эта комбинация позволяет патчу выйти в тот момент, когда вы переключаете манифест, пока гигабайты данных сборки остаются постоянно закэшированными.

Cache-Control для версионированных сборок и манифеста

# versioned build files never change -> cache them hard
Cache-Control: public, max-age=31536000, immutable

# the manifest that points at the current version -> keep it fresh
Cache-Control: public, max-age=60

Подключите это к вашему лаунчеру или патчеру

Вашему автообновлятору тоже не нужны отдельные серверы. Разместите на CDN небольшой JSON-манифест, который перечисляет текущую версию и каждый файл с его путём, размером и хешем. При старте лаунчер забирает манифест с ближайшего edge, сравнивает хеши с тем, что уже есть у игрока, и скачивает только изменившиеся файлы — каждый с edge, с докачкой через HTTP Range, если соединение оборвётся посреди загрузки.

Это и есть весь обновлятор: манифест плюс версионированные файлы, всё отдаётся с CDN. Не нужно поддерживать бэкенд для скачивания, не нужно гоняться за багами частичной загрузки, и та же схема работает как для лаунчера на ПК, так и для мобильной игры, забирающей пакеты ресурсов и удалённую конфигурацию при первом запуске.

манифест версии, отдаваемый с 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": "..." }
  ]
}

Справляйтесь со всплесками релиза и DDoS

Игры — одни из самых всплесковых и атакуемых вещей в интернете: релиз или распродажа отправляет каждого игрока скачивать одновременно, а онлайн-игры — любимая цель DDoS. Раздача скачиваний с edge уже поглощает легитимный всплеск, потому что сеть отвечает на него близко к игрокам, а не через ваш источник.

Помимо этого, поставьте перед своими эндпоинтами скачивания и игровым/аккаунтным API CDN WAF и защиту от DDoS, а также добавьте rate limiting, чтобы ни один клиент не мог заваливать маршрут логина или проверки патча. Ваш настоящий источник остаётся скрытым за edge, так что и всплеск релиза, и атака попадают на сеть, построенную для их поглощения, а не на ваш сервер. (Чтобы обозначить границы: это защищает вашу HTTP-доставку и API — смягчение атак на серверы мультиплеера в реальном времени по UDP находится на отдельном, специализированном уровне.)

Что так распространяют студии