למה שתי בדיקות מהירות VPN באותה מנהרה לא מסכימות
יציאה חדשה משנה את שרת הבדיקה, והתחלה איטית משנה את הציון. קבעו את היעד, יישרו את מספר הזרמים והפרידו בין עלות המעבד לבין קיבולת הקישור.
שתי הרצות, מנהרה אחת, והמספרים נבדלים פי שלושה. המנהרה לא השתנתה ביניהן. מה שהשתנה הוא המדידה: אתר בדיקה שבוחר שרת לפי המיקום הנראה שלכם, מספר זרמים שקובע אם התחלה איטית אחת או שש ממלאות את הצינור, ומשך קצר מספיק כדי להסתיים לפני שהנתיב בכלל מתחיל לשמש כראוי. בדיקות מהירות אינן שגויות, אבל הן עונות על שאלה צרה יותר מזו שאנשים שואלים אותן.
כתובת יציאה חדשה משנה את יעד הבדיקה
רוב אתרי הבדיקה בוחרים שרת מדידה אוטומטית, והם בוחרים אותו בין השאר לפי מהיכן החיבור שלכם נראה מגיע. הפעילו את המנהרה והמדינה הנראית שלכם משתנה, ולכן השרת הנבחר משתנה, וההשוואה עכשיו משתרעת על שני נתיבים שונים לשני מארחים שונים.
התוצאה אינה מדידת VPN כלל. זו מדידה של הנתיב שלכם לשרת שלא בחרתם, וההבדל בין שתי ההרצות יכול להיות נשלט על ידי הקישוריות של אותו שרת ולא על ידי משהו שהמנהרה עשתה.
קבעו את היעד לפני שאתם משנים כל דבר אחר. כל כלי אמין מאפשר לכם לבחור שרת במפורש, וכשהוא לא עושה זאת, עמוד התוצאות בדרך כלל נוקב בשם זה שהשתמש בו, וזה מספיק כדי לשים לב ששתי ההרצות אינן בנות השוואה. אשרו מה האתר ראה לפני שאתם סומכים על הבחירה שלו:
curl -sS https://ipinfo.io/json | grep -E '"ip"|"org"|"country"'אם המדינה השתנתה בין ההרצות, גם כל מה שהבדיקה בחרה אחר כך השתנה. רשמו את היציאה שנצפתה לצד כל תוצאה והבלבול נעלם ברובו.
התחלה איטית מסתיימת אחרי שרוב הבדיקות הקצרות מסתיימות
חיבור TCP אינו מתחיל בקצב הקישור. הוא מתחיל בחלון גודש קטן, מכפיל אותו בערך בכל הלוך ושוב, ומגיע לקיבולת הנתיב רק אחרי כמה הליכות וחזרות. בדיקה של עשר שניות בנתיב עם השהיה גבוהה יכולה לבלות חלק ניכר מחייה בעלייה הזו.
לכן מנהרה עם השהיה גבוהה יותר מקבלת ציון גרוע בבדיקה קצרה ממה שמגיע לה, ולכן הרצה ארוכה יותר מדווחת לעיתים קרובות מספר גבוה יותר בלי שום שינוי תצורה. מסגרת התפוקה RFC 6349 מתייחסת לכך במפורש, ולכן מדידות רציניות נמשכות מספיק כדי להגיע למצב יציב. הרצה של חמש שניות בנתיב לוויין מודדת את המאיץ, לא את הכביש.
הסתכלו על שלבי החיבור במקום לסמוך על מספר אחד. Curl מדווח על כל שלב בנפרד, כך שאתם רואים אם הזמן הולך ללחיצת היד, לעלייה או להעברה:
curl -sS -o /dev/null -w 'dns=%{time_namelookup} tcp=%{time_connect} tls=%{time_appconnect} total=%{time_total} bytes/s=%{speed_download}\n' \
https://mirror.example.net/testfile.binהריצו אותו פעמיים ברצף לאותו יעד. אם ההרצה השנייה מהירה בהרבה, מדדתם את העלייה ולא את הנתיב, וכל השוואה שהשתמשה רק בהרצה הראשונה חשודה.
זרם אחד ושישה זרמים מודדים דברים שונים
זרם TCP יחיד מוגבל על ידי החלון שהוא יכול להחזיק באוויר, שהוא בערך זמן ההלוך ושוב כפול הקצב. בנתיב ארוך המכפלה הזו עולה על מה שזרם אחד ישתמש בו, ולכן הורדה אחת מדווחת בחסר על הקיבולת שקיימת. שישה זרמים במקביל ממלאים את הפער ומפיקים מספר גדול יותר.
iperf3 -c speed.example.net -t 20
iperf3 -c speed.example.net -t 20 -P 6
mtr -rwc 50 speed.example.netשני המספרים נכונים. מספר הזרם הבודד אומר מה תוריד הורדה אחת, וזה מה שלשונית דפדפן בדרך כלל מקבלת. המספר המקבילי אומר מה הנתיב יכול לשאת בסך הכול, וזה מה שטורנט או הורדה מרובת חלקים יכול לנצל. לצטט אחד כאילו היה האחר זו הדרך שבה מנהרה בריאה מוחלפת בלי סיבה.
השוואה בין תוצאה מקבילית לתוצאת זרם יחיד היא הדרך הנפוצה ביותר שבה אנשים מסיקים ש-VPN חצה את המהירות שלהם. יישרו את השיטה ואז השוו. העקבות בפקודה השלישית מוסיפות את ההקשר החסר: נתיב עם ג'יטר גבוה יפיק תוצאות לא עקביות בשני המצבים, ואף מספר זרמים לא מתקן זאת.
הצפנה עולה זמן מעבד, עטיפה עולה בתים
שני מנגנונים פועלים על כל מנה בלי קשר למידת מהירות הקישור. הצפנה צורכת מעבד לכל בית, והעטיפה מוסיפה בתי כותרת שהקישור עדיין חייב לשאת. שניהם מופיעים כתקרה, והתסמינים שלהם שונים.
תקרת המעבד מופיעה כמישור: התפוקה מפסיקה לעלות לא משנה כמה זרמים תוסיפו, והמעבד של המכונה עסוק בזמן שהקישור אינו. בנתב קטן או בטלפון זה לעיתים קרובות הגבול האמיתי, ולכן קו מהיר יכול עדיין לתת מנהרה צנועה.
עלות הבתים קטנה יותר אך קבועה. כותרות נוספות משמעותן פחות מטען לכל מנה, ובנתיב עם יחידת שידור מרבית קבועה הן יכולות גם לעורר פיצול או חור שחור שמופיע כתקיעה בהעברות גדולות ולא כממוצע איטי.
| Observation | Likely mechanism | What to measure |
|---|---|---|
| Throughput flat as streams increase | CPU per packet on one core | Per-core utilisation during the test |
| Fast small transfers, stalled large ones | MTU and fragmentation | Payload size at which it breaks |
| Good average, unusable calls | Queueing delay behind a full buffer | Latency under load |
שלושת אלה מתבלבלים לעיתים קרובות מפני שמשתמשים מתארים את כולם כמשהו איטי. רק הראשון מגיב למכונה גדולה יותר, רק השני מגיב ל-MTU קטן יותר, ורק השלישי מגיב לניהול תורים.
כתבו את השיטה ברשומה
תוצאה שראויה לשמירה נוקבת בשם ההתקן, רשת הגישה, היציאה, שרת המדידה, הכיוון, מספר הזרמים והמשך. בלי אלה אי אפשר להשוות שני מספרים, וקריאה שמכילה מספר אחד היא למעשה מצב רוח.
שמרו גם את ההרצות הגרועות. סדרה שבה יציאה אחת יוצרת תקיעה בכל פעם מאלפת בהרבה מממוצע, והתקיעות הן בדיוק מה שממוצעים מסתירים.
ואז בדקו את הדבר שבאמת מעניין אתכם. אם הורדה גדולה היא המטרה, הורידו את הקובץ. אם שיחה היא המטרה, מדדו השהיה תחת עומס ולא תפוקה בהמתנה, מפני שמנהרה יכולה לצבור ציון טוב בבדיקת מהירות ובכל זאת להפוך כל פגישה לבלתי ניתנת לשמיעה.