Как реализовать и оптимизировать постоянное соединение в 1С через HTTP и веб-сервисы?

← На главную

При проектировании высоконагруженных систем интеграции перед разработчиком 1С часто встает вопрос: как избежать накладных расходов на создание нового сеанса при каждом HTTP-запросе? Традиционный подход Stateless (без сохранения состояния) подразумевает, что каждый запрос автономен, однако процедура авторизации и инициализации параметров сеанса в 1С может занимать значительное время (от нескольких сотен миллисекунд до нескольких секунд). В этой статье мы разберем, как минимизировать эти задержки, имитируя или настраивая «постоянное соединение».

Использование механизма повторного использования сеансов (Session Pooling)

Самый эффективный и штатный способ оптимизации работы с HTTP-сервисами в 1С — это настройка пула сеансов на стороне веб-сервера. Этот механизм позволяет платформе не завершать сеанс сразу после выполнения запроса, а «засыпать» и ожидать следующего вызова. Разберем, как это настроить в файле публикации default.vrd.

Проанализируем основные параметры секции pool, которые влияют на удержание соединений:

Параметр size: определяет максимальное количество сеансов, которые будут одновременно удерживаться в памяти сервера. Если запросов приходит больше, чем указано в size, новые запросы будут ждать или создавать новые временные сеансы.
Параметр maxAge: это фактически «время жизни» вашего постоянного соединения в секундах. Если установить здесь большое значение (например, 3600), сеанс будет оставаться активным в течение часа, ожидая новых данных от клиента.
Параметр waitTimeout: время ожидания свободного сеанса из пула, если все доступные слоты заняты.

Пример настройки файла default.vrd для обеспечения стабильного пула сеансов:


<point xmlns="http://v8.1c.ru/8.2/virtual-resource-system"
       xmlns:xs="http://www.w3.org/2001/XMLSchema"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       base="/MyService"
       ib="Srvr=ServerName;Ref=BaseName;">
    <httpService name="MyAPI" rootUrl="api" enable="true" reuseSessions="autouse"/>
    <pool size="10" maxAge="600" waitTimeout="5"/>
</point>

Обратите внимание на параметр reuseSessions="autouse". В этом режиме платформа сама управляет привязкой запросов к существующим сеансам в пуле, что значительно ускоряет обработку мелких, но частых запросов.

Управление сеансами через заголовок IBSession

Если нам требуется более жесткий контроль над тем, какой именно запрос в какой сеанс попадает (например, при реализации сложной многошаговой транзакции), мы можем использовать механизм явного управления сессиями. Рассмотрим подробнее фазы работы с заголовком IBSession:

Инициация (start): Клиент отправляет первый запрос с HTTP-заголовком IBSession: start. В ответ сервер 1С создает полноценный сеанс и возвращает его уникальный идентификатор в заголовке ответа.
Работа с ID: Во всех последующих запросах клиент передает полученный ID (например, IBSession: 00000000-0000-0000-0000-000000000000). Платформа 1С мгновенно направляет этот запрос в уже открытый сеанс, где подгружены все параметры сеанса и кэшированные данные.
Завершение (finish): Чтобы не занимать лицензию зря, клиент должен отправить финальный запрос с заголовком IBSession: finish.

Выясним причину, по которой этот метод не всегда удобен: если клиентское приложение завершится аварийно и не отправит finish, сеанс в 1С «зависнет» до истечения таймаута, потребляя лицензию. Это критически важно учитывать при расчете количества доступных лицензий в организации.

Альтернатива: Технология WebSockets для real-time взаимодействия

Рассмотрим ситуацию, когда нам нужно не просто быстро отвечать на запросы, а инициировать передачу данных со стороны сервера 1С на клиент (Push-уведомления). Стандартный HTTP так не умеет, так как он всегда работает по схеме «запрос-ответ». В этом случае на помощь приходят WebSocket.

Платформа 1С не поддерживает WebSocket напрямую как сервер, но мы можем реализовать это через внешние компоненты или прослойки. Разберем по шагам, как обычно строится такая схема:

Разворачивается промежуточный сервер (на Node.js, Go или Python), поддерживающий WebSocket или SignalR.
1С взаимодействует с этим сервером как клиент (через HTTP-запросы или внешние компоненты).
Внешние клиенты (браузеры, мобильные приложения) держат постоянное TCP-соединение с промежуточным сервером.

Это позволяет обойти ограничения 1С по лицензированию и обеспечить моментальную доставку сообщений без постоянного опроса (polling) базы данных.

HTTP Keep-Alive и уровень веб-сервера

Не путайте сеанс 1С и TCP-соединение. Даже если вы используете режим Stateless, важно убедиться, что на уровне веб-сервера (IIS или Apache) включена опция Keep-Alive. Посмотрим, что это дает:

При включенном Keep-Alive после выполнения одного запроса TCP-соединение между клиентом и сервером не разрывается. Это исключает затраты времени на повторное выполнение «рукопожатия» (Handshake), что особенно заметно при использовании протокола HTTPS, где установка защищенного соединения требует нескольких циклов обмена данными. Это «постоянное соединение» на низком уровне, которое работает прозрачно для кода 1С.

Проблема потребления лицензий и масштабируемости

Проанализируем ситуацию с лицензиями более детально. Это главный «подводный камень» при реализации постоянных соединений. Каждый сеанс, удерживаемый в пуле (параметр size в default.vrd), или каждый сеанс, открытый через IBSession: start, занимает одну сеансовую лицензию 1С.

Если ваше приложение ориентировано на тысячи внешних пользователей, использование «постоянных соединений» в 1С напрямую через HTTP/Веб-сервисы станет экономически невозможным. В таких случаях мы рекомендуем:

Использовать брокеры сообщений (например, RabbitMQ). 1С подключается к очереди, забирает пачку сообщений и закрывает соединение.
Использовать промежуточные кэширующие базы (Redis, MongoDB), где данные для внешних потребителей лежат в готовом для отдачи виде без участия тяжелых механизмов 1С.