IP ثابت GCP در برابر سرعت VPN: سه متغیر، یک آزمون

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

نشانی رزروشده در واقع چه چیزی می‌خرد

Compute Engine نشانی‌های زودگذر را که همراه نمونه تخصیص و آزاد می‌شوند، از نشانی‌های ثابتی که رزرو می‌کنید و نگه می‌دارید جدا می‌کند. این تفاوت درباره نگه‌داشت و صورت‌حساب است، نه مسیری که بسته می‌پیماید. نقطه پایانی پایدار برای رکوردهای DNS، نمایه‌های دسترسی از راه دور، فهرست‌های مجاز شرکا و قواعد فایروال که نباید با راه‌اندازی دوباره VM تغییر کنند، واقعاً سودمند است.

این‌ها دلایل خوبی برای رزرو یکی هستند. هیچ‌کدام دلیل توان عبوری نیست.

لایه، نشانی و انتقال را سه متغیر نگه دارید

Google Cloud همچنین لایه‌های سرویس شبکه Premium و Standard را می‌فروشد و هر دو مسیرهای متفاوتی به اینترنت با دسترسی متفاوت به امکانات طی می‌کنند. نشانی‌دهی ثابت به هر دو عمود است، پس ثابت و Premium را واقعیت‌های نامرتبط درباره یک VM بدانید، نه مترادف. لایه واقعی، منطقه و هر اتصال یا پیوست در کار را ثبت کنید، چون آن‌ها مسیر را به گونه‌ای توصیف می‌کنند که برچسب نشانی هرگز نخواهد کرد.

سه متغیر، سه آزمایش جداگانه، وگرنه نتیجه یک روایت است نه یک اندازه‌گیری.

آزمونی طراحی کنید که به یک پرسش پاسخ دهد

VM، نشانی، مکان کلاینت، مقصد و بار کاری را ثابت نگه دارید و در همان حال نمایه‌های تأییدشده UDP و TCP را مقایسه کنید. هم شنونده سرور برای هر انتقال و هم قواعد فایروال متناظر لازم است؛ ویرایش یک کلیدواژه در کلاینت و بی‌تغییر گذاشتن شنونده فقط صبر شما را می‌آزماید. از انتقالی تکرارپذیر استفاده کنید و جهت، مدت، جریان‌های تک و موازی و واحدها را ثبت کنید، چون MB/s و Mb/s هشت برابر تفاوت دارند.

پردازنده VM را هم زیر نظر بگیرید، چون نمونه کوچک در رمزگذاری یا کار softirq بسیار پیش‌تر از شبکه اشباع می‌شود و آن سقف دقیقاً شبیه محدودیت ارائه‌دهنده دیده خواهد شد.

شمارنده‌های ارسال دوباره و افت از VM و کلاینت مشکل مسیر را از مشکل انتقال جدا می‌کنند و نوار پیشرفت نمی‌تواند. یک توالی کارآمد با iperf3 حدود ده دقیقه برای هر انتقال طول می‌کشد. سرور را در سمت دور راه بیندازید، کلاینت را سی ثانیه در هر جهت اجرا کنید و هر جهت را سه بار تکرار کنید. نخستین اجرای هر سری را کنار بگذارید، سپس نرخ فرستنده و گیرنده را همراه با شمار ارسال دوباره که اجراهای TCP چاپ می‌کنند مقایسه کنید.

چرا UDP و TCP از نظر مکانیکی متفاوت‌اند

OpenVPN روی UDP داده‌نگارها را حمل می‌کند و رسیدگی به افت را به انتقال خود برنامه می‌سپارد. روی TCP، جریان مطمئن تونل زیر جریان از پیش مطمئن برنامه می‌نشیند، پس یک قطعه گمشده هر چیزی را که پشت آن است متوقف می‌کند، در حالی که اتصال بیرونی طبق زمان‌بندی خودش دوباره می‌فرستد. این رفتار سر صف ویژگی تونل‌کردن TCP درون TCP است، نه سیاست ارائه‌دهنده. رسیدگی به MTU و MSS هم میان دو حالت متفاوت است و این رفتار قطعه‌بندی را در همان مسیر تغییر می‌دهد.

بنابراین یک آزمون سریع‌تر TCP فقط ثابت می‌کند که TCP آن روز در آن مسیر سریع‌تر بود، و هیچ چیز کلی‌تری.

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

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

پایداری نشانی و سرعت انتقال هر دو می‌توانند برای یک استقرار مهم باشند، و تصمیم سودمند این است که با هر تغییر کدام یک را می‌خرید.