یک دانلود بزرگ را شروع می‌کنید، ثانیه‌های اول عادی به نظر می‌رسند و سپس سرعت تقریباً روی نیمی از آنچه خط باید تحویل دهد تثبیت می‌شود. تونل را وصل می‌کنید، همان دانلود را تکرار می‌کنید و در تمام فایل سرعت بالاتری نگه می‌دارد. این هم‌زمان یک اندازه‌گیری واقعی و یک نتیجهٔ گمراه‌کننده است، چون تونل مسیر را سریع‌تر نکرد. فقط ترافیک شما را از پورتی بیرون برد که چیزی در طول مسیر آن را محدود می‌کرد.

شکل منحنی آن را لو می‌دهد

به انتقال نگاه کنید نه به عدد نهایی. مسیر محدودشده معمولاً نزدیک سرعت خط شروع می‌شود، سهمیهٔ انفجاری خود را خرج می‌کند و بعد روی حد تثبیت می‌شود، پس میانگین به این بستگی دارد که چه مدت نگاه کرده‌اید. تونلی که مسیر را واقعاً بهتر می‌کرد، از ثانیهٔ اول سرعت بهتری نشان می‌داد و آن را حفظ می‌کرد. فلات اثر انگشت است و اگر فقط قله را ثبت کنید، به‌راحتی از دست می‌رود.

دو بار اجرای همان فایل، یکی مستقیم و یکی از طریق تونل، برای دیدن اینکه فلات وجود دارد یا نه کافی است.

توجه کنید فلات چه زمانی شروع می‌شود، چه مدت می‌ماند و چه سرعتی را نگه می‌دارد. این سه مقدار یک شکل‌دهنده را از مسیر شلوغ جدا می‌کند، چون ازدحام اجازه می‌دهد سرعت سرگردان شود، در حالی که شکل‌دهنده آن را به یک عدد میخکوب می‌کند. اگر اجرای مستقیم به‌تدریج بدتر شود و اجرای تونل پایدار بماند، شما به سیاست نگاه می‌کنید نه به فیزیک.

سه مقایسه، هر کدام با یک متغیر

در هر اجرا یک چیز را تغییر دهید، وگرنه چیزی یاد نمی‌گیرید. همان فایل را از مسیر وب معمولی بگیرید، سپس از طریق یک ابزار انتقال که از پورت دیگری استفاده می‌کند، از میزبان با ظرفیت مشابه و در همان ساعت. دستگاه مشتری را ثابت نگه دارید، چون لپ‌تاپی که بین شبکه‌ها جابه‌جا می‌شود متغیری اضافه می‌کند که نمی‌توانید کنترلش کنید.

curl -o /dev/null -w '%{speed_download}' https://files.example/big.iso
scp [email protected]:/exports/big.iso /dev/null

از فایلی استفاده کنید که از قبل فشرده شده، مثل تصویر دیسک، تا فشرده‌سازی انتقال نتواند تفاوت را توضیح دهد. سپس اگر سرور را کنترل می‌کنید، شنوندهٔ آن را به پورتی که گمان می‌برید محدود شده منتقل کنید، پروفایل مشتری را به‌روز کنید و تکرار کنید. اگر تونل اکنون به سرعت محدودشده افت کند، حد از پورت پیروی می‌کند نه از تونل، و مسئله حل می‌شود. هر مقایسه را دو بار اجرا کنید و ارقام فلات را نگه دارید، نه قله‌ها را.

ساعت را هم ثبت کنید، چون شکل‌دهنده می‌تواند زمانی باشد و آزمون عصر ممکن است با آزمون صبح هم‌خوانی نداشته باشد. دو اجرا در ساعت یکسان ارزش بیشتری از ده اجرای پراکنده در روز دارد.

این اندازه‌گیری از چه چیزی نمی‌تواند پشتیبانی کند

نشان نمی‌دهد که تونل به‌طور کلی سریع‌تر است، که چیزی را فشرده می‌کند یا که پورت‌های دیگر محدود نشده‌اند. یک انتقال روی یک خط در طول یک ساعت را توصیف می‌کند. محدودیت‌ها می‌توانند برای هر نشست، هر مشترک یا زمانی باشند و اپراتور می‌تواند آن‌ها را بدون اعلام تغییر دهد.

همچنین نشان نمی‌دهد که مسیر مستقیم معیوب است. مسیر محدودشده دقیقاً همان‌طور که مقصود است کار می‌کند، فقط با سیاست محدود شده است.

این تمایز وقتی آن را می‌نویسید مهم است. نقص یک بلیت تعمیر می‌خواهد، در حالی که سیاست یک پرسش دربارهٔ قرارداد یا تصمیم به دور زدن آن می‌خواهد. نامیدن یک سقف به‌عنوان نقص، گفتگوی پشتیبانی را از مقدمهٔ غلط شروع می‌کند. نامیدن آن به‌عنوان سیاست به شما اجازه می‌دهد پرسش مشخصی بپرسید که پاسخ مشخصی دارد.

یافته را به درخواست پشتیبانی تبدیل کنید

از اعداد استفاده کنید و نتیجه‌گیری را رها کنید. درخواستی که می‌گوید انتقال‌های بزرگ از پورت 80 در این ساعت‌ها حدود نیمی از سرعت انتظاری می‌مانند، همراه با ارقام فلات، قابل اقدام است. درخواستی که می‌گوید VPN سریع‌تر است، قابل اقدام نیست، چون به‌عنوان ادعایی دربارهٔ تونل خوانده می‌شود نه مشاهده‌ای دربارهٔ خط. هر دو اجرا و مهرهای زمانی‌شان را پیوست کنید و سپس بگذارید اپراتور سیاست را توصیف کند.

فقط برای دنبال کردن آن عدد، هر برنامه‌ای را به تونل هُل ندهید.

تونل هنوز یک پرش اضافه، رمزنگاری و مجموعهٔ تازه‌ای از حالت‌های خرابی به شما تحمیل می‌کند، در حالی که پورت محدود برای هر چیز دیگری که از آن استفاده می‌کند محدود می‌ماند. وقتی انتقال‌های بزرگ باید به‌طور قابل‌اعتماد تمام شوند، یادداشت خودتان را از اینکه کدام پورت حد را حمل می‌کند نگه دارید. انتقال یک شنونده به پورت 80 نیز با هر وب سروری که از قبل به آن مقید است برخورد می‌کند و این به‌جای اصلاح، یک قطعی تازه می‌سازد.

مقالات مرتبط