چرا دانلود از طریق 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 با هر وب‌سروری که از قبل آنجا بسته شده برخورد می‌کند و خرابی حاصل شبیه تونل خراب است نه تعارض پورت.