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

ترابری واقعاً چه چیزی را تغییر می‌دهد

TCP جریانی مطمئن و مرتب از بایت‌ها ارائه می‌دهد و هر چه از دست برود را دوباره می‌فرستد، همان‌طور که RFC 9293 مشخص می‌کند. UDP داده‌گرام‌ها را به شبکه می‌سپارد و OpenVPN لایهٔ اطمینان خودش را روی آن سوکت اجرا می‌کند. کپسوله‌کردن TCP در TCP دو حلقهٔ بازیابی را روی هم می‌چیند، بنابراین یک بخش گمشده می‌تواند جریان درونی را نگه دارد تا وقتی ارسال مجدد بیرونی برسد. همین تعامل استدلال واقعی برای UDP است و به‌صورت تأخیر ظاهر می‌شود، نه به‌صورت توان عبوری.

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

هیچ‌کدام از این‌ها به محرمانگی یا یکپارچگی مربوط نیست. دست‌دادن TLS و رمز کانال داده برای هر دو ترابری یکی است، پس جابه‌جایی نمی‌تواند مجموعهٔ رمز ضعیف را نجات دهد.

کجا TCP جای خود را به دست می‌آورد

شبکه‌های دسترسی دلیل معمول انتخاب TCP هستند. یک هتل، فرودگاه یا شبکهٔ مهمان ممکن است 443 خروجی را مجاز کند و بقیه را دور بریزد، و شنوندهٔ TCP روی آن پورت تنها نمایه‌ای است که کار می‌کند. این دسترس‌پذیری است نه کارایی، و به‌تنهایی دلیل به‌قدر کافی خوبی است.

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

ورود ردشده مشکل ترابری نیست. غیرفعال‌کردن بررسی گواهی برای عبور دادن اتصال تغییری دیگر با نتیجه‌ای بسیار بدتر است.

آماده نگه‌داشتن یک نمایهٔ TCP سازش عملی است. بیشتر کارخواه‌ها هر دو را ذخیره می‌کنند و می‌گذارند وقتی شبکه مسیر UDP را رد کرد جابه‌جا شوید، که تا وقتی لازمش ندارید هیچ هزینه‌ای ندارد. کاری که نباید بکنید این است که دو نمایه با نقاط پایانی متفاوت ارائه دهید، چون آن‌وقت مقایسهٔ شما سرورها را اندازه می‌گیرد.

بررسی کنید واقعاً کدام شنونده را دارید

پیش از مقایسهٔ کارایی تأیید کنید که دو طرف در مورد ترابری و پورت هم‌نظرند. تغییر proto udp به proto tcp در فایل کارخواه شنونده‌ای روی سرور ایجاد نمی‌کند. سرور باید برای آن پروتکل پیکربندی شده باشد و نمایه باید با آن بخواند.

grep -E '^(proto|port|remote)' /etc/openvpn/server.conf
ss -lunp | grep openvpn
ss -ltnp | grep openvpn

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

تأیید سمت کارخواه ارزان است: اتصال را با --verb 4 اجرا کنید و خط ترابری را در گزارش بخوانید. اگر کارخواه UDP می‌گوید در حالی که سرور روی TCP گوش می‌دهد، دست‌دادن هرگز شروع نمی‌شود و هیچ تنظیمی کمکی نمی‌کند.

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

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

برای هر اجرا سه نتیجه ثبت کنید: اینکه تونل برقرار می‌شود، پایدار می‌ماند و کار کامل می‌شود. درخواست‌های کوچکی که کار می‌کنند در حالی که انتقال‌های بزرگ گیر می‌کنند به اندازهٔ بسته و MTU اشاره دارند، نه به ترابری. اتصال‌های مکرر به مسیر یا به مهلت یک دستگاه میانی اشاره دارند.

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

مقالات مرتبط