Детекция connectivity

В браузерной среде Mapbox GL JS полностью зависит от сетевого состояния при загрузке стилей, тайлов, шрифтов и спрайтов. Любое взаимодействие с картографическим слоем фактически представляет собой цепочку HTTP-запросов к источникам данных, поэтому задача детекции connectivity становится частью архитектуры устойчивости приложения.

Основная сложность заключается в том, что состояние «есть сеть / нет сети» в вебе не является бинарно точным: соединение может формально присутствовать, но быть нестабильным, медленным или частично ограниченным (например, блокировка CDN, DNS сбои, деградация TLS). Поэтому корректная стратегия работы с Mapbox GL JS опирается не на один сигнал, а на комбинацию событий и проверок.

Базовые механизмы определения состояния сети в браузере

Объект navigator.onLine предоставляет базовое логическое состояние:

  • true — браузер считает, что сеть доступна
  • false — соединение отсутствует

Однако этот флаг отражает лишь наличие сетевого интерфейса, а не реальную возможность загрузки ресурсов.

Ключевое ограничение: значение может оставаться true при отсутствии доступа к внешним сервисам (например, при captive portal или блокировке CDN).

События online / offline

Браузер генерирует события:

  • window.addEventListener('online', handler)
  • window.addEventListener('offline', handler)

Эти события используются как триггеры для изменения состояния карты:

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

Слабое место модели — задержка реакции и отсутствие гарантий восстановления реальной связности.

Поведение Mapbox GL JS при потере соединения

Загрузка стиля и ресурсов

При инициализации карты выполняется последовательность запросов:

  1. загрузка style JSON
  2. загрузка sprite (PNG + JSON)
  3. загрузка glyphs (шрифты)
  4. загрузка vector tiles или raster tiles

Любой сбой на одном из этапов может привести к:

  • частично отрисованной карте
  • пустым слоям
  • повторным попыткам загрузки через внутренний loader

Событие error в карте

Mapbox GL JS генерирует событие error, которое может быть связано с:

  • сетевыми сбоями при загрузке тайлов
  • отсутствием доступа к источнику
  • некорректным стилем
  • тайм-аутами запросов

Структура события обычно содержит объект с полем error и типом источника (source, tile, style).

Ключевой аспект: событие не всегда означает полную потерю connectivity — часто это локальная ошибка конкретного ресурса.

Детекция деградации соединения через тайлы

Ошибки загрузки тайлов

Vector tiles являются наиболее чувствительным компонентом. При проблемах сети наблюдаются:

  • повторные запросы одного и того же tile
  • рост latency до тайм-аута
  • пустые тайлы без геометрии

Стратегия анализа:

  • подсчет количества failed tile requests
  • отслеживание времени ответа
  • группировка ошибок по z/x/y координатам

Тайм-ауты и повторные попытки

Внутренний loader Mapbox GL JS автоматически повторяет запросы при временных сбоях. Однако при устойчивом отсутствии сети это приводит к деградации производительности.

Типовая логика внешнего контроля:

  • ограничение числа retry
  • экспоненциальная задержка
  • отключение источника при критическом пороге ошибок

Композитная модель определения connectivity

Надежная система строится на комбинации сигналов:

1. Системный уровень

  • navigator.onLine
  • online/offline события

2. Прикладной уровень

  • успешная загрузка style
  • успешная загрузка glyphs
  • доступность sprite

3. Уровень тайлов

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

Поведение при восстановлении соединения

Перезагрузка стиля

При восстановлении сети часто требуется повторная инициализация:

  • map.setStyle() с тем же стилем
  • сброс кешированных ошибок источников
  • повторная загрузка glyphs и sprite

Причина: частично загруженный граф ресурсов не всегда автоматически восстанавливается в корректное состояние.

Реинициализация источников

Vector sources могут оставаться в состоянии ошибки. Для восстановления:

  • удаление и повторное добавление source
  • принудительное обновление tiles URL
  • сброс internal tile cache

Кэширование и Service Worker

Роль кэша в детекции connectivity

При наличии Service Worker поведение меняется:

  • тайлы могут загружаться из Cache Storage
  • отсутствие сети маскируется успешными ответами
  • ошибки становятся менее детерминированными

Следствие: детекция connectivity должна учитывать источник ответа, а не только факт успешной загрузки.

Разделение типов ресурсов

  • Style JSON — чаще кешируется агрессивно
  • Tiles — кешируются по стратегии LRU
  • Glyphs — редко обновляются
  • Sprites — промежуточная частота обновления

Стратегии деградации интерфейса карты

Режим ограниченной функциональности

При отсутствии сети:

  • отключение интерактивных слоев
  • сохранение последнего viewport
  • блокировка запросов на новые tiles

Статический режим

Если доступны cached tiles:

  • отключение обновлений источников
  • фиксация zoom и bounds
  • запрет style change

Анализ нестабильного соединения

Паттерн «flapping connectivity»

Характеризуется:

  • частыми переходами online/offline
  • нестабильной загрузкой tiles
  • чередованием успешных и failed запросов

Решение:

  • введение debounce для online событий
  • подтверждение сети через контрольный HTTP-запрос
  • threshold-based переключение состояния

Контрольный запрос (network probe)

Практика заключается в периодическом запросе к легковесному ресурсу:

  • 204 No Content endpoint
  • минимальный PNG tile
  • lightweight JSON

Если probe стабилен — считается, что сеть восстановлена, независимо от navigator.onLine.

Интеграция состояния сети с жизненным циклом карты

Инициализация

При создании карты:

  • фиксация текущего network state
  • подписка на online/offline
  • регистрация error listeners

Runtime управление

Во время работы:

  • мониторинг tile errors
  • контроль загрузки style
  • реакция на изменение сети

Завершение или перезагрузка

При критической деградации:

  • уничтожение текущего instance карты
  • повторная инициализация
  • очистка cache источников

Метрики качества connectivity

Для оценки состояния соединения используются:

  • latency tile request (ms)
  • error rate (%)
  • successful tile ratio
  • time to first render (TTFR)
  • style reload frequency

Эти метрики позволяют отличить:

  • полную потерю сети
  • деградацию CDN
  • локальные ошибки источников
  • проблемы рендеринга

Особенности поведения в разных типах источников

Vector tiles

Наиболее чувствительны к нестабильности. Ошибки проявляются визуально сразу.

Raster tiles

Могут частично загружаться, создавая «мозаичный» эффект.

GeoJSON sources

Зависят от XHR/fetch; ошибки чаще связаны с CORS или API.

Сценарии отказоустойчивости

Полная потеря сети

  • прекращение всех запросов
  • переход на cached tiles
  • блокировка style updates

Частичная деградация

  • повторные попытки отдельных tiles
  • замедление рендеринга
  • пропуски данных на карте

Восстановление

  • повторная синхронизация источников
  • очистка stale cache
  • повторный запрос style graph

Синхронизация состояния карты с сетью

Ключевая задача — согласование внутреннего состояния карты с внешним состоянием сети:

  • network state → map state machine
  • map errors → network hypothesis update
  • probe results → state correction

Так формируется адаптивная модель, в которой карта не просто реагирует на сеть, а оценивает её качество в динамике.

Оглавление