UDP وQUIC عبر الوكلاء

قد يجتاز خادم وكيل فحص ويب مع عجزه عن نقل حركة البيانات التي يحتاجها برنامجك. فمثلًا، قد تسجل لعبة الدخول عبر الوكيل لكنها تفشل في تبادل تحديثات اللعب. وقد يفتح موقع بصورة طبيعية بينما يستخدم المتصفح HTTP/2 بدل HTTP/3. فهذه العمليات تستخدم قدرات شبكة مختلفة.

للاختيار الأوسع للبروتوكول، انظر وكلاء SOCKS وHTTP. وتشرح هذه المقالة وصول UDP إلى الوجهة عبر وكيل، وما يحتاجه QUIC من ذلك المسار، وكيفية التحقق من استخدام تطبيقك وسيلة النقل وعنوان IP للخروج المقصودين.

وظائف UDP وQUIC وHTTP/3

يوصل TCP تدفق بايتات مرتبًا. وإذا ضاعت بيانات، يرتب إعادة إرسالها ويحجب البايتات اللاحقة عن التطبيق حتى يُسد النقص. ويرسل UDP رسائل منفصلة تسمى رزم بيانات. ولا يضمن UDP نفسه التسليم أو الترتيب أو الحماية من التكرار؛ بل يقرر البرنامج المستخدم له كيفية معالجة هذه الحالات.

يتيح ذلك للتطبيقات اختيار سلوك مختلف. فقد يتخلص تطبيق صوتي من رزمة وصلت متأخرة عن موعد تشغيلها. وقد تفضل لعبة تحديث موقع حديثًا على قديم. وقد يتكون تبادل DNS من سؤال وجواب قصيرين. وتعتمد وسيلة النقل الفعلية على البرنامج: فلا تعني هذه الأمثلة أن كل مكالمة أو لعبة أو طلب DNS يستخدم UDP.

QUIC بروتوكول نقل مبني على UDP. ويضيف إنشاء الاتصال واستعادة البيانات المفقودة والتحكم بالازدحام وتدفقات موثوقة. ويمكن لملف منقول عبر تدفق QUIC موثوق أن يصل كاملًا وبالترتيب. ولا يزيل انتقال رزمه داخل رزم UDP موثوقية QUIC.

يتيح QUIC أيضًا لعدة تدفقات مشاركة اتصال. وعند ضياع بيانات من تدفق، تستطيع التدفقات الأخرى التي وصلت بياناتها المتابعة. وقد يقلل ذلك الانتظار مقارنة بنقل كل التدفقات داخل اتصال TCP مرتب واحد. وتظل النتيجة معتمدة على المسار وفقدان الرزم والخادم والتطبيق العميل؛ ولا يضمن اختيار QUIC وحده تطبيقًا أسرع.

ينقل HTTP/3 بروتوكول HTTP عبر QUIC. ويستخدم HTTP/1.1 وHTTP/2 عادةً TCP. وتستطيع الثلاثة خدمة موقع HTTPS، لذا لا تحدد https:// في العنوان إصدار HTTP ولا تؤكد استخدام UDP.

التشفير خاصية منفصلة. فلا يشفر UDP البيانات. ويستخدم QUIC بروتوكول TLS 1.3 لإنشاء حماية لحركة بيانات التطبيق. وقد يستخدم تطبيق UDP عادي آلية أمان أخرى أو ينقل حمولته دون تشفير؛ ولا يضيف تمريرها عبر وكيل تلك الحماية تلقائيًا.

كيف ينقل SOCKS5 بيانات UDP

يعرّف SOCKS5 مُرحّل UDP: خدمة تقبل رزم البيانات من التطبيق العميل، وترسل حمولاتها إلى الوجهة، وتعيد الردود. ويرتب التطبيق العميل هذا التمرير أولًا عبر TCP. ثم يتواجد اتصال التحكم ومسار رزم البيانات جنبًا إلى جنب.

1. يتصل التطبيق العميل بخادم SOCKS5 عبر TCP ويكمل إجراء المصادقة المتفق عليه.
2. يطلب UDP ASSOCIATE. وإذا قبل الوكيل، يزود الرد عنوان المُرحّل ومنفذ UDP الخاص به.
3. يرسل التطبيق العميل رزم البيانات إلى المُرحّل برأس SOCKS يحدد الوجهة. ويزيل المُرحّل ذلك الرأس قبل تمرير الحمولة. وللردود، يضيف رأس SOCKS قبل إعادة رزمة البيانات إلى التطبيق العميل.
4. يبقي التطبيق العميل اتصال التحكم TCP مفتوحًا أثناء استخدام المُرحّل. ويؤدي إغلاقه إلى إنهاء تمرير UDP الذي رتبه ذلك الاتصال. ويسمى هذا الربط بين اتصال التحكم وتمرير UDP ارتباط UDP.

قد يستخدم المُرحّل عنوانًا أو منفذًا مختلفًا عن نقطة TCP المدخلة في إعدادات الوكيل. ولا ينفذ إرسال UDP خام إلى تلك النقطة المألوفة تبادل SOCKS5. ويستطيع عميل ينفذ CONNECT فقط استخدام SOCKS5 لTCP، لكنه يفتقر إلى الإجراء اللازم هنا. ولا يعرّف SOCKS4 إمكانية تمرير UDP هذه.

وهذا يفسر نجاحًا جزئيًا شائعًا: يسمح جدار الحماية باتصال TCP والمصادقة، لكنه يحظر رزم البيانات إلى المُرحّل المتفق عليه. فكلمة المرور تعمل، ومع ذلك لا يتلقى التطبيق ردود UDP. ويجب إتاحة جزأي المسار.

هل يستطيع وكيل HTTP تمرير UDP؟

يطلب HTTP CONNECT العادي من الوكيل فتح اتصال TCP بالوجهة ونقل تدفق بايتات. ولا ينشئ تمرير UDP. ويحمي استخدام TLS للاتصال بوكيل HTTPS ذلك الاتصال دون تغيير نوع النفق المطلوب.

لHTTP آلية إضافية لإنشاء نفق UDP، تسمى عادةً CONNECT-UDP وطُورت ضمن MASQUE. ومع تطبيق عميل وخادم متوافقين، يطلب التطبيق العميل نفقًا إلى وجهة UDP. ويمرّر الوكيل رزم البيانات إلى تلك الوجهة وينقل الردود عائدًا. ويتطلب ذلك دعمًا صريحًا من الطرفين.

على الاتصال من التطبيق العميل إلى الوكيل، يمكن نقل HTTP Datagrams ضمن إطارات QUIC DATAGRAM عند دعم HTTP/3 والامتدادات المطلوبة. ويمكن أيضًا نقلها في كبسولات: رسائل مؤطّرة داخل تدفق HTTP موثوق، بما في ذلك HTTP/2 عبر TCP. وحينها يظل الوكيل يرسل UDP إلى الوجهة مع أن الجزء الأول من المسار يستخدم TCP.

يؤثر ذلك الاختيار في التوقيت. فإذا فقد اتصال TCP بيانات، فقد تنتظر البايتات اللاحقة استعادتها، فتتأخر رزم البيانات المنقولة داخلها. وقد يعمل النفق لكنه لا يناسب حمل عمل معينًا في الوقت الحقيقي. ومجرد إدخال عنوان وكيل http:// في برنامج لا يفعّل أيًا من آليات UDP الإضافية هذه.

أي اتصال يستخدم QUIC؟

تحتاج عبارة «وكيل QUIC» إلى سياق. فقد تصف وسيلة النقل المستخدمة للوصول إلى الوكيل، أو اتصال التطبيق بالوجهة. وهذان جزآن منفصلان من التبادل.

في تمرير UDP العادي، لا يحتاج الوكيل إلى إنهاء اتصال QUIC الخاص بالتطبيق. فهو يمرّر الرزم بينما يبقى التطبيق والوجهة طرفي ذلك التبادل المشفر. ويظل الوكيل يعرف إلى أين يمرّر البيانات، ويستطيع ملاحظة حجمها وتوقيتها.

لماذا يهم دعم التطبيق

يحتاج البرنامج إلى تنفيذ طريقة التمرير التي توفرها الخدمة. ولا يكشف مربع اختيار SOCKS5 ما إذا كان يدعم UDP ASSOCIATE. وكذلك قد يدعم برنامج HTTP/3 للاتصالات المباشرة مع توفير اتصالات وكيل TCP فقط.

يقدم Chrome مثالًا محددًا: فدعم SOCKS5 المدمج فيه يمرّر طلبات URL القائمة على TCP، ولا يمرّر UDP عبر SOCKS5. ولا يستطيع تحميل صفحة بذلك الإعداد اختبار مُرحّل UDP الخاص بالخدمة. ويخص هذا القيد وضع العميل المحدد؛ وقد تكون لعملاء آخرين أو برامج توجيه خارجية قدرات مختلفة.

تحقق من نطاق الإعداد أيضًا. فقد يستخدم تسجيل الدخول وتنزيل الملفات والصوت واللعب مكونات شبكة مختلفة داخل تطبيق واحد. وقد يغطي وكيل مضبوط لطلبات الويب بعضها فقط. ويعتمد إعداد وكيل النظام أيضًا على التزام كل برنامج به.

يستطيع برنامج يعيد توجيه حركة بيانات تطبيق آخر إرسال UDP الخاص به عبر وكيل، بشرط دعمه UDP وطريقة التمرير لدى الخدمة. ولا تكفي إعادة توجيه TCP وحده. وإذا استخدم البرنامج واجهة شبكة افتراضية، تقرر قواعد التوجيه أي البيانات تدخلها. اختبر التركيبة كاملة: التطبيق وبرنامج التوجيه ونقطة اتصال الوكيل.

الرجوع إلى بديل والفشل والاتصال المباشر

عند تعذر المسار المطلوب، تعتمد النتيجة على قدرات التطبيق وسياسته. وقد تبدو ثلاث نتائج متشابهة إذا كان السؤال الوحيد هو ما إذا كان شيء ما قد فُتح:

يسمى الانتقال إلى إصدار HTTP قائم على TCP رجوعًا إلى بديل. وقد يحافظ على التصفح العادي عند تعذر QUIC. ويفتح التطبيق العميل اتصالًا مختلفًا؛ فلا يتحول QUIC نفسه إلى TCP. لذلك قد يساعد تعطيل QUIC تطبيق ويب على استخدام مسار TCP متاح، لكنه لا يوفر UDP لميزة تتطلبه.

الذهاب مباشرةً إلى الوجهة قرار توجيه. ولا يُرسل UDP غير المدعوم مباشرةً في كل البرامج: فقد يتوقف البرنامج أو يجرب نقلًا آخر أو يتبع قاعدة تجاوز مضبوطة. وإذا وجب مرور كل بيانات المهمة عبر الوكيل، فاستخدم وضعًا يتوقف عند فشل ذلك المسار، وافحص سلوكه عند تعذر الوكيل.

لماذا قد يتوقف UDP عن العمل بعد الإعداد

قواعد المنافذ ومسار العودة

ينتمي منفذ TCP 443 ومنفذ UDP 443 إلى وسيلتي نقل مختلفتين. ولا يفتح السماح بأحدهما الآخر. وفي SOCKS5 يجب أن يصل التطبيق العميل إلى نقطة مُرحّل UDP المعادة، وأن يُسمح للمُرحّل بالوصول إلى منفذ UDP للوجهة أيضًا. وقد يستخدم HTTP/3 منافذ غير 443، فتحقق من نقطة الاتصال التي يستخدمها التطبيق فعليًا.

يجب أن تعود الردود عبر المُرحّل وجدار الحماية وأي NAT، الذي يترجم العناوين وغالبًا المنافذ بين الشبكات. ولا يثبت إرسال رزمة بيانات وحده عمل مسار العودة. وقد يغيّر الانتقال الشبكي عنوان IP العام للتطبيق العميل أو ربط المنفذ. ويُلزم مُرحّلو SOCKS5 برفض رزم البيانات القادمة من عنوان IP مصدر غير المسجل لارتباط UDP ذاك، لذا قد يستلزم تغير العنوان ارتباطًا جديدًا.

التوقفات والحالة المنتهية

تحتفظ المُرحّلات وأجهزة NAT بسجلات مؤقتة لتبادلات UDP. وقد تنتهي تلك السجلات خلال توقف. وقد تعمل مكالمة أو جلسة أولًا، ثم تفقد مسار UDP حتى يعيد التطبيق العميل إعداده. ولا يمنع الاحتفاظ بعنوان IP للخروج نفسه ذلك: فالحالة اللازمة لتمرير UDP وتخصيص IP لدى الخدمة أمران منفصلان.

حجم رزمة البيانات وMTU

MTU أكبر رزمة IP تستطيع وصلة شبكة نقلها دون تجزئة. ويحد أصغر حد من هذا النوع على المسار الحجم القابل للاستخدام، ويسمى MTU المسار. وتشغل رؤوس IP وUDP والأنفاق الإضافية كلها مساحة في الرزمة. وقد تمر رسالة اختبار صغيرة بينما تُسقط رزم أكبر، لذا يجب أن يراعي التطبيق المسار الكامل والرؤوس المضافة إليه.

يجب أن ينقل مسار QUIC حمولة UDP لا تقل عن 1,200 بايت، دون حساب رأسي IP وUDP. ويحشو التطبيق العميل رزم UDP الحاملة لرزم QUIC Initial الخاصة به إلى حجم الحمولة الأدنى هذا على الأقل. وتحتاج رؤوس الوكيل في الجزء من التطبيق العميل إلى الوكيل مساحة إضافية. وليست هذه توصية بضبط MTU واجهة على 1,200: بل يفسر ذلك إمكان نجاح طلب DNS صغير وردّه بينما تتعذر مصافحة QUIC الأكبر.

التأخير والفقدان والحمل

للمكالمة أو اللعبة، قد يهم وقت التسليم بقدر التسليم نفسه. وقد يضعف تغير التأخير وفقدان الرزم وحدود معدل الرزم مُرحّل UDP يعمل من جوانب أخرى. ولا يصف عرض النطاق وحده هذه الظروف. ويضيف الوكيل جزءًا آخر إلى المسار؛ وقد يغيّر الأداء إلى الأفضل أو الأسوأ بحسب الشبكات وحمل العمل.

كيفية التحقق من UDP وHTTP/3 عبر وكيل

اختبر التطبيق الذي تنوي استخدامه، أو عميلًا ينفذ طريقة التمرير نفسها. ويتحقق الاختبار المفيد من الرد ووسيلة النقل وعنوان الخروج للتبادل نفسه.

1. اختر وجهة تجيب على حركة البيانات المطلوبة. استخدم خادم التطبيق الفعلي أو مستجيب UDP تتحكم فيه. ولHTTP/3 اختر وجهة معروفة بدعمه. ولا يبين الصمت من منفذ UDP عشوائي أي جزء فشل.
2. أكد قبول المُرحّل أو النفق. في SOCKS5، افحص نتيجة UDP ASSOCIATE وعنوان المُرحّل ومنفذه المعادين. ومع نفق HTTP UDP، أكد قبول ذلك النفق. ولا تشمل المصادقة وحدها هذه الخطوة.
3. أكمل طلبًا وردًا. ويمكن لمستجيب تتحكم فيه إعادة معرّف طلب وتسجيل عنوان IP المصدر الذي رآه. ويتحقق ذلك من نقطة الخروج المستخدمة لتبادل UDP ذاك. أما فحص IP ويب منفصل فيغطي طلبه الخاص فقط.
4. لHTTP/3، أكد البروتوكول في التبادل مع الوجهة. وابحث عن HTTP/3 أو h3 في سجل اتصال التطبيق العميل أو الخادم، مع دليل على مسار الوكيل. وإذا كان للعميل المختبر وضع HTTP/3 فقط، فقد يكشف فشلًا كان الرجوع التلقائي إلى بديل سيخفيه.
5. كرر الاختبار في ظروف ذات صلة: أحجام رزم بيانات واقعية، وحركة مستمرة، وتوقف يعقبه نشاط. وإذا حُظر النقل المباشر للمهمة، فاختبر أيضًا ما يحدث عند تعذر الوكيل. واحتفظ بإصدار العميل وإعدادات الاتصال مع النتيجة.

قد يساعد التقاط الرزم على تحديد المسار. ويرسل تمرير SOCKS5 UDP القياسي رزم البيانات إلى المُرحّل المتفق عليه. وقد يستخدم نفق HTTP UDP بدلًا من ذلك اتصال TCP خارجيًا، لذا لا يكفي غياب UDP في الجزء الأول من المسار دليلًا على الفشل.

يختبر DNS البعيد وping أمرين مختلفين. فقد يبحث الوكيل عن عنوان اسم مضيف لاتصال TCP دون تمرير حركة UDP الخاصة بالتطبيق. ويستخدم ping العادي ICMP. ولا يحل أي من الاختبارين محل طلب UDP ورد عليه يُلاحظان على مسار الوكيل المقصود.

متى يستحق دعم UDP الاختيار

ابدأ بحركة البيانات التي تتطلبها مهمتك. فقد يلبي وكيل TCP فقط عمل المواقع وواجهات API الذي يعمل عبر HTTP/1.1 أو HTTP/2 بالكامل. أما اختبار HTTP/3 ووسائط UDP والميزات الأخرى المعتمدة على UDP فتحتاج إلى مُرحّل أو نفق مناسب، وعميل يستطيع استخدامه.

اسأل الخدمة عن طريقة تمرير UDP وإعداد العميل المدعومين. ثم افحص الوجهات والمنافذ المسموح بها وحدود حجم رزم البيانات وسلوك الخمول وأي حدود لحركة البيانات أو معدل الرزم تتعلق بحمل العمل. وإذا وجب استخدام TCP وUDP عنوان IP للخروج أو موقعًا واحدًا، فتحقق من ذلك في التطبيق الفعلي. ولا يثبت الحساب المشترك أو نجاح فحص ويب تطابق سلوك الخروج.