# Карта: переиспользовать HTTP-соединения и убрать последовательное ожидание

Статус: предложение, не реализовано. Инвазивность: **Низкая**. Основа: `webrtc-komaroff@772de4a`, 16.09.2026.

Открытие карты сейчас создаёт новый `ClientSession` в `init_map_handler`, затем последовательно запрашивает каталог аэропортов и позицию. Эти данные нужны одновременно, но второй запрос ждёт окончания первого. После NATS reconnect браузер снова вызывает bootstrap. На маленьком каталоге это может быть незаметно; механизм всё равно добавляет работу на каждый повтор.

![Текущий и предлагаемый bootstrap](</experiments/voice-ai/archive/c/DOCS/architecture-2026-09-16/diagrams/p01-bootstrap.svg>)

Core по-прежнему управляет начальной загрузкой карты. API по-прежнему возвращает данные, а NATS доставляет команды уже подписанному клиенту. Меняется жизнь соединения и порядок независимых запросов.

## Предлагаемая правка

Создавать HTTP session при startup Core и закрывать через cleanup context. Ограничить connection pool и задать connect/read/total timeouts. Два независимых GET выполнять параллельно. Если позиция и каталог должны отражать одну версию данных, вместо параллелизма добавить один `GET /api/map/bootstrap` с согласованным snapshot; это уже изменение API.

Каталог можно отдавать с revision/ETag и кэшировать по версии. Позицию пользователя нельзя кэшировать как общий глобальный объект: текущий mock этого не показывает, а реальная интеграция потребует user/session scope.

## Что изменится в числах

| Показатель | Подтверждённая исходная точка | Проверяемый результат |
|---|---|---|
| Создание ClientSession | 1 на bootstrap | 1 на lifecycle экземпляра Core |
| Последовательная цепочка API calls | 2 GET | 2 параллельных GET; либо 1 aggregate GET |
| Ожидание API без overhead | примерно T_airports + T_position | примерно max(T_airports, T_position) для параллельного варианта |
| Повторная передача каталога | полный payload в текущем пути | 304/кэш только при неизменной revision |
| p95 bootstrap, соединения/с | baseline отсутствует | измерить одинаковыми 1/10/50 одновременными открытиями |

Формула описывает устранение последовательного ожидания, а не обещает такое же ускорение всего экрана. Если основная задержка в тайлах MapLibre, это изменение почти не повлияет на ready-map.

## Как принять и откатить

Проверить нормальный ответ, timeout каждого backend, повтор после reconnect и shutdown без unclosed-session warnings. Для aggregate endpoint сравнить поля и порядок UI-команд со старой версией. Сначала достаточно pool + parallel GET; endpoint и кэш можно принять отдельными MR.

Откат возвращает прежний handler без изменения хранилища. При маленькой частоте открытия карты приоритет ниже исправления повторных workflow.

## Основания

[init_map_handler](<https://git.giscloud.ru/voice-chat/webrtc-komaroff/-/blob/772de4a714ae6c5abea91946e85a1953ee919ec3/src_core/handlers/handle_init_map.py>), [requestInitMap](<https://git.giscloud.ru/voice-chat/webrtc-komaroff/-/blob/772de4a714ae6c5abea91946e85a1953ee919ec3/src_front/src/assistant/assistantApp.ts>). Текущая документация [aiohttp: persistent session](<https://docs.aiohttp.org/en/stable/client_advanced.html#persistent-session>) рекомендует session с жизнью приложения и управляемым cleanup. Context7: `/aio-libs/aiohttp`, запрос о pooling и cleanup, 16.09.2026. Этот принцип применим к используемой 3.10.5; API новой версии нельзя переносить без проверки совместимости.

[Все предложения](</experiments/voice-ai/archive/c/DOCS/architecture-2026-09-16/improvements/README.md>) · [Фактическая архитектура](</experiments/voice-ai/archive/c/DOCS/architecture-2026-09-16/README.md>)