Как работают пул сеансов и повторное использование сессий в HTTP-сервисах 1С

← На главную

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

По каким разрезам формируются сеансы в пуле

Платформа 1С:Предприятие 8.3 поддерживает повторное использование сеансов для обслуживания входящих HTTP- и SOAP-запросов. Чтобы запрос был обработан уже существующим сеансом из пула (без затрат времени на полноценный старт сеанса), все ключевые параметры входящего подключения должны полностью совпадать. Разберем каждый разрез пула сеансов:

Тип сервиса — определяет технологию обращения: Web-сервисы (SOAP) или HTTP-сервисы (REST/JSON/XML). Сеанс, созданный для HTTP-сервиса, не может быть использован для вызова Web-сервиса, и наоборот.
Наименование сервиса — имя объекта метаданных в дереве конфигуратора (свойство Имя ветки «Общие — HTTP-сервисы» или «Общие — Web-сервисы»). Для каждого конкретного сервиса создается свой изолированный пул.
Пользователь и пароль — учетные данные (Basic-аутентификация или параметры в строке соединения), под которыми авторизуется внешний клиент. Запросы от имени разных пользователей всегда распределяются по разным сеансам.
Значения разделителей — используются в конфигурациях, поддерживающих работу в режиме разделения данных (мультитенантность / SaaS). Сеанс привязывается к конкретной области данных.
Безопасный режим — состояние выполнения программного кода (включение или отключение безопасного режима для сеанса), предотвращающее выполнение потенциально опасных операций.

Где настраиваются параметры сервисов и пула сеансов

Проанализируем, где в конфигураторе и в файлах публикации на веб-сервере задаются указанные свойства:

В дереве метаданных конфигуратора: перейдем в ветку Общие → HTTP-сервисы (или Web-сервисы). В свойствах сервиса указывается имя, корневой URL, а также параметр ПовторноеИспользованиеСеансов (значения Использовать / НеИспользовать / Авто).
В диалоге публикации на веб-сервере: выберем пункт меню Администрирование → Публикация на веб-сервере. На вкладке Прочие настраиваются флаги Разделение данных и Безопасное.
В файле публикации (default.vrd): параметры пула можно переопределить непосредственно в XML-структуре файла конфигурации веб-сервера.

Рассмотрим пример тонкой настройки пула сеансов в файле default.vrd для конкретного HTTP-сервиса:


<httpService name="MobileAPI"
    rootUrl="mobile"
    enable="true"
    reuseSessions="autouse"
    sessionMaxAge="60"
    poolSize="10"
    poolTimeout="30"
    waitTimeout="5"/>

Разберем назначение атрибутов управления пулом:

poolSize — максимальное количество параллельно удерживаемых сеансов в пуле для данного сервиса.
poolTimeout — время жизни неактивного сеанса в пуле (в секундах). Если за это время новых вызовов не поступило, сеанс уничтожается и освобождает память.
waitTimeout — предельное время ожидания освобождения сеанса из пула при пиковой нагрузке, когда все сеансы лимита poolSize заняты.

Механизм работы пула и выигрыш в производительности

Выясним, как работает обслуживание запросов при включенном повторном использовании сеансов:

При первом обращении клиента веб-сервер инициирует создание нового серверного сеанса с типом соединения Соединение с HTTP-сервисом.
Сеанс выполняет обработчик метода (например, GET или POST) и возвращает HTTP-ответ.
После завершения ответа сеанс не закрывается, а переходит в состояние ожидания внутри пула.
При поступлении следующего запроса с идентичными параметрами авторизации и адресации 1С мгновенно отдает задачу готовому сеансу, экономя время на инициализации контекста, проверке прав и загрузке метаданных.
Если одновременно приходят параллельные запросы от нескольких клиентов, платформа поднимает дополнительные сеансы в пределах заданного лимита пула.

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

Особенности жизненного цикла и нюансы разработки

При использовании пула сеансов необходимо учитывать важные технические особенности платформы:

Обработчик события «ПриНачалеСеанса»: при повторном использовании сеансов процедура ПриНачалеСеанса в модуле управляемого приложения или сеанса отрабатывает только один раз — при физическом создании соединения. Для каждого последующего входящего запроса этот обработчик повторно не вызывается. Поэтому инициализацию контекста и проверку входящих параметров необходимо выполнять непосредственно внутри метода HTTP-сервиса.
Кэш и переменные сеанса: модули с признаком повторного использования возвращаемых значений сохраняют вычисленный кэш на протяжении всей жизни сеанса в пуле. Не сохраняйте клиентские контекстные данные в глобальных переменных модулей, чтобы избежать отдачи некорректных данных другим запросам.
Транзакции: каждый HTTP-вызов должен представлять собой полностью завершенную операцию. Открыть транзакцию в одном HTTP-запросе и зафиксировать в другом невозможно.

Управление авторизацией и завершение сессии (Logoff)

При использовании стандартной Basic-аутентификации браузеры и многие HTTP-клиенты кэшируют заголовок Authorization до закрытия процесса или вкладки. Чтобы принудительно сбросить сессию на клиенте, можно применить следующие подходы:

Отправка ответа 401: серверный метод может вернуть HTTP-ответ со статусом 401 Unauthorized и заголовком WWW-Authenticate: Basic realm="1C", что заставит браузер очистить сохраненные данные авторизации.
Использование токенов (Bearer / API-Key): для гибкого управления сессиями публикацию делают анонимной, а проверку доступа реализуют программно по токену в заголовках. Для завершения сеанса клиент просто отправляет запрос на инвалидацию токена в базе данных 1С.

Пример программной проверки авторизационного токена в методе HTTP-сервиса:


Функция ОбработатьЗапросGET(Запрос)
    
    ЗаголовокАвторизации = Запрос.Заголовки.Получить("Authorization");
    
    Если ЗаголовокАвторизации = Неопределено Или Не СтрНачинаетсяС(ЗаголовокАвторизации, "Bearer ") Тогда
        Ответ = Новый HTTPСервисОтвет(401);
        Ответ.УстановитьТелоИзСтроки("Требуется авторизация по токену");
        Возврат Ответ;
    КонецЕсли;
    
    Токен = Сред(ЗаголовокАвторизации, 8);
    Если Не ТокенАвторизацииДействителен(Токен) Тогда
        Ответ = Новый HTTPСервисОтвет(403);
        Ответ.УстановитьТелоИзСтроки("Токен недействителен или просрочен");
        Возврат Ответ;
    КонецЕсли;
    
    // Выполнение бизнес-логики сервиса
    Ответ = Новый HTTPСервисОтвет(200);
    Ответ.Заголовки.Вставить("Content-Type", "application/json; charset=utf-8");
    Ответ.УстановитьТелоИзСтроки("{""status"": ""success""}");
    Возврат Ответ;
    
КонецФункции

Лицензирование и устойчивость к нагрузкам

При проектировании высоконагруженных API важно помнить о двух аспектах:

Лицензии: в клиент-серверном варианте сеансы HTTP-соединений могут технически не занимать постоянную клиентскую лицензию в окне активных сеансов, однако согласно лицензионному соглашению каждый пользователь или автоматизированная система, взаимодействующая с 1С через веб-сервисы, должна быть покрыта соответствующим числом клиентских лицензий.
Защита от перегрузок: для предотвращения падения кластера 1С при всплесках запросов перед веб-сервером (Apache/IIS) рекомендуется устанавливать обратный прокси-сервер (например, Nginx) с включенным ограничением частоты входящих запросов (rate limiting). Для тяжелых операций длительной записи документов оптимально использовать асинхронную схему с помещением входящих данных в очередь и быстрой отдачей ответа 202 Accepted.