CONNECT-TCP يمنح النفق عنواناً، وعلى البوابات اللحاق به

الخلاصة

عندما يمر اتصال TCP عبر وكيل، يحدد CONNECT التقليدي الجهاز والمنفذ المقصودين، لكنه لا يحدد خدمة الوكيل التي ستفتحه. يضيف CONNECT-TCP عنواناً ومساراً واضحين لتلك الخدمة.
وافق IESG في 30 أكتوبر على نشر المسودة بوصفها Proposed Standard. لا يحدّث القرار البوابات؛ فعلى كل بوابة نقل النفق بين إصدارات HTTP التي تدعمها. ولا تنشر الوثائق أعداد التثبيت أو نتائج التشغيل الفعلي.

حين يطلب العميل من وكيل فتح اتصال TCP، يعرف الوكيل الوجهة. لكن خادم HTTP الذي يستضيف خدمات عدة لا يملك في الطلب القديم اسماً يحدد أي خدمة وكيل ستتولى الاتصال. CONNECT-TCP يضيف للوكيل أصلاً ومساراً يحددان هذه البوابة بوضوح.

يتيح HTTP CONNECT للعميل أن يطلب من وكيل فتح اتصال TCP بمضيف ومنفذ محددين، ثم ينقل الوكيل البيانات إلى الوجهة. الاقتراح الجديد يفصل بين سؤالين: أين يذهب النفق، وأي خدمة وكيل تفتحه؟ هذا الفصل يساعد الخادم على توجيه الطلب وتحديد نطاق ترويسات مثل Alt-Svc وStrict-Transport-Security. وتشير المسودة أيضاً إلى أن الأصل الصريح يدعم وسائل الحماية من توجيه الطلب إلى منفذ خاطئ على الخادم.

والبوابة بين إصدارات HTTP تدخل في صلب الحكاية: ينبغي أن تحمل طلب CONNECT-TCP وتحافظ على وجهته وهي تنقله بين HTTP/1.1 وHTTP/2 وHTTP/3. لذلك لا ينتهي العمل عند خادم الوكيل؛ بل يصل إلى كل وسيط في الطريق.

في 30 أكتوبر، وافق IESG على نشر draft-ietf-httpbis-connect-tcp بوصفها Proposed Standard. وصدرت النسخة 17 في اليوم السابق. تقترح المسودة طريقة جديدة لنقل TCP عبر HTTP؛ ولا تحدد الوجهات التي يحق للمستخدم الوصول إليها. صار عنوان نقطة الوكيل أوضح، بينما يظل قرار الإذن لدى مشغّل الوكيل.

تعرّف المسودة خدمة الوكيل بقالب URI يحتوي target_host وtarget_port. يملأ العميل الوجهة ويرسل URI الناتج إلى الوكيل. في HTTP/1.1 يستخدم GET ثم يرقّي الاتصال إلى connect-tcp. وفي HTTP/2 وHTTP/3 يستخدم Extended CONNECT مع ضبط :protocol على connect-tcp. ويعلن الوكيل في إعداداته إن كان يدعم Extended CONNECT.

ينتقل تدفق TCP داخل رسائل Capsule Protocol. تحمل DATA البايتات، وتحمل FINAL_DATA البايتات الأخيرة وتشير إلى إغلاق يماثل TCP FIN. لا تحاول حدود الكبسولات تقليد مقاطع TCP أو سجلات TLS؛ إنها تغليف للتدفق أثناء مروره عبر HTTP.

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

وتصل الفاتورة إلى البوابات. على البوابة التي تعد بالتوافق أن تتعامل مع Upgrade في HTTP/1.1 أو Extended CONNECT، وأن تمرر connect-tcp وتحول الطلبات بين إصدارات HTTP التي تدعمها. وعليها تمرير Proxy-Status أيضاً. إذا كان الخادم الأصلي يتحقق من المستخدمين بشهادات TLS للعميل، فعلى البوابة إجراء التحقق أو تمرير معلومات الشهادة إلى الخادم.

كتبت IETF شروط التسليم في المتطلبات، لكنها لم تحدّث البوابات. لا تتضمن المسودة ولا سجل القرار عدد البوابات المنشورة أو توقعاً للتبني أو نتائج توافق في التشغيل الفعلي. يستطيع المعيار تثبيت شكل الرسالة؛ لكن على المشغّلين حصر كل وكيل وبوابة وحدّ للمصادقة على المسار.