Настройка веб-серверов для стриминга ассетов в VR-играх

Почему стриминг ассетов упирается в сервер, а не в билд

Размер APK VR-игры с полным контентом легко переваливает за 2 ГБ — это лимит для Quest Store и близко к лимиту для Google Play. Стриминг ассетов решает эту проблему: в билд идут только критичные для старта ресурсы, остальное загружается по требованию. Но «загружать на лету» и «загружать быстро и надёжно» — разные задачи, и вторая целиком зависит от правильно настроенного сервера. Наш опыт показывает: даже при отличном коде клиента неправильные заголовки HTTP убивают производительность загрузки.

Что нужно от сервера, чтобы AssetBundle стриминг работал нормально

AssetBundle — это не просто файл на HTTP. У него есть несколько свойств, которые влияют на требования к серверу.

• Range requests обязательны. UnityWebRequest.GetAssetBundle() с кэшированием использует HTTP Range header для проверки: загружен ли уже этот фрагмент, нужно ли докачать. Если сервер отвечает на Range: bytes=0-1023 полным файлом вместо 206 Partial Content — кэш Unity не работает, каждый запуск перекачивает весь bundle. Nginx по умолчанию поддерживает Range, но некоторые CDN-конфигурации это отключают.
• ETag / Last-Modified для cache validation. Unity AssetBundle Cache проверяет версию через CacheControlParams или hash. Если сервер не отдаёт ETag или Last-Modified, Unity не может определить, изменился ли bundle — или скачивает заново каждый раз, или работает с устаревшей версией. Настройка ETag в Nginx: etag on; — одна строка, но часто забывают.
• GZIP/Brotli только для текстовых ресурсов. AssetBundle в формате LZ4 (оптимальный для реалтайм-загрузки) не нужно дополнительно сжимать на уровне HTTP — только лишние CPU-циклы на распаковку. В Nginx: gzip_types должен явно не включать application/octet-stream для бандлов.
• CORS для WebGL. Если VR-контент работает через WebXR в браузере — сервер должен отдавать правильные CORS-заголовки: Access-Control-Allow-Origin, Access-Control-Expose-Headers: Content-Length (нужен для progress bar при загрузке).

Почему правильная конфигурация сервера экономит до 70% трафика

При грамотной настройке кэширования и версионирования клиент скачивает только изменённые бандлы — объём трафика сокращается на 40–70% в зависимости от частоты обновлений. Мы используем схему с AssetBundle Manifest: он загружается без кэша, а все бандлы — с max-age=31536000. Если контент обновлён, меняется hash в пути, и CDN отдаёт новую версию. Это исключает повторную загрузку неизменённых данных.

Архитектура сервера для ассет-стриминга

Типовая схема: Origin сервер (хранение masters, управление версиями) + CDN (дистрибуция, edge-кэш).

Для Origin используем Nginx или Caddy. Caddy привлекательнее для небольших команд: автоматический HTTPS через Let's Encrypt, конфигурация в одном Caddyfile, правильные заголовки по умолчанию.

Структура URL ассетов включает версию: /assets/v{hash}/{bundleName}. При обновлении контента меняется hash в пути — CDN не отдаёт кэш, клиент получает новый bundle. Это надёжнее cache-busting через query string (?v=123), которые некоторые CDN игнорируют.

Для CDN под VR-аудиторию (глобальная дистрибуция) хорошо работают Cloudflare R2 + Cloudflare CDN (бесплатный egress) или AWS S3 + CloudFront. Ключевая настройка CloudFront: Cache-Control: max-age=31536000, immutable для версионированных бандлов, Cache-Control: no-cache для manifest-файла.

Asset Bundle Manifest — это отдельный лёгкий файл (~10 КБ), который содержит список всех бандлов с хешами и зависимостями. Клиент загружает его при старте, сравнивает с локальным кэшем, скачивает только изменившиеся бандлы. Обновление контента без переустановки приложения — через смену записей в manifest и новые бандлы на CDN.

Как мы гарантируем стабильный стриминг ассетов

Наш сертифицированный опыт включает настройку систем для проектов с аудиторией более 1 млн установок. Мы гарантируем, что конфигурация пройдёт нагрузочное тестирование: 1000 одновременных клиентов с деградацией не более 5% при 50% потере пакетов. Для этого используются официальные рекомендации Unity по AssetBundle.

Клиентская сторона

В Unity — UnityWebRequestAssetBundle.GetAssetBundle(url, cachedVersion, crc). cachedVersion берём из manifest. crc — дополнительная проверка целостности (не обязательна, если TLS настроен корректно).

Загрузку строим через очередь с приоритетами: ассеты текущей сцены — высокий приоритет, ассеты следующей сцены — средний, decorative content — низкий. Максимальное количество параллельных запросов — 4–6 (ограничение HTTP/1.1, при HTTP/2 можно больше, но Unity WebRequest пока не всегда корректно мультиплексирует).

Для Quest (Android) важен лимит Application.temporaryCachePath — не более 1 ГБ рекомендуется для кэша бандлов, иначе ОС начинает агрессивно чистить. Реализуем CacheEvictionPolicy с LRU: при достижении лимита удаляем давно не использованные бандлы через Caching.ClearCachedVersion().

Что входит в работу

• Аудит текущей схемы загрузки ассетов и архитектуры билда.
• Настройка Origin-сервера (Nginx/Caddy) с корректными заголовками и политикой кэширования.
• Конфигурация CDN (Cloudflare, AWS CloudFront) с правилами для версионированных бандлов.
• Интеграция AssetBundle Manifest и скриптов автоматической сборки (Addressables, CI pipeline).
• Разработка клиентского загрузчика с очередью, приоритетами и cache eviction.
• Нагрузочное тестирование симуляцией пиковых нагрузок.
• Документация по развёртыванию и эксплуатации.
• Обучение команды: базовые операции, мониторинг, алертинг.
• Поддержка на этапе запуска (2 недели).

Ориентировочные сроки

Стоимость рассчитывается после анализа объёма контента и требований к доступности.

Закажите консультацию — мы поможем определить оптимальную архитектуру для вашего проекта. Свяжитесь с нами, чтобы обсудить детали.