WebSockets בצד שרת מוסבר

בקשת HTTP רגילה עובדת לפי דפוס פשוט - הקליינט שואל, השרת עונה, והחיבור נסגר. זה מצוין לרוב השימושים, אבל מה קורה כשצריך שהשרת יוכל "לדבר" עם הקליינט מתי שהוא רוצה, בלי שהקליינט יצטרך לשאול כל הזמן אם יש חדש? הודעת צ'אט שמגיעה בזמן אמת, התראה שקופצת ברגע שמשהו קרה, לוח מחוונים שמתעדכן לבד - כל אלה דורשים ערוץ תקשורת אחר לגמרי, וזה בדיוק מה ש-WebSocket נותן.

למה HTTP רגיל לא מספיק כאן

אפשר לנסות לדמות תקשורת בזמן אמת עם HTTP רגיל, על ידי כך שהקליינט שואל את השרת שוב ושוב כל כמה שניות "יש חדש?" - טכניקה שנקראת polling. הבעיה היא שזה לא באמת מיידי, כי תמיד יש פער בין הרגע שמשהו קרה לבין השאלה הבאה, וזה גם מבזבז המון בקשות מיותרות כשאין שום דבר חדש לדווח.

אז מה זה בעצם WebSocket

WebSocket הוא פרוטוקול שמייצר חיבור אחד מתמשך בין הקליינט לשרת, ומשאיר אותו פתוח. אחרי handshake ראשוני שמתחיל כבקשת HTTP רגילה ואז "משתדרג" לחיבור WebSocket, שני הצדדים יכולים לשלוח הודעות זה לזה בכל רגע, בלי לפתוח חיבור חדש בכל פעם. השרת יכול פשוט לדחוף הודעה לקליינט ברגע שיש משהו חדש, במקום לחכות שהקליינט ישאל.

זה ההבדל המהותי - ב-HTTP הקליינט תמיד יוזם, ב-WebSocket כל צד יכול ליזום בכל רגע, וזה בדיוק מה שהופך אותו לכלי הטבעי לתקשורת דו-כיוונית בזמן אמת.

שימושים אופייניים

צ'אט הוא הדוגמה הכי מוכרת - הודעה שמישהו שולח צריכה להופיע אצל שאר המשתתפים כמעט מיד, לא כשהם רעננו את הדף. התראות דומות - כשמשהו קורה במערכת, המשתמש רואה אותו על המסך בלי לרענן כלום. לוחות מחוונים חיים - למשל מסך שמציג נתוני מסחר או מדדי מערכת שמתעדכנים כל הזמן - נהנים מאוד מ-WebSocket, כי השרת פשוט דוחף עדכון בכל פעם שהנתון משתנה, בלי לחכות לבקשה.

האתגר שמגיע עם חיבורים מתמשכים

לחיבור HTTP רגיל אין מצב - כל בקשה עצמאית, והשרת לא צריך לזכור כלום בין בקשה לבקשה. חיבור WebSocket הפוך - הוא נשאר פתוח לאורך זמן, מה שאומר שהשרת צריך לנהל ולזכור אלפי חיבורים פתוחים בו זמנית, וזה עומס אחר לגמרי מניהול בקשות HTTP קצרות.

זה נהיה מורכב עוד יותר כשיש כמה שרתים שמאזנים עומס ביניהם. אם משתמש A מחובר לשרת 1, ומשתמש B מחובר לשרת 2, איך הודעה ממשתמש A מגיעה למשתמש B? הפתרון הנפוץ הוא שכבת pub/sub משותפת - למשל דרך Redis - שכל השרתים מאזינים לה, כך שהודעה שנכתבת בשרת אחד מגיעה לכל השרתים האחרים, וכל אחד דואג להעביר אותה לחיבורים שהוא מנהל.

מתי בכלל לא צריך WebSocket

לא כל תכונה "בזמן אמת" צריכה WebSocket. אם עדכון פעם בכמה שניות או אפילו כל דקה מספיק - למשל בדיקה תקופתית של סטטוס משימה שרצה ברקע - polling פשוט לרוב מספיק, וקל משמעותית לבנות ולתחזק. WebSocket כדאי לשמור למקרים שבאמת דורשים מיידיות אמיתית, כי המורכבות הנוספת שהוא מביא - ניהול חיבורים, סנכרון בין שרתים - לא מצדיקה את עצמה כשהצורך בפועל צנוע יותר.

איך לומדים לבנות עם זה בפועל

הבנת הפרוטוקול היא שלב ראשון, אבל לבנות מערכת WebSocket שמתמודדת נכון עם ניתוקים, סנכרון בין שרתים, וניהול חיבורים בקנה מידה, זה נלמד רק בעבודה על פרויקט אמיתי. בקורס צד-שרת בונים תכונת זמן אמת אמיתית עם WebSocket, כולל כל המורכבות שמגיעה איתה.

בונים תכונת זמן אמת ולא בטוחים אם WebSocket הוא הכלי הנכון? זה בדיוק סוג השאלה שכדאי לשאול בקהילה שלנו.

הצטרפו לקהילה בדיסקורד

לסיכום

WebSocket פותח ערוץ תקשורת דו-כיווני ומתמשך בין קליינט לשרת, בדיוק מה שצריך כשכל שנייה של עיכוב מורגשת - צ'אט, התראות, לוחות מחוונים חיים. אבל הוא מגיע עם מורכבות אמיתית בניהול חיבורים וסנכרון בין שרתים, ולכן שווה לשמור אותו למקרים שבאמת דורשים תקשורת מיידית, ולא להשתמש בו רק כי הוא נשמע מתקדם יותר.