چگونه سرعت VPN را چنان بسنجیم که اعداد معنایی داشته باشند
سرور آزمون را ثابت کنید، لایه زیرین را ساکن نگه دارید و تأخیر را جدا از توان عبوری بخوانید. تونل مسیر را پیش از آنکه چیزی بسنجد عوض می‌کند.
آزمون سرعت هرگز VPN را نمی‌سنجد. مسیری را می‌سنجد، و روشن کردن تونل بخشی از آن مسیر را پیش از حرکت نخستین بایت جایگزین می‌کند. به همین دلیل یک لپ‌تاپ در برابر یک سایت عدد سالم و در برابر سایت دیگر عدد ضعیف نشان می‌دهد، بی‌آنکه در هیچ‌یک از دو طرف چیزی تغییر کرده باشد. نتیجه را به‌عنوان شاهدی درباره یک مسیر بخوانید، نه امتیازی برای یک محصول.
سه چیز تعیین می‌کند که مقایسه ارزشی دارد یا نه: اینکه هر دو اجرا هدف یکسانی را زده باشند، اینکه شبکه دسترسی ساکن مانده باشد، و اینکه تأخیر را همراه با حجم ثبت کرده باشید.
تونل پیش از نخستین بایت چه چیزی را بازنویسی می‌کند
کارخواه هر بسته را در سرآیند دیگری می‌پیچد، پس بار مفید هر بسته کوچک‌تر می‌شود. هزینه به‌ازای هر بسته است نه هر انتقال، یعنی یک فایل بزرگ به بسته‌های بیشتری از همان فایل بدون تونل نیاز دارد. چنین هزینه اضافی به‌صورت شمار بسته‌ها دیده می‌شود، نه به‌صورت تنظیمی قابل مشاهده.
دو پیامد دارد. آزمونی که از بلوک‌های بزرگ ساخته شود هزینه هر بسته را حس می‌کند، و آزمونی که از درخواست‌های کوچک بسیار ساخته شود به‌جای آن رفت‌وبرگشت‌های متعدد را حس می‌کند. و اگر کشف MTU مسیر جایی در طول راه بسته باشد، تونل روی اندازه بسته کوچک‌تر می‌ماند و توان عبوری به‌دلیلی پایین می‌آید که هیچ ربطی به رمزها ندارد.
می‌توانید سقف را مستقیم ببینید. در لینوکس بزرگ‌ترین باری را بخواهید که بدون قطعه‌بندی عبور می‌کند، سپس با تونل روشن تکرار کنید:
ping -M do -s 1472 -c 3 203.0.113.10
اگر این شکست خورد، به 1,400 پایین بیایید و دوباره امتحان کنید. تونلی که تنها 1,380 بایت حمل می‌کند به شما می‌گوید چیزی در پایین‌تر مسیر تنگ‌تر می‌کند، و هیچ تنظیمی در کارخواه آن را بالا نمی‌آورد.
چرا سرور آزمون با روشن شدن تونل جابه‌جا می‌شود
بیشتر ابزارها بر پایه نشانی عمومی‌ای که می‌بینند یک سرور نزدیک برمی‌گزینند. با روشن بودن تونل، آن نشانی از آن گره خروج است، پس ابزار ممکن است میزبان را در شهر یا کشوری دیگر برگزیند. آن‌گاه دو مقصد را مقایسه می‌کنید و شکاف میان آن‌ها فاصله خروج تا میزبان آزمون را نیز در بر می‌گیرد.
سرور را پیش از نخستین اجرا با نام یا شناسه ثابت کنید و در هر اجرای بعدی نگه دارید. اگر ابزار آن را نگه نمی‌دارد، هدفی را برگزینید که خودتان کنترل می‌کنید و خودتان آن را بگردانید: iperf3 -c test.example.net -R -t 20 مقصد را ثابت نگه می‌دارد و عددی به شما می‌دهد که می‌توانید با دیروز بسنجید.
یک متغیر را عوض کنید، و لایه زیرین یکی نیست
بی‌سیم همان تغییر پنهان همیشگی است. توان سیگنال با جابه‌جا شدن لپ‌تاپ و اشغال کانال با آغاز تماس یک همسایه تغییر می‌کند، پس دو اجرا با ده دقیقه فاصله روی Wi-Fi تکرار یک آزمون نیستند. کابل، یا موقعیتی ثابت با سطح سیگنال نوشته‌شده، بیشتر آن نوفه را برمی‌دارد. یادداشت سطح سیگنال در آغاز و پایان هر اجرا معمولاً کافی است تا نشان دهد دو اجرا به هم مربوط‌اند یا نه.
بار دستگاه هم در همان سبد است. کارخواهی که روی یک هسته رمزگذاری می‌کند بسیار پیش‌تر از پیوند به سقف خود می‌رسد، و همگام‌سازی پس‌زمینه زودتر به آن می‌رسد. در طول اجرا CPU را بپایید و بنویسید چه چیز دیگری باز بود. تنظیمات توان هم می‌تواند اینجا گاز بگیرد، زیرا لپ‌تاپی که با باتری کار می‌کند ممکن است پردازنده را بسیار پیش از آنکه پیوند نزدیک به اشغال باشد محدود کند.
| Measurement | What it answers | What it misses |
|---|---|---|
| Download | Bulk capacity along the path | Any question about responsiveness |
| Upload | Capacity from client to exit | Download health |
| RTT to a fixed target | Distance plus queueing | Whether capacity is available |
| Jitter or loss | Stability under load | How much the link can carry |
لایه زیرین را ساکن نگه دارید، نه اینکه روی آن میانگین بگیرید. سه اجرای هم‌خوان بیش از ده اجرای گرفته‌شده در اتاق‌های مختلف می‌گویند.
تأخیر، افت و ICMP به پرسش‌های متفاوتی پاسخ می‌دهند
پینگ کاوشگر کوچکی به نشانی ثابت می‌فرستد، و بسیاری از شبکه‌ها به ICMP با اولویت پایین پاسخ می‌دهند یا آن را کاملاً نادیده می‌گیرند. پاسخ‌های نیامده کاوشگر را توصیف می‌کنند، نه بسته‌های برنامه را. زمان رفت‌وبرگشتی که زیر بار بالا می‌رود معمولاً یعنی صفی در حال پر شدن است، نه اینکه مسیر بلندتر شده باشد.
برای دانستن اینکه تونل تأخیر می‌افزاید یا نه، یک هدف را با و بدون آن مقایسه کنید، یا دو خروجی را که از همان شبکه دسترسی در دسترس‌اند بسنجید. کاوشگر را چندبار اجرا کنید و به پراکندگی نگاه کنید، زیرا میانگین درست همان نوسانی را پنهان می‌کند که یک تماس را بی‌فایده می‌کند.
به کاری برگردید که کند به نظر می‌رسید
سنجه‌ای که بهتر می‌شود در حالی که تماس هنوز بریده‌بریده است به چیز دیگری پاسخ داده است. کاری را که پژوهش با آن آغاز شد دوباره اجرا کنید، چه جلسه باشد چه پوشه اشتراکی چه نشست میزکار دوردست. اگر عدد بهتر شد و کار نه، گلوگاه جایی بود که آزمون هرگز به آن نرسید، مانند سرور پشت تونل یا پیوند بالاسوی شما.
هر اجرا را با دستگاه، شبکه دسترسی، نقطه پایانی، پروتکل، هدف و زمان ثبت کنید. اجرایی که هرگز متصل نشد یک نتیجه دسترس‌پذیری است نه توان عبوری صفر، پس آن را زیر همان برچسب بایگان کنید نه اینکه پاکش کنید.
فهرست کوتاهی پیش از مقایسه بعدی
هدف را ثابت کنید و بنویسید چرا آن را برگزیدید. اندازه بسته‌ای را که مسیر اجازه می‌دهد ثبت کنید تا افت بعدی توضیحی داشته باشد. شبکه دسترسی را یکسان نگه دارید، بار CPU را بنویسید و پیش از باور کردن یک تفاوت سه اجرا بگیرید.
سپس دقیقاً یک چیز را عوض کنید و تکرار کنید. مقایسه‌ای که می‌توانید توضیح دهید از آن یکی با عدد بزرگ‌تر بهتر است.