آیا VPN می‌تواند از اتصال مستقیم سریع‌تر باشد؟
کپسوله‌سازی سربار می‌افزاید، اما خروج می‌تواند مسیر عبور، مقصد و شرایط انتقال را تغییر دهد. با سه مقایسه تصمیم بگیرید، نه با یک آزمون سرعت.
گاه انتقالی که روی اتصال دفتر کند پیش می‌رود از میان تونل سریع تمام می‌شود، و کپسوله‌سازی اضافی این را غیرممکن نشان می‌دهد. این تناقض ظاهری از مقایسهٔ چیزهای اشتباه می‌آید. تونل کار اضافه می‌کند و همچنین مسیر شبکه‌ای را که ترافیک طی می‌کند تغییر می‌دهد، نشانی‌ای که مقصد می‌بیند و گاهی این که کدام سرور اصلاً پاسخ می‌دهد. تصمیم میان دو مسیر نیازمند جدا کردن این سه اثر پیش از هر نتیجه‌ای دربارهٔ سرعت است.
سه چیزی که تونل می‌تواند تغییر دهد
نخستین مورد عبور است. مسیریابی اینترنت از سیاست اپراتور و روابط تجاری پیروی می‌کند نه از تأخیر اندازه‌گیری‌شده، بنابراین مسیر از طریق ارائه‌دهندهٔ VPN می‌تواند شبکه‌هایی متفاوت از مسیر مستقیم را بپیماید. می‌تواند از یک نقطهٔ تبادل شلوغ پرهیز کند یا روی نقطه‌ای با peering بهتر فرود آید، و به همان راحتی می‌تواند بدتر باشد.
دومین مورد مقصد است. تغییر نشانی خروج اغلب پاسخ DNS را تغییر می‌دهد، و یک شبکهٔ محتوا ممکن است کش یا منطقهٔ دیگری به شما بدهد. آن‌گاه بخشی از بهبود به سرور تازه تعلق دارد نه به تونل. همان نام میزبان می‌تواند روی سرور نزدیک‌تر یا کم‌بارتر فرود آید بی‌آنکه چیزی روی کلاینت تغییر کند.
سومین مورد رفتار انتقال است. کپسوله‌سازی اندازهٔ مؤثر بسته را تغییر می‌دهد، و تونلی که از یک قطعهٔ میانی پرافت پرهیز می‌کند می‌تواند بگذارد یک جریان TCP پنجره‌اش را بزرگ کند به جای آن که پیوسته عقب بکشد. هیچ‌یک از این‌ها سازوکار شتاب‌دهی جهانی نیست؛ هر کدام شرطی است که باید مشاهده شود. جدا کردنشان همان چیزی است که کنجکاوی را به واقعیت بدل می‌کند.
چیزی که نمی‌تواند تغییر دهد
هیچ چیز در تونل به پیوند میان دستگاه و شبکه ظرفیت نمی‌افزاید. کانال اشباع‌شدهٔ Wi-Fi، مایل آخر شلوغ یا طرح موبایل محدود هر دو مسیر را یکسان محدود می‌کنند، و آزمون سرعت از میان تونل نمی‌تواند از آن سقف فراتر برود. همان پیوند بسته‌های کپسوله‌شده را حمل می‌کند، پس کپسوله‌سازی می‌تواند ظرفیت مصرف کند اما هرگز آن را نمی‌سازد. آنچه تغییر می‌کند این است که بسته‌ها پس از ترک آن پیوند به کجا می‌روند. از همین رو نتیجهٔ سریع تونل همیشه توضیحی بالادستِ نخستین گام دارد.
محدودیت‌های سمت سرور هم به همان اندازه بی‌اعتنا هستند. اگر میزبان دور آهسته سرویس دهد، مسیر بهتر تنها پاسخ آهسته را کارآمدتر تحویل می‌دهد و کاربر همچنان منتظر می‌ماند. یک مبدأ مشترک زیر بار در همان لحظه روی هر دو مسیر آهسته به نظر می‌رسد.
مسیرها را درست مقایسه کنید
کاربرد، جهت، مدت و هم‌زمانی را یکسان نگه دارید و فقط مسیر را تغییر دهید. هر آزمون را بیش از یک بار و در ساعت یکسان روز اجرا کنید و نشانی خروج و پاسخ حل‌کننده را در کنار گذردهی ثبت کنید. یک اجرا نمونه است نه اندازه‌گیری، و یک بار دانلود سریع می‌تواند برخورد با کش باشد که دربارهٔ مسیر چیزی نمی‌گوید. شرط‌ها را پیش از نتیجه‌ها بنویسید، چون تفسیر اعداد بعداً دشوار است.
mtr -rwc 50 -T -P 443 203.0.113.20
curl -o /dev/null -s -w '%{speed_download} %{time_connect}\n' https://example.com/file
dig +short cdn.example.com
traceroute -n -T -p 443 cdn.example.comپاسخ حل‌کننده همان جزئیاتی است که بیشتر مقایسه‌ها از قلم می‌اندازند، و «بهبودهایی» را توضیح می‌دهد که با اجبار همان سرور ناپدید می‌شوند. اگر نشانی میان اجراها متفاوت باشد، آزمون دو مقصد را مقایسه کرده نه دو مسیر را. تأخیر و افت را در کنار گذردهی گزارش کنید، چون مسیری که در مجموع سریع‌تر است اما به هر درخواست تعاملی تأخیر می‌افزاید برای بار کاری که شکایت کرده بهتر نیست. زمان رفت‌وبرگشت برای هر چیزی که می‌پرسد و منتظر می‌ماند مهم‌تر از سرعت انبوه است.
کجا این تفاوت ارزش نگه داشتن دارد
اگر تونلی تأییدشده به‌طور قابل اعتماد یک بار کاری مشخص را بهبود دهد، این یک انتخاب عملیاتی مشروع است: بار کاری، اندازه‌گیری و خروجی به‌کاررفته را مستند کنید. یک سند قابل استفاده یک میزبان، نشانی خروجی که تونل تولید کرده، پاسخ حل‌کننده و همان ارقام از مسیر مستقیم در همان روز را نام می‌برد. این برای مهندس بعدی کافی است تا مقایسه را تکرار کند نه این که دوباره درباره‌اش جدل کند. هنوز مدرکی نیست که ارائه‌دهنده چیزی را محدود می‌کند، و به کاربردها یا ساعت‌های دیگر منتقل نمی‌شود.
سند اندازه‌گیری را همراه پیکربندی نگه دارید. این به پرسش بعدی پاسخ می‌دهد که آیا بهبود هنوز وجود دارد، و تنها راه دانستن این است که مسیر تغییر کرده یا بار کاری. سندی بدون تاریخ نمی‌تواند به آن پرسش اصلاً پاسخ دهد.