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 одновременных соединений (подтверждено кейсами). Свяжитесь с нами для бесплатной консультации по вашему проекту. Мы оценим текущую инфраструктуру и предложим оптимальное решение.