WebSocket עבור 1C-Bitrix: הגדרה והפחתת השהיה

תארו לעצמכם: פורטל ארגוני עם 500 עובדים, צ'אט כערוץ התקשורת הראשי. כל 20 שניות, הדפדפן של כל עובד שולח בקשה "יש הודעות חדשות?" — זהו Long Polling. השרת מוצף, והודעות מגיעות באיחור. נתקלנו בזה עשרות פעמים. הגדרת WebSocket ב-Bitrix פותרת את הבעיה באופן קיצוני: השרת דוחף נתונים ברגע שהם מופיעים, עומס הערוץ יורד ב-70%, והשהיה — במילישניות. עם הניסיון שלנו (10+ שנים עם Bitrix, 50+ פרויקטי WebSocket) אתם מקבלים אחריות לפעולה יציבה.

כיצד WebSocket מאיץ את Bitrix24

WebSocket הוא חיבור דו-כיווני קבוע בין הדפדפן לשרת. ב-Bitrix, המודול pull (Push and Pull) מטפל בכך. כאשר קיים NodeJS push-server, הוא עובר אוטומטית מ-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 לאפס. חיסכון במשאבים מאפשר לשרת יותר לקוחות על אותה חומרה. בפרויקט אחד, הורדנו את עומס ה-CPU של השרת מ-85% ל-25% והפחתנו את השהיית אספקת ההודעות מ-15 שניות לפחות מ-100ms.

הגדרת WebSocket שלב אחר שלב ב-Bitrix

בדיקת סביבה

ודאו שהשרת עומד בדרישות: PHP 7.4+, Node.js 12+, המודול BX.Pull.connect({ serverEnabled: true, serverUrl: 'https://example.ru/bitrix/subws/', guestMode: false, userId: USER_ID, userHash: USER_HASH, transport: 'websocket' // принудительно WebSocket }); מופעל (עבור NodeJS push-server). הניסיון שלנו מראה ש-80% מהבעיות נובעות מהיעדר הרשאות ביצוע לתהליך NodeJS.

הגדרת Nginx

WebSocket דורש טיפול מיוחד ב-Nginx. המפתח הם כותרות proc_open ו-Upgrade:

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; } } 

Connection — מטפל נכון גם בחיבורי WebSocket (Upgrade: websocket) וגם בבקשות HTTP רגילות דרך מיקום אחד.

אשכולות NodeJS Push-Server

תהליך NodeJS יחיד משתמש בליבת CPU אחת. תחת עומס גבוה (1000+ חיבורים), יש צורך במצב אשכול — מספר תהליכי עובדים מאחורי מאזן עומסים:

ב-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; } } של push-server:

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

map $http_upgrade $connection_upgrade פירושו מפגשים דביקים: לקוח אחד תמיד פוגע באותו עובד. ללא זה, חיבורי 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 (לחיצת יד בלבד):

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 

מידע נוסף על הפרוטוקול בויקיפדיה.

שגיאות נפוצות ופתרונות

בואו נסתכל על כמה בעיות נפוצות בהגדרת WebSocket. ראשית, החיבור נופל כל 60 שניות. סיבה: 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 ב-Nginx לא מוגדר או ברירת המחדל היא 60 שניות. פתרון — הגדילו את ה-timeout ל-3600 שניות. שנית, WebSocket לא עובד מאחורי Cloudflare. Cloudflare מנתב WebSocket רק בתוכניות בתשלום (Pro+). בתוכנית החינמית — השתמשו ב-long polling או הוציאו את דומיין ה-WebSocket מ-Cloudflare (DNS בלבד). שלישית, שגיאה 400 Bad Request במהלך לחיצת יד. Nginx לא מעביר את כותרת systemctl status push-server לשרת האחורי — בדקו journalctl -u push-server ו-netstat -tlnp | grep 9011. HTTP/2 לא תומך בשדרוג WebSocket — השתמשו ב-HTTP/1.1 בלבד עבור נקודת הקצה של WebSocket.

מה כלול בהגדרת WebSocket

• ביקורת על תצורת השרת וה-Bitrix הנוכחית (בדיקת מודול X-Forwarded-Proto, גרסת PHP, NodeJS).
• הגדרת Nginx: פרוקסי WebSocket, SSL, מגבלות חיבורים.
• התקנה והגדרה של NodeJS push-server: אשכולות, מפגשים דביקים.
• אינטגרציה עם Bitrix24: כפיית WebSocket, בדיקת גיבוי ל-SSE/Long Polling.
• אופטימיזציה של מגבלות מערכת: proxy_read_timeout, Upgrade, proxy_http_version 1.1.
• תיעוד לתמיכה וניטור.
• הדרכת מנהלים (שעה).

אנו מבטיחים פעולה יציבה: לאחר ההגדרה, אנו מתמודדים עם עומסים של עד 10,000 חיבורים במקביל (מאושר על ידי מקרי בוחן). צרו קשר לייעוץ חינם על הפרויקט שלכם. אנו נעריך את התשתית הנוכחית שלכם ונציע את הפתרון האופטימלי.