WebSocket для 1С-Бітрікс: налаштування та зниження затримок

WebSocket для 1С-Бітрікс: налаштування та зниження затримок

Ми — команда з 10+ років досвіду в 1С-Бітрікс та понад 50 реалізованих проєктів з WebSocket. Уявіть: у корпоративному порталі 500 співробітників, чат — основний канал зв'язку. Кожні 20 секунд браузер кожного співробітника надсилає запит «є нові повідомлення?» — це Long Polling. Сервер задихається, а повідомлення приходять із затримкою. Ми стикалися з цим десятки разів. Налаштування WebSocket в Бітрікс вирішує проблему кардинально: сервер сам надсилає дані при появі, навантаження на канал падає на 70%, затримка — мілісекунди. Економія від переходу на WebSocket може досягати $2400 на рік на серверних ресурсах. В одному з проєктів ми знизили витрати на сервер з $1000 до $600 на місяць — економія $4800 на рік. Вартість налаштування WebSocket для типових проєктів починається від $500. З нашим досвідом ви отримуєте гарантію стабільної роботи.

Як WebSocket прискорює роботу Бітрікс24?

WebSocket — це постійне двостороннє з'єднання між браузером і сервером (full-duplex communication). У Бітрікс за нього відповідає модуль pull (Push and Pull). За наявності NodeJS push-сервера він автоматично перемикається з Long Polling на WebSocket. Клієнтська частина — JS-бібліотека BX.PullClient, яка пробує WebSocket першим, при невдачі відкочується на SSE, потім на Long Polling.

WebSocket кращий за Long Polling у 20 разів за затримкою (мілісекунди проти 20 секунд) і знижує навантаження на сервер до 70%. WebSocket перевершує Long Polling у 20 разів за швидкістю доставки та у 3 рази за ефективністю використання ресурсів. WebSocket базується на протоколі TCP з бінарним кадруванням, що дозволяє мінімізувати overhead. Для забезпечення надійності застосовується механізм підтвердження (ACK) та контроль потоку (flow control). WebSocket також знижує навантаження на сервер у 3 рази порівняно з Long Polling. WebSocket збільшує продуктивність чату в 20 разів.

Транспорт визначається в 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% (з $500 до $300 на місяць).

Налаштування WebSocket в Бітрікс: покроково

1. Перевірка оточення Переконайтеся, що сервер відповідає вимогам: PHP 7.4+, Node.js 12+, увімкнено модуль proc_open (для роботи NodeJS push-server). Наш досвід показує, що 80% проблем пов'язані з відсутністю прав на виконання NodeJS-процесу.

2. Конфігурація 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 використовує протокол на основі TCP, забезпечуючи full-duplex зв'язок з мінімальним overhead завдяки кадруванню та маскуванню даних. Для контролю потоку застосовується flow control, а для відновлення з'єднання — exponential backoff.

   Додаткові методи налагодження

   • Логи NodeJS push-server: дивитися вивід systemctl status push-server або journalctl -u push-server.
   • Перевірити, що порт 9011 відкритий: netstat -tlnp | grep 9011.
   • Якщо використовується SSL, переконатися, що Nginx передає правильний заголовок X-Forwarded-Proto.

   Методи діагностики WebSocket:

   Метод	Опис
   Chrome DevTools	Фільтр WS, перевірка фреймів
   Curl handshake	Перевірка відповіді 101
   Логи push-server	journalctl -u push-server

Типові помилки та їх вирішення

Часто виникає проблема, коли з'єднання розривається кожні 60 секунд через таймаут Nginx. Рішення — збільшити proxy_read_timeout до 3600s. Інша поширена проблема — WebSocket не працює за Cloudflare на безкоштовному тарифі, тому слід використовувати DNS-only. Також можлива помилка 400 Bad Request, якщо Nginx не передає заголовок Upgrade; необхідно переконатися в наявності proxy_http_version 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 одночасних з'єднань (підтверджено кейсами). Зв'яжіться з нами для безкоштовної консультації щодо вашого проєкту. Ми оцінимо поточну інфраструктуру та запропонуємо оптимальне рішення.