האם VPN צורך יותר נתונים? תוספת כותרות, חבילות שמירה ומונים

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

המיתוס: ה-VPN מכפיל את השימוש שלך

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

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

מה באמת מוסיף בייטים

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

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

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

למה שני מונים אף פעם לא מסכימים

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

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

adb shell dumpsys netstats | grep -A3 "iface=wlan0"
adb shell dumpsys netstats detail | grep -i vpn

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

מדוד משימה חוזרת במקום מבחן מהירות

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

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

לאן להסתכל כשהחשבון והאפליקציה לא מסכימים

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

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