האם VPN יכול להיות מהיר יותר מחיבור ישיר?

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

שלושה דברים שהמנהרה יכולה לשנות

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

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

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

מה היא לא יכולה לשנות

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

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

השוו את המסלולים כראוי

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

mtr -rwc 50 -T -P 443 203.0.113.20
curl -o /dev/null -s -w '%{speed_download} %{time_connect}\n' https://example.com/file
dig +short cdn.example.com
traceroute -n -T -p 443 cdn.example.com

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

מתי ההבדל שווה לשמור

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

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