لا يكون UDP دائمًا أسرع: كيف تختار ناقل OpenVPN

كل دليل يقول إن UDP يتفوق على TCP مع OpenVPN، وهذه النصيحة افتراض وليست قياسًا. يغيّر الناقل طريقة تسليم الحزم وما يحدث عندما يهدرها المسار، لا طريقة تشفير النفق. خلف بوابة مقيدة أو وكيل يسمح بالمنفذ 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 لا إلى الناقل. أما إعادة الاتصال المتكررة فتشير إلى المسار أو إلى مهلة وسيط.

احتفظ بملف التعريف الذي يعمل في الظروف التي تواجهها فعلًا، واحتفظ بالآخر محفوظًا. الاختيار يخص الشبكة لا الشخص، ولهذا فإن أي جواب افتراضي واحد خاطئ في مكان ما.