Long Polling מול WebSockets: מתי הפתרון הפשוט עדיף על המתוחכם

מאת צוות מדיה דיל · 07.08.2026 · API Engineering · 7 דק׳

השוואה טכנית מעמיקה בין Long Polling ל-WebSockets: עלות תשתית, latency, תאימות עם רשתות ארגוניות, ומתי דווקא הפתרון ה'ישן' הוא ההחלטה ההנדסית הנכונה.

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

איך Long Polling עובד

Long Polling הוא טכניקה שמנצלת HTTP רגיל, בלי שום פרוטוקול מיוחד: הלקוח שולח בקשת GET רגילה, אבל השרת לא עונה מיד — הוא משהה את התגובה עד שיש מידע חדש לשלוח, או עד ל-Timeout מוגדר (למשל 30 שניות), ומה שקורה הוא שברגע שהתגובה חוזרת (עם מידע חדש, או ריקה בגלל Timeout), הלקוח מיד שולח בקשה חדשה, וחוזר חלילה. מבחוץ זה נראה כמעט כמו זרם רציף, אבל בפועל זו סדרה של בקשות HTTP נפרדות ועצמאיות לחלוטין:

async function longPoll() {
  try {
    const res = await fetch('/updates?since=' + lastSeen, { signal: timeoutSignal(30000) });
    if (res.status === 200) {
      const data = await res.json();
      handleUpdate(data);
      lastSeen = data.timestamp;
    }
  } catch (e) {
    // Timeout או שגיאת רשת - זה תקין, פשוט ננסה שוב
  } finally {
    setTimeout(longPoll, 0); // מיד אחרי שהבקשה הקודמת הסתיימה
  }
}

ההבדל המהותי מ-Polling רגיל (בקשה כל כמה שניות בלי קשר אם יש מידע חדש) הוא שכאן השרת ממתין באופן פעיל, כך שברגע שיש עדכון, הוא נשלח כמעט מיידית — ה-Latency בפועל דומה בהרבה ל-WebSocket ממה שהאינטואיציה מציעה, כל עוד ה-Timeout מוגדר קצר יחסית וקצב העדכונים לא גבוה במיוחד.

ניהול Timeout בשני קצוות החיבור

נקודה טכנית שקל לפספס: יש שני Timeouts שצריכים לעבוד בהרמוניה — ה-Timeout שהשרת מגדיר לעצמו (כמה זמן להמתין לפני שמחזיר תשובה ריקה), וה-Timeout של כל שכבות התשתית שביניים (Load Balancer, Reverse Proxy, ולעיתים גם ה-Client HTTP library עצמה). אם ה-Load Balancer מוגדר ל-Idle Timeout של 30 שניות אבל השרת מתכנן להמתין 60, ה-Load Balancer ינתק את החיבור מבעד לשרת בלי שהוא יידע, והלקוח יקבל שגיאת רשת גנרית במקום תשובה מסודרת. הכלל המעשי: ה-Timeout של השרת חייב להיות קצר משמעותית (למשל 25 שניות מתוך חלון של 30) מכל Timeout אחר בשרשרת, כדי שהשרת תמיד "יספיק" להחזיר תשובה מסודרת (גם אם ריקה) לפני שמישהו אחר מנתק בשמו.

למה Long Polling עדיין רלוונטי: תאימות תשתית

ה-יתרון המרכזי, ולעיתים המכריע, של Long Polling הוא שהוא בקשת HTTP רגילה לחלוטין — לא Upgrade, לא Protocol חדש. זה אומר שהוא עובד ללא כל התאמה מיוחדת מאחורי כל Proxy ארגוני, Firewall או Load Balancer ישן שקיים בעולם. WebSocket, למרות שהוא סטנדרט בוגר כיום, עדיין נתקל בבעיות אמיתיות ברשתות ארגוניות שמריצות Proxies מפוקחים במיוחד (סביבות בנקאיות, ממשלתיות, בתי חולים) שחוסמים או משבשים Protocol Upgrade מסיבות אבטחה שמרניות. עבור מוצר B2B שחייב לתמוך גם בסביבות IT שמרניות שכאלה, Long Polling הוא לפעמים לא רק חלופה אלא הכרח — Fallback חובה שחייב לעבוד גם כשכל שאר האפשרויות חסומות.

עלות תשתית: חיבור פתוח מול בקשות חוזרות

הטרייד-אוף המרכזי הוא בין שני סוגי עלות שונים לחלוטין. WebSocket משלם עלות "קבועה" — כל חיבור פתוח צורך משאב (Socket, זיכרון) לאורך כל זמן החיים שלו, גם כשאין תעבורה בפועל, אבל אחרי ה-Handshake הראשוני אין Overhead נוסף על כל הודעה. Long Polling משלם עלות "משתנה" — כל מחזור בקשה-תגובה כולל Overhead של HTTP (כותרות, אימות מחדש לעיתים, TCP handshake אם אין Keep-Alive), אבל כל בקשה בפני עצמה קלה יותר לניהול ברמת השרת כי היא לא "תופסת" Socket ייעודי לאורך זמן ממושך מעבר לחלון ההמתנה. עבור מערכת עם עדכונים נדירים (פעם בכמה דקות) ומספר גדול של לקוחות סבילים, Long Polling עשוי בפועל לצרוך פחות משאבי שרת כוללים, כי רוב הלקוחות פשוט לא מייצרים תעבורה משמעותית בין מחזור למחזור. עבור מערכת עם עדכונים תכופים (כמה בשנייה), Overhead ה-HTTP החוזר של Long Polling הופך למשמעותי, ו-WebSocket מנצח בבירור.

יישום צד שרת: המתנה יעילה בלי חסימת Thread

נקודה חשובה למימוש בצד השרת: "המתנה" לא אמורה להיות לולאת polling פנימית שבודקת כל כמה מילישניות אם יש מידע חדש (מה שמבזבז CPU בלי סיבה). המימוש הנכון משתמש במנגנון Event-Driven — Promise/Future שנפתר כשמידע חדש מגיע (למשל דרך מנוי ל-Pub/Sub פנימי או Change Stream של מסד הנתונים), עם `Promise.race` מול Timer שמייצג את ה-Timeout:

app.get('/updates', async (req, res) => {
  const since = req.query.since;
  const result = await Promise.race([
    waitForUpdate(since),         // נפתר כשיש מידע חדש
    sleep(TIMEOUT_MS).then(() => null), // נפתר כ-null בתום הזמן
  ]);
  if (result) return res.json(result);
  return res.status(204).send(); // אין חדש, נסה שוב
});

המימוש הזה לא תופס Thread או CPU בזמן ההמתנה — הוא רק "רשום" ל-Callback שיופעל כשיש עדכון, בדיוק כמו כל קוד אסינכרוני רגיל. זה מה שמאפשר לשרת יחיד להחזיק אלפי בקשות Long Polling ממתינות בו-זמנית בלי לקרוס, כל עוד השרת בנוי על מודל Event Loop או Async I/O ולא על Thread-per-Request מסורתי.

latency בפועל: לא ההבדל שחושבים

יש הנחה נפוצה ש-WebSocket "מהיר" ו-Long Polling "איטי", אבל בפועל ההבדל תלוי מאוד באיך Long Polling ממומש. אם ה-Timeout מוגדר נכון וה-Server אכן "משחרר" את הבקשה ברגע שיש מידע חדש (ולא ממתין לזמן קבוע), ה-Latency בפועל בין אירוע לקבלתו אצל הלקוח יכול להיות קרוב מאוד ל-WebSocket — בסדר גודל של מאות מילישניות, לא שניות. ההבדל האמיתי מתגלה בתדירות גבוהה מאוד: אם יש 10 עדכונים בשנייה, כל אחד דורש מחזור HTTP מלא ב-Long Polling (כולל אימות מחדש אם לא נשמר Session), בעוד WebSocket שולח כל עדכון כ-Frame בודד על אותו חיבור פתוח, ללא Overhead נוסף. ההבדל הזה בהחלט משמעותי, אבל הוא מתבטא רק כשקצב העדכונים גבוה — למקרי שימוש עם עדכונים ספורדיים, הוא כמעט לא מורגש.

מורכבות מימוש והוצאות תפעול

מבחינת עלות פיתוח, Long Polling פשוט משמעותית לתחזוקה בפרודקשן. אין צורך בשכבת Pub/Sub לפיזור הודעות בין שרתים — כל בקשת Long Polling היא stateless מבחינת ה-Load Balancer, יכולה לנחות בכל instance, וה-instance קורא את המידע החדש ישירות ממסד הנתונים או מ-Cache משותף. אין צורך ב-Sticky Sessions, אין צורך בניהול Heartbeat נפרד (ה-Timeout של הבקשה עצמו משמש כמנגנון "בדיקת דופק" טבעי), ואין צורך בקוד Reconnection ייעודי מעבר ללוגיקה הרגילה של "אם הבקשה נכשלה, נסה שוב". זו סיבה מרכזית שבגללה מערכות רבות בוחרות ב-Long Polling כברירת מחדל ל-MVP, ועוברות ל-WebSocket רק אחרי שהוכיחו צורך אמיתי בקצב עדכונים גבוה שמצדיק את המורכבות הנוספת.

טעויות נפוצות

הטעות השכיחה ביותר במימוש Long Polling היא הגדרת Timeout ארוך מדי (דקות במקום שניות), מה שיוצר עומס גבוה על השרת כי כל בקשה "תופסת" חיבור פתוח לזמן ארוך, בדיוק כמו WebSocket אבל בלי שום יתרון תמורת זה. טעות שנייה היא היעדר בדיקת Auth מחדש בכל מחזור — אם ה-Session פג תוקף באמצע המתנה, השרת צריך להחזיר סטטוס ברור (401) כדי שהלקוח יידע להפנות מחדש להתחברות, לא סתם להמשיך להחזיק את הבקשה. טעות שלישית היא היעדר Backoff כשמחזורים נכשלים ברצף — אם השרת מחזיר שגיאה שוב ושוב, לקוח שממשיך לנסות מיידית בלי השהיה יוצר לולאה שמזרימה עומס מיותר בדיוק כשהמערכת כבר במצוקה.

עלות בענן: חיבורים מול בקשות

יש להבחין גם בהיבט הכלכלי, ולא רק הטכני. בפלטפורמות Serverless (Lambda, Cloud Run) שמחייבות לפי זמן ריצה בפועל, חיבור WebSocket שנשאר פתוח לאורך שעות — גם אם רוב הזמן אין בו תעבורה — יכול להתברר כיקר משמעותית מאשר מודל שמבוסס בקשות בדידות, כי חלק מהפלטפורמות האלה כלל לא תומכות טבעית בחיבורים מתמשכים ודורשות שירות ייעודי (API Gateway WebSocket, למשל) עם תמחור נפרד לפי מספר החיבורים הפעילים ומספר ההודעות. Long Polling, לעומת זאת, מתאים באופן טבעי הרבה יותר לארכיטקטורת Serverless: כל בקשה היא Invocation נפרדת וקצרה יחסית, מתומחרת בדיוק לפי זמן העיבוד בפועל, בלי עלות "החזקה" של חיבור פתוח בין עדכון לעדכון. זו שיקול כלכלי של ממש בסקייל גדול — אלפי לקוחות עם WebSocket פתוח שרובם שקטים רוב הזמן זו עלות תשתית משמעותית שצריך לתקצב במודע, ולא רק החלטה טכנית.

מתי לבחור מה

Long Polling מתאים כש: קצב העדכונים נמוך יחסית (לא יותר מכמה לדקה), נדרשת תמיכה ברשתות ארגוניות שמרניות, הסביבה מבוססת Serverless, או כשפשטות תפעולית חשובה יותר מ-Latency מינימלי. WebSocket מתאים כש: יש תעבורה דו-כיוונית תכופה, latency קריטי (משחקים, מסחר פיננסי), או מספר גדול של לקוחות שמצדיק את ההשקעה בתשתית Pub/Sub. הרבה מערכות מאמצות גישה היברידית: מתחילות עם WebSocket, ונופלות אוטומטית ל-Long Polling כ-Fallback כשה-Handshake נכשל (בדיוק כפי שספריות כמו Socket.IO עושות מתחת למכסה המנוע) — כך מקבלים את היתרון של שניהם בלי לוותר על תאימות רחבה. כשאנחנו במדיה דיל נדרשים להמליץ ללקוח על אחת מהגישות, השאלה הראשונה שאנחנו שואלים היא לא "מה יותר מודרני" אלא "כמה עדכונים בדקה בפועל, ולאיזה קהל יעד" — כי התשובה לשאלה הזו קובעת את ההחלטה כמעט תמיד יותר מכל שיקול טכנולוגי אחר.

סיכום

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

תגיות: Long Polling · WebSockets · Real-Time · HTTP · Latency · Architecture Decision

← חזרה לבלוג · צור קשר