למה הורדה דרך VPN יכולה לנצח את החיבור הישיר שלכם
העברה שמאיצה בתוך המנהרה מצביעה בדרך כלל על הגבלה ביציאה אחת. שלוש השוואות מבוקרות מפרידות בין מעצב לבין האצה אמיתית.
חברו את המנהרה, התחילו הורדה גדולה, והיא נעה בערך בפי שניים מהמהירות שאליה הגיע אותו קובץ בלעדיה. זה נשמע כמו פרסומת, אבל זו יכולה להיות מדידה אמיתית בקו ביתי. הסיבה הרגילה היא הגבלת קצב שנקשרת ליציאה אחת: המנהרה נושאת את ההעברה שלכם למקום שבו המעצב לא מסתכל, והקיבולת האמיתית של הקו מתגלה לראשונה.
כלומר המספר המעניין אינו כמה מהיר היה ה-VPN. הוא כמה מהקו שלכם מעולם לא קיבלתם, ולמה.
הגבלה שעוקבת אחרי היציאה, לא אחרי המסלול
ספק גישה יכול להגביל תפוקה לכל מנוי לפי פרוטוקול או יציאת יעד, ויציאה 80 היא יעד מועדף משום שכל כך הרבה גלישה רגילה משתמשת בה. לעיתים קרובות ההגבלה אינה מוחלת מהחבילה הראשונה: ההעברה מתחילה קרוב לקצב הקו, שורפת מכסת פרץ, ואז מתייצבת על המספר המוגבל. השניות הראשונות נראות תקינות ושאר ההעברה לא.
שלחו את אותם בתים דרך יציאה אחרת והמעצב ב-80 לא יראה אותם לעולם. נראה שהמנהרה מנצחת את החיבור הישיר למרות שהיא הוסיפה קפיצה, הצפנה והתקרות משלה. מה שהשתפר אינו המסלול אלא היעדר של כלל.
זו גם הסיבה שההשפעה כה עקבית בין קבצים ליעדים. אם ההגבלה נמצאת ביציאה, כל מה שמועבר באותה יציאה מתנהג אותו דבר, יהיה גודל הקובץ אשר יהיה ומי שיהיה המארח. יעד שמושך כלל אחר מציג עקומה אחרת, וההבדל הזה הוא אבחוני בעצמו.
מדדו את המישור, לא את השיא
שיא הוא החלק הפחות אינפורמטיבי של העברה, מפני שכל חיבור נראה טוב בזמן שהחוצצים שלו מתמלאים. רשמו היכן הקצב מתייצב וכמה זמן הוא נשאר שם.
curl -o /dev/null -w '%{speed_download} %{time_total}\n' https://<host>/test.bin
scp user@<transfer-host>:/data/test.bin /tmp/הריצו את הזוג בזה אחר זה על אותה מכונה, באותה שעה, מול מארחים ברשתות דומות. דגימה אחת לא מוכיחה דבר; צורת העקומה לאורך שתי הרצות של כל אחד היא מה שמבדיל מכסת פרץ מהגבלה יציבה. רשמו היכן הקצב משתטח ולא מה הראתה השנייה הראשונה, מפני שהפרץ הוא בדיוק מה שמעצב נותן לכם לפני שהוא מתחיל להגביל. מישור שקט שמחזיק עד סוף ההעברה הוא המספר להשוואה.
השאירו את הקובץ דחוס מלכתחילה כדי שדחיסת תעבורה לא תוכל להיות מוצעת כהסבר. PDF או ארכיון מסיר את המשתנה הזה, וגם מונע ממישהו לטעון שהמנהרה דחסה את המטען. אם שתי ההעברות משתמשות באותו קובץ, ההבדל היחיד שנותר הוא המסלול והיציאה. רשמו את הכלי ואת היציאה לצד כל מספר, אחרת ההרצה השנייה אינה ברת השוואה לראשונה.
שלוש השוואות שמבודדות את הסיבה
עברו עליהן לפי הסדר והפסיקו ברגע שהתבנית ברורה, מפני שכל אחת שוללת סיפור אחר.
- חזרו על אותה הורדה בנתיב האינטרנט הרגיל ובכלי העברה ביציאה אחרת, ממארח בעל קיבולת דומה.
- חזרו על שניהם עם קובץ שאינו ניתן לדחיסה, כדי שדחיסה תפסיק להיות מועמדת.
- אם אתם מפעילים בעצמכם את שרת המנהרה, קשרו אותו מחדש ליציאה 80, כווננו את פרופיל הלקוח כך ששני הקצוות יסכימו, והעבירו שוב. אם המנהרה יושבת כעת בקצב האינטרנט המוגבל, ההגבלה עוקבת אחרי היציאה ולא אחרי ה-VPN.
השלב השלישי הוא המכריע, והוא גם זה שאנשים מדלגים עליו מפני שהוא דורש שינוי תצורה. בלעדיו הראיתם ששני דברים שונים, לא שהיציאה היא הסיבה.
מה המדידה הזו אינה יכולה לתמוך בו
היא אינה מראה שהמנהרה מהירה יותר באופן כללי, שהיא דוחסת משהו, או שיציאות אחרות בקו אינן מוגבלות. היא מתארת את ההעברה הזו, בקו הזה, בשעה הזו. הגבלות יכולות לחול לפי הפעלה, לפי מנוי או לפי שעה ביום, והן יכולות להשתנות בלי הודעה.
היא גם אינה מוכיחה שהמסלול הישיר שבור. מסלול מוגבל עדיין עובד; הוא מוגבל בכוונה, ומדיניות מכוונת אינה תקלה שמחכה לתיקון.
והיא בוודאי אינה מצדיקה לנתב הכול דרך המנהרה. כל יישום ביציאה 80 נשאר מוגבל, בעוד שכל מה שאתם מפנים תלוי כעת בקפיצה נוספת ובאופן כשל נוסף.
הפכו את הממצא למשהו שאפשר לפעול לפיו
רשמו את התצפית כמדידה ולא כפסק דין: העברות גדולות ביציאה 80 מתייצבות סמוך למחצית הקצב שאותו קובץ משיג ביציאה אחרת, בשעות האלה, בקו הזה, עם הדגימות האלה מצורפות. זו בקשת תמיכה שמישהו יכול לחקור.
«ה-VPN מהיר יותר» אינו כך. זה מזמין תשובה על תקורת ההצפנה, והתשובה הזו נכונה טכנית ובכל זאת אינה אומרת לאיש דבר מועיל. צרפו את מספר הדגימות, השעה והיציאה, כדי שהקורא יוכל לשחזר את התבנית.
אם תחליטו להמשיך להשתמש ביציאה אחרת להעברות גדולות, רשמו את ההסתייגות ברשומות שלכם: העברת מאזין ליציאה 80 מתנגשת בכל שרת אינטרנט שכבר קשור שם, והכשל הנובע נראה כמו מנהרה שבורה ולא כמו התנגשות יציאות.