WebSocket для 1С-Битрикс: настройка и снижение задержек

WebSocket для 1С-Битрикс: настройка и снижение задержек

Представьте: в корпоративном портале 500 сотрудников, чат — основной канал связи. Каждые 20 секунд браузер каждого сотрудника отправляет запрос «есть новые сообщения?» — это Long Polling. Сервер захлебывается, а сообщения приходят с задержкой. Мы сталкивались с этим десятки раз. Настройка WebSocket в Битрикс решает проблему кардинально: сервер сам отправляет данные при появлении, нагрузка на канал падает на 70%, задержка — миллисекунды. С нашим опытом (10+ лет с Битрикс, более 50 проектов с WebSocket) вы получаете гарантию стабильной работы.

Как WebSocket ускоряет работу Битрикс24?

WebSocket — это постоянное двустороннее соединение между браузером и сервером. В Битрикс за него отвечает модуль pull (Push and Pull). При наличии NodeJS push-сердера он автоматически переключается с Long Polling на WebSocket. Клиентская часть — JS-библиотека BX.PullClient, которая пробует WebSocket первым, при неудаче откатывается на SSE, затем на Long Polling.

WebSocket лучше Long Polling в 20 раз по задержке и снижает нагрузку на сервер до 70%.

Транспорт определяется в bitrix/js/pull/pull.js через переменную BX.Pull.config. Принудительно установить транспорт для отладки:

BX.Pull.connect({
    serverEnabled: true,
    serverUrl: 'https://example.ru/bitrix/subws/',
    guestMode: false,
    userId: USER_ID,
    userHash: USER_HASH,
    transport: 'websocket' // принудительно WebSocket
});

Сравним Long Polling и WebSocket:

Почему стандартный Long Polling не подходит для высоконагруженных проектов?

При 2000 онлайн-пользователей Long Polling генерирует 2000 запросов каждые 20 секунд — 100 запросов в секунду. Это создаёт огромную нагрузку на Nginx и PHP-FPM. WebSocket держит одно постоянное соединение на пользователя, что снижает количество HTTP-запросов до нуля. Экономия ресурсов позволяет обслуживать больше клиентов на том же железе. Снижение нагрузки на сервер позволяет экономить на аренде мощностей — в одном из проектов мы сократили затраты на сервер на 40%.

Настройка WebSocket в Битрикс: пошагово

Проверка окружения

Убедитесь, что сервер соответствует требованиям: PHP 7.4+, Node.js 12+, включён модуль proc_open (для работы NodeJS push-server). Наш опыт показывает, что 80% проблем связаны с отсутствием прав на выполнение NodeJS-процесса.

Конфигурация Nginx

WebSocket требует специальной обработки в Nginx. Ключевое — заголовки Upgrade и Connection:

map $http_upgrade $connection_upgrade {
    default upgrade;
    ''      close;
}

server {
    listen 443 ssl http2;
    server_name example.ru;

    # ... SSL настройки ...

    # WebSocket endpoint для push-server
    location /bitrix/subws/ {
        proxy_pass http://127.0.0.1:9011;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $connection_upgrade;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        # Критически важно: без этого Nginx разрывает соединение через 60 сек
        proxy_read_timeout 3600s;
        proxy_send_timeout 3600s;

        # Не буферизировать — данные должны идти в реальном времени
        proxy_buffering off;
    }
}

map $http_upgrade $connection_upgrade — корректная обработка как WebSocket (Upgrade: websocket), так и обычных HTTP-запросов через один location.

Кластеризация NodeJS push-server

Один NodeJS-процесс использует одно ядро CPU. При высокой нагрузке (1000+ соединений) нужен кластерный режим — несколько worker-процессов за load balancer:

В config.json push-server:

{
  "cluster": {
    "workers": 4,
    "sticky": true
  }
}

sticky: true — «липкие» соединения: один клиент всегда попадает на один worker. Без этого WebSocket-соединение может разорваться при переключении между воркерами.

Для балансировки нескольких NodeJS-инстансов в Nginx:

upstream push_backend {
    ip_hash; # sticky sessions по IP
    server 127.0.0.1:9011;
    server 127.0.0.1:9012;
    server 127.0.0.1:9013;
    server 127.0.0.1:9014;
}

location /bitrix/subws/ {
    proxy_pass http://push_backend;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection $connection_upgrade;
    proxy_read_timeout 3600s;
    proxy_buffering off;
}

Отладка и диагностика

В Chrome DevTools → Network → фильтр WS — показывает все WebSocket-соединения с данными фреймов.

Через curl (только handshake):

curl -v \
  -H "Upgrade: websocket" \
  -H "Connection: Upgrade" \
  -H "Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==" \
  -H "Sec-WebSocket-Version: 13" \
  https://example.ru/bitrix/subws/
# Ожидаемый ответ: HTTP/1.1 101 Switching Protocols

Подробнее о протоколе — в Wikipedia.

Типовые ошибки и их решение

Рассмотрим несколько частых проблем при настройке WebSocket. Первая — соединение разрывается каждые 60 секунд. Причина: proxy_read_timeout в Nginx не выставлен или равен умолчанию (60s). Решение — увеличить таймаут до 3600s. Вторая — WebSocket не работает за Cloudflare. Cloudflare проксирует WebSocket только на платных тарифах (Pro+). На бесплатном тарифе — использовать long polling или выводить WebSocket-домен из-под Cloudflare (DNS-only). Третья — ошибка 400 Bad Request при handshake. Nginx не передаёт заголовок Upgrade бэкенду — проверить наличие proxy_http_version 1.1 и proxy_set_header Upgrade. HTTP/2 не поддерживает WebSocket upgrade — для WebSocket endpoint использовать только HTTP/1.1.

Что входит в настройку WebSocket?

• Аудит текущей конфигурации сервера и Битрикс (проверка модуля pull, версии PHP, NodeJS).
• Настройка Nginx: WebSocket-прокси, SSL, лимиты соединений.
• Установка и конфигурация NodeJS push-server: кластеризация, sticky sessions.
• Интеграция с Битрикс24: принудительное включение WebSocket, тестирование отката на SSE/Long Polling.
• Оптимизация системных лимитов: ulimit, worker_connections, LimitNOFILE.
• Документация по поддержке и мониторингу.
• Обучение администратора (1 час).

Гарантируем стабильную работу: после настройки выдерживаем нагрузку до 10 000 одновременных соединений (подтверждено кейсами). Свяжитесь с нами для бесплатной консультации по вашему проекту. Мы оценим текущую инфраструктуру и предложим оптимальное решение.