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

רוחב פס והשהיה הם מדידות שונות

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

שימו לב גם לכיוון תחת עומס. חוצץ העלאה מלא יכול לעכב כל דבר אחר בזמן שקיבולת ההורדה עומדת ללא שימוש.

מדדו את זמן ההלוך־חזור תחת עומס

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

ping -c 20 -i 0.2 203.0.113.5
dd if=/dev/zero bs=1M count=50 | ssh [email protected] "cat > /dev/null"

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

העבירו את התור למקום שבו הצוואר

ניהול תורים עוזר רק במכשיר שבאמת מחזיק את הפיגור. בדקו מה הממשק עושה לפני שמוסיפים כללים.

tc -s qdisc show dev eth0
tc qdisc replace dev eth0 root fq_codel

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

מה המנהרה משנה ומה היא מסתירה

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

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

מאמרים קשורים