WebSocket Ping לעומת TCP Keepalive דרך פרוקסי
בחרו בדיקת חיות עבור עמית ה-WebSocket במקום להתייחס לשקע TCP חי כהוכחה שנתיב היישום מגיב.
שקע TCP חי, עמית WebSocket שמגיב והתקדמות שימושית ביישום הם שלוש תצפיות שונות:
| ראיה | מה היא מבססת |
|---|---|
| חיות ברמת TCP | נתיב התעבורה הנבדק מגיב ברמה הזו |
| WebSocket Pong תואם | העמית השיב למסגרת הבקרה הזו |
| אישור מהאפליקציה | היישום אישר פעולה לפי הפרוטוקול שלו עצמו |
פרוקסי קדמי מחזיק בדרך כלל חיבורים נפרדים כלפי הלקוח וכלפי היעד. עמית ה-TCP של הלקוח הוא הפרוקסי, בעוד Ping בתוך מנהרה מבוססת מגיע לנקודת הקצה של WebSocket.
Pong תואם
הפרוטוקול דורש ש-Pong משיב יישא את נתוני היישום של ה-Ping. השתמשו בהתאמה הזו כדי לזהות בדיקה תלויה. Pong לא מבוקש מותר, אך אינו מבקש אישור; שליחתו לאחר כל הודעת נתונים מספקת ראיה אחרת.
העדיפו את מנגנון פעימת הלב הנתמך בספרייה. JavaScript בדפדפן זקוק במקום זאת לחוזה פעימת לב ברמת היישום. בחרו מרווחים וספי כשל לפי עומס העבודה ומדיניות הרשת. השהיות בתזמון או לולאת אירועים עמוסה מדי עלולות להחמיץ סף אגרסיבי בלי להוכיח כשל רשת.
השאירו את המקלט פועל
הלקוח זקוק לקלט ופלט רציפים כדי לקלוט ולעבד מסגרות בקרה. חסימת המנגנון הזה עלולה לגרום למחסור מקומי להיראות כהשבתה.
Ping יוצר תעבורת מנהרה, אך כל מתווך מחליט בעצמו מה מספק את מדיניות החוסר שלו. שום פעימת לב אינה מבטיחה הגנה מפני גבול מוחלט של חיי החיבור.
עמית יכול להשיב ל-Ping בעוד היישום שלו מפסיק לייצר עדכונים, ומנוי שקט יכול להיות תקין. עקבו בנפרד אחר ה-Pong התקף האחרון והאירוע המשמעותי ביישום כאשר שניהם חשובים. בכשל, שמרו את המסלול, הזמנים שחלפו והבדיקה התלויה, ואז סגרו או שחזרו דרך מחזור החיים הנתמך.