چرا افت VPN روی شبکه سلولی بدتر از Ethernet به نظر میرسد
دو شبکه دسترسی و دو حالت تونل چهار عدد میدهند. ماتریس را پر کنید، هر دو کسر را نگه دارید و بگذارید الگو اندازهگیری بعدی را انتخاب کند.
همان لپتاپ، همان سرور و همان تونل میتوانند یکپنجم توان عبوری خود را روی Ethernet و سهچهارم آن را روی شبکه سلولی از دست بدهند، و هیچیک از این دو عدد به معنای خراب بودن VPN نیست. هر شبکه دسترسی مسیر متفاوتی میدهد و تونل مسیر دومی روی آن اضافه میکند. مقایسه یک عدد تونلدار با یک عدد بدون تونل به هیچ پرسشی پاسخ نمیدهد، چون آن دو عدد مخرجهای متفاوت را توصیف میکنند. چهار خانه و یک کسر نگهداشت برای هر ردیف به شما میگوید پرسش بعدی کدام است.
چهار خانه، نه یک جریمه
خط پایه مستقیم و نتیجه تونلدار را روی هر شبکه دسترسی اندازه بگیرید و آنها را به عنوان ماتریس نگه دارید، نه یک حکم واحد. خط پایه همان کار انجامشده روی آن شبکه بدون تونل است؛ نتیجه تونلدار همان کار با تونل است.
| Access network | Direct baseline | Same task through the tunnel |
|---|---|---|
| Ethernet | E0 | E1 |
| Cellular | C0 | C1 |
برای آزمونهای مستقیم از بار کاری مجاز استفاده کنید و کنترلهای حریم خصوصی مورد نیاز محیط را حفظ کنید. آزمونی که سیاست را نقض میکند عددی تولید میکند که نمیتوانید منتشر کنید و نباید تکرار کنید.
متغیرها را ثابت نگه دارید
دستگاه، برنامه، مقصد، جهت انتقال و نقطه پایانی VPN را در هر چهار خانه ثابت نگه دارید. اگر خدماتی بین اجراها سرور آزمون خود را بیصدا عوض کند، تغییر را ثبت کنید و آن جفت را کنترلنشده در نظر بگیرید، نه اینکه تفاوت را با میانگین هموار کنید.
ماتریس را در هر دو جهت و در ساعتهای قابل مقایسه روز تکرار کنید. شرایط رادیوی سلولی و بار روی سلول آن در چند دقیقه تغییر میکند، بنابراین یک خط پایه غیرعادی خوب میتواند جریمه ظاهری را بزرگتر نشان دهد. پراکندگی نتایج را کنار یک مقدار نماینده ثبت کنید و یادداشت کنید که اجراهای تونلدار با خطوط پایه درهم بودهاند یا به صورت یک بلوک اجرا شدهاند.
درهمآمیزی بیش از آنچه بیشتر مردم انتظار دارند مهم است. خط پایهای که پیش از ناهار اندازهگیری شده و اجرای تونلداری که پس از آن اندازهگیری شده، دو شبکه متفاوت با یک نام هستند.
مخرج را آشکار نگه دارید
هم کسر نگهداشت و هم نرخ مطلق را گزارش کنید: E1 تقسیم بر E0، و C1 تقسیم بر C0. پیوند سریعی که بخش کوچکی از توان عبوری خود را نگه میدارد و پیوند کندی که بیشتر آن را نگه میدارد یافتههای متفاوتی هستند، و تنها کسر تفاوت را نشان میدهد.
توان عبوری مطلق همچنان تعیین میکند کاربر چه کاری میتواند انجام دهد. کسر تعیین میکند کجا را نگاه کنیم. وقتی Ethernet بیشتر خط پایه خود را نگه میدارد و شبکه سلولی بسیار کمتر، متغیر جالب روی مسیر سلولی است نه درون رمزنگاری.
هر دو عدد به گزارش تعلق دارند، چون هر یک به تنهایی از نتیجهای پشتیبانی میکند که دادهها از آن پشتیبانی نمیکنند.
پیش از تغییر هر چیز، الگو را بخوانید
سقفهای تونلدار مشابه روی هر دو شبکه به چیز مشترکی اشاره میکنند: نقطه پایانی، پردازنده آن، یک محدودیت نرخ یا یک پرش پرترافیک. افتهایی که فقط روی شبکه سلولی دیده میشود به مسیر آن شبکه، افت بسته، تأخیر و اندازه مؤثر بسته اشاره میکند.
اینها سرنخ هستند نه تشخیص، و این تفاوت هنگام نوشتن تیکت مهم است. سقف مشترک با تعویض مودم سلولی بهتر نمیشود، و افت فقط سلولی با تغییر اندازه نقطه پایانی بهتر نمیشود. پیش از پیشنهاد یک تغییر بگویید کدام یک از دو الگو را دیدهاید. به این ترتیب تغییر یک پیشبینی با خود دارد و اندازهگیری بعدی میتواند آن را تأیید یا باطل کند.
راهنمای کارایی خود OpenVPN نیز محدودیتهای پهنای باند، پردازنده، انتقال و اندازه بسته را در همان خطوط جدا میکند، که یادآوری سودمندی است از اینکه تونل بهندرت یک متغیر است.
وقتی اندازه بسته مظنون است
پوششدهی فضای بسته را مصرف میکند، بنابراین اندازه مؤثر روی مسیر سلولی میتواند کوچکتر از مقداری باشد که رابط اعلام میکند. برای مسیری که مقایسه میکنید شواهد اندازه بسته را نگه دارید، نه اینکه مقداری را از نام فناوری دسترسی فرض کنید.
Datagram packetization-layer path MTU discovery کشف اندازه مؤثر را توصیف میکند نه کدگذاری ثابت آن را. از مشاهداتی که پیادهسازی پشتیبانی میکند استفاده کنید، و به عنوان پیشگیری یک MTU پایین دلبخواه را به هر کارخواه تحمیل نکنید، چون این کار یک مشکل را با مشکل بدتری روی مسیرهایی که سالم بودند عوض میکند.
فرضیه اندازه به شواهد خود نیاز دارد: همان انتقال در دو اندازه، با ثبت الگوی افت.
هر بار یک متغیر اضافه کنید
انتقال جایگزین را فقط پس از ذخیره ماتریس خط پایه مقایسه کنید. این کار یک متغیر عمدی را در بازی نگه میدارد و به شما امکان میدهد تغییر را به آن نسبت دهید نه اینکه حدس بزنید.
تنظیم اندازه بار TCP را از رفتار دادهگرامهای UDP جدا نگه دارید، چون این دو به افت و اندازه مسیر واکنش متفاوتی دارند. بهبودی که از تغییر انتقال میآید شواهدی درباره همان انتقال است، نه اثبات اینکه رمزنگاری یا پوشش علت اصلی بوده است.
ترتیب کار: چهار خانه را پر کنید، هر دو کسر را حساب کنید، اجراها را درهم بیامیزید، سپس یک فرضیه انتخاب کنید و آن را با یک تغییر بیازمایید. هر چیز دیگری مقایسه دو ناشناخته است.