למה איבוד חבילות צריך בדיקה משלו
כל מה שאתם שולחים באינטרנט מחולק לחבילות קטנות. כשחלק מהן נעלמות, דפי אינטרנט עדיין נטענים והורדות עדיין מסתיימות, כי אפליקציות מבוססות TCP פשוט מבקשות שוב את החלק החסר. משחקים, צ׳אט קולי ושיחות וידאו לא יכולים להרשות לעצמם לחכות, ולכן הם ממשיכים לחבילה הבאה. התוצאה היא יריב שמשתגר ממקום למקום, מילים שנבלעות או פריים וידאו קפוא. בדיקת איבוד חבילות חושפת את מה שבדיקת מהירות רגילה מסתירה.
איך מתבצעת המדידה
הבדיקה מקימה ערוץ נתונים של WebRTC בין הדפדפן שלכם לשרת הבדיקה שבחרתם. הערוץ מוגדר למסירה ללא סדר וללא שליחות חוזרות כלל (maxRetransmits: 0), כך שחבילה שאבדה לעולם לא נשלחת שוב. זה קרוב מאוד להתנהגות של UDP, שבו משתמשים רוב המשחקים ואפליקציות ה-VoIP. מכיוון שהחיבור מועבר דרך שירות ה-TURN של השרת עצמו, הוא עובד גם מאחורי NAT מחמיר וברשתות ארגוניות רבות.
כל חבילה נושאת מספר סידורי. השרת מחזיר כל חבילה מיד, ובסוף הבדיקה שולח את רשימת המזהים שקיבל. הדפדפן משווה את הרשימה הזו למה ששלח ולמה שחזר:
- חבילות שלא הגיעו לשרת כלל נספרות כאיבוד בהעלאה.
- חבילות שהגיעו לשרת אך לא חזרו נספרות כאיבוד בהורדה.
- חבילות שחזרו, אבל מאוחר מכדי להועיל, מסומנות כמאחרות.
- חבילות שהגיעו שלא לפי הסדר וחבילות כפולות נספרות במונים נפרדים.
בחירת ההגדרות הנכונות
גודל החבילה, הקצב והמשך קובעים איזה סוג תעבורה הבדיקה מחקה. ברירות המחדל מתאימות לרוב האנשים, אבל אם אתם עוקבים אחרי בעיה מסוימת, נסו את הפרופילים האלה:
- משחקים: 64–128 בתים, 60–100 חבילות בשנייה, 1–2 דקות.
- שיחות קוליות: 160–200 בתים, 50 חבילות בשנייה, דקה אחת.
- חבילות גדולות: 1000–1200 בתים, 20–50 חבילות בשנייה.
- ניטור ארוך טווח: קצב נמוך, 5 דקות.
אם האיבוד עולה עם חבילות גדולות אבל לא עם קטנות, בדקו את הגדרות ה-MTU או מגבלת קיבולת בקו. אם בדיקות קצרות יוצאות נקיות אבל ארוכות מראות פרצי איבוד מזדמנים, הבעיה כנראה לסירוגין: הפרעות Wi-Fi, נתב שמתחמם יתר על המידה או עומס בשעות הערב.
מה האיבוד לפי כיוון מספר לכם
לדעת באיזה כיוון החבילות אובדות היא הדרך המהירה ביותר להבין מי צריך לתקן את הבעיה. בעיות בתוך הבית, כמו אות Wi-Fi חלש או גיבוי לענן שמנצל את כל קיבולת ההעלאה, יוצרות בדרך כלל איבוד בהעלאה. איבוד בהורדה מצביע לרוב על עומס ברשת של ספק האינטרנט, על איכות הקו בחיבורי DSL או כבלים, או על צומת עמוס במסלול לשרת. אם אתם רואים איבוד בשני הכיוונים, בדקו קודם את הקישור בין המכשיר לנתב, ואחר כך את הקישור בין הנתב לקו החיצוני.
ג׳יטר, MOS וציון החיבור
אסור לשפוט איבוד חבילות לבדו. ג׳יטר, ההפרש המוחלט הממוצע בין זמני הלוך-חזור עוקבים, מראה עד כמה ההשהיה שלכם לא יציבה. ג׳יטר גבוה מאלץ אפליקציות להשתמש בחוצץ, וחבילות שמגיעות אחרי שהחוצץ כבר הושמע נחשבות למעשה כאבודות. ציון ה-MOS משלב השהיה, ג׳יטר ואיבוד בעזרת גרסה פשוטה של מודל E לפי ITU-T G.107 כדי להעריך איך תישמע שיחה קולית: 4 ומעלה טוב, מתחת ל-3.5 פירושו ירידה ברורה באיכות. הציון A–F ואחוז היציבות מרכזים את כל זה בסיכום אחד.
צמצום הסיבה
- הריצו את הבדיקה ב-Wi-Fi ואחר כך בכבל, באותו מכשיר. הבדל גדול אומר שהרשת האלחוטית היא האשמה.
- חזרו על הבדיקה עם מיקום שרת אחר. אם האיבוד מופיע רק בשרת אחד, הבעיה במסלול הזה.
- בדקו בבוקר ושוב בערב. איבוד שמופיע רק בשעות העומס מצביע על קיבולת הרשת.
- הורידו את התוצאות כ-CSV או JSON וצרפו אותן לפניית תמיכה במידת הצורך.
לבדיקה כללית מהירה, השתמשו בבדיקת הפינג בעמוד הבית שלנו. אם משחק מסוים מגמגם, השוו את ההשהיה לאזורים בדפים כמו בדיקת הפינג ל-Valorant.