Rate limiting

В CesiumJS система ограничения частоты запросов строится вокруг управления сетевой нагрузкой при работе с потоковыми 3D-данными: тайлами, текстурами, геометрией, а также внешними сервисами (геокодинг, terrain, imagery). Основная цель — предотвращение перегрузки браузера и серверов при одновременной загрузке большого количества ресурсов сцены.

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

RequestScheduler как центральный механизм контроля нагрузки

Основной компонент, отвечающий за rate limiting, — это Cesium.RequestScheduler. Он управляет очередями сетевых запросов и распределяет их по приоритетам.

Система учитывает два основных типа лимитов:

  • глобальные лимиты браузера на количество одновременных HTTP-соединений
  • внутренние лимиты Cesium на категорию ресурсов

Внутри Cesium запросы делятся на категории:

  • REQUESTS_PER_SERVER
  • REQUESTS_PER_SERVER_THROTTLE
  • REQUESTS_PER_SERVER_INFLIGHT

Каждый сервер (или endpoint) получает собственный набор ограничений, что предотвращает монопольное использование соединений одним источником.

Пример конфигурации:

Cesium.RequestScheduler.maximumRequestsPerServer = 18;
Cesium.RequestScheduler.maximumRequestsPerServerWithoutThrottling = 6;
Cesium.RequestScheduler.throttleRequests = true;

Эта конфигурация задаёт базовую модель:

  • небольшое количество «быстрых» запросов
  • ограниченное число фоновых запросов
  • включённый механизм автоматического троттлинга

Приоритизация запросов и конкуренция ресурсов

Каждый запрос в Cesium получает приоритет. Он зависит от типа данных и их визуальной значимости.

Основные уровни приоритета:

  • высокий приоритет: тайлы в текущем поле зрения камеры
  • средний приоритет: соседние тайлы и предварительная загрузка
  • низкий приоритет: дальние уровни детализации и фоновые данные

Система динамически перераспределяет очередь в зависимости от движения камеры. При резком перемещении происходит перерасчёт приоритетов, и часть запросов может быть отменена.

Важный аспект: отмена запросов не блокирует сервер, но снижает сетевой шум и экономит пропускную способность.

Ограничение параллельной загрузки и влияние браузера

Cesium учитывает ограничения HTTP/1.1 и HTTP/2:

  • для HTTP/1.1 типично 6 соединений на домен
  • для HTTP/2 — мультиплексирование, но с внутренними лимитами потока

Cesium не полагается полностью на браузер, а вводит собственную очередь ожидания.

Ключевые механизмы:

  • очередь pending-запросов
  • очередь active-запросов
  • очередь throttled-запросов

Перемещение между очередями происходит каждый кадр в render loop.

3D Tiles и поведение rate limiting при потоковой загрузке

При работе с Cesium3DTileset система ограничения запросов становится критически важной, поскольку сцена может содержать десятки тысяч тайлов.

Алгоритм загрузки:

  1. вычисление видимости тайлов (frustum + occlusion)
  2. оценка screen space error
  3. формирование списка необходимых запросов
  4. постановка в очередь RequestScheduler

Параметр:

maximumScreenSpaceError: 16

влияет не только на качество, но и на количество сетевых операций: чем выше детализация, тем больше запросов одновременно активируется.

При перегрузке сети Cesium снижает агрессивность загрузки, откладывая менее важные тайлы.

ImageryProvider и контроль текстурных запросов

Слои изображений (imagery layers) создают отдельный поток запросов. Для них применяются отдельные правила:

  • текстуры имеют собственный приоритет
  • повторные запросы дедуплицируются
  • применяется кэширование по координатам тайла

Типичный источник нагрузки — тайловые сервисы (XYZ, WMTS).

Пример:

const imageryLayer = new Cesium.ImageryLayer(
  new Cesium.OpenStreetMapImageryProvider({
    url: "https://tile.openstreetmap.org/"
  })
);

Cesium ограничивает число одновременных загрузок текстур, чтобы не блокировать геометрию сцены.

Cesium Ion и серверные ограничения

При использовании Cesium Ion добавляется внешний слой rate limiting на стороне сервиса:

  • квоты на количество тайлов
  • ограничения на потоковую передачу terrain
  • лимиты на tileset streaming

CesiumJS не получает прямую информацию о лимитах сервера, поэтому использует косвенные механизмы:

  • экспоненциальное замедление повторных запросов
  • отказ от агрессивного префетчинга
  • снижение параллелизма при ошибках 429

Обработка перегрузки и backpressure

При превышении лимитов система переходит в режим деградации нагрузки:

  • отмена низкоприоритетных запросов
  • уменьшение количества prefetch-тайлов
  • увеличение задержек между повторными запросами

Если сервер возвращает ошибки:

  • 429 Too Many Requests
  • 503 Service Unavailable

Cesium включает backoff-стратегию с увеличением интервалов повторных попыток.

RequestRenderMode и влияние на сетевую активность

Режим:

scene.requestRenderMode = true;

влияет на rate limiting косвенно. В этом режиме:

  • рендеринг не происходит постоянно
  • запросы активируются только при изменениях сцены
  • уменьшается число фоновых запросов

Это снижает нагрузку на сеть, но увеличивает задержку отображения новых данных.

Кэширование как часть системы ограничения запросов

Cesium активно использует несколько уровней кэша:

  • память браузера (in-memory cache)
  • IndexedDB (в некоторых провайдерах)
  • HTTP cache headers

Кэш снижает фактическое количество сетевых обращений, что напрямую уменьшает давление на rate limiting.

Для 3D Tiles:

  • кэшируются геометрические чанки
  • повторные запросы избегаются при одинаковых tile coordinates

Кастомизация лимитов и адаптация под сеть

В реальных приложениях часто требуется настройка под слабые каналы связи.

Типичная стратегия:

Cesium.RequestScheduler.maximumRequestsPerServer = 8;
Cesium.RequestScheduler.maximumRequestsPerServerWithoutThrottling = 2;
Cesium.RequestScheduler.throttleRequests = true;

Дополнительно:

  • уменьшение maximumScreenSpaceError
  • отключение prefetch (tileset.preloadFlightDestinations = false)
  • ограничение количества активных imagery layers

Поведение при медленной сети

При высокой задержке сети система автоматически:

  • увеличивает очередь pending-запросов
  • снижает агрессивность загрузки high-resolution тайлов
  • отдаёт приоритет текущему viewport

Ключевой эффект — стабильность кадра вместо полного качества сцены.

Влияние отмены запросов на производительность

Cesium активно использует отмену запросов (cancellation tokens). Это позволяет:

  • не загружать устаревшие тайлы
  • уменьшать нагрузку на сеть
  • ускорять реакцию на движение камеры

Отменённые запросы освобождают слот в RequestScheduler, позволяя запускать более актуальные операции.

Управление конкурентностью в сложных сценах

При большом количестве Cesium3DTileset и imagery layers возникает конкуренция за ресурсы.

Основные методы контроля:

  • объединение tileset-источников
  • снижение уровня детализации на дальних расстояниях
  • использование уровня LOD с более крупными тайлами
  • ограничение количества одновременно активных источников данных

Каждый tileset конкурирует за общий пул запросов, поэтому архитектура сцены напрямую влияет на сетевую нагрузку.

Практика распределения приоритетов между слоями

Типичная модель приоритизации:

  • terrain — высокий приоритет
  • 3D Tiles в фокусе камеры — высокий
  • imagery — средний
  • prefetch — низкий

Cesium перераспределяет ресурсы динамически, но разработчик может косвенно влиять через настройки видимости слоёв и геометрию сцены.

Динамическое регулирование нагрузки во время навигации

Во время интерактивного перемещения камеры система:

  • увеличивает долю запросов высокого приоритета
  • временно замораживает фоновый prefetch
  • пересчитывает очередь каждый frame update

После остановки камеры:

  • запускается догрузка высокого разрешения
  • активируется фоновая загрузка дальних тайлов

Эта модель позволяет сохранять интерактивность даже при ограниченном канале связи.

Оглавление