أنفاق HTTP CONNECT عبر مأخذ Java في OpenJDK 25

يمكن لبروتوكول TCP مخصص أن ينتقل عبر وكيل HTTP عندما يسمح ذلك الوكيل بـ CONNECT إلى الوجهة. ولا يلزم أن يتحول بروتوكول التطبيق إلى HTTP: فـ HTTP ينشئ النفق، ثم يتبادل التطبيق بايتاته الخاصة داخله.

يوفر OpenJDK 25 مسارًا عبر وكيل HTTP في Socket(Proxy). ويقوم تنفيذه بإجراء تبادل CONNECT ويعيد مأخذًا موصولًا يستخدمه التطبيق.

Proxy route = new Proxy(
    Proxy.Type.HTTP,
    new InetSocketAddress("proxy.example", 8080));

try (Socket socket = new Socket(route)) {
    socket.setSoTimeout(10000);
    socket.connect(
        InetSocketAddress.createUnresolved("tcp-service.example", 8443),
        5000);
    InputStream input = socket.getInputStream();
    OutputStream output = socket.getOutputStream();
}

تستخدم هذه القطعة أصنافًا من java.net وjava.io. استبدل نقطتي النهاية ونفّذ تبادل البروتوكول قبل مغادرة كتلة try. ولهدف TCP عام مسموح به، اختر مرشحات HTTP من قائمة وكلاء HTTP فقط بعد التحقق من إذن CONNECT لمنفذ ذلك الهدف. عنوان الوكيل هو المكان الذي يتصل به Java أولًا؛ أما العنوان الذي يُمرَّر إلى connect فيحدد الخدمة التي يجب أن يصل إليها الوكيل.

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

ما يتركه لك اتصال ناجح

تحمل التدفقات الناتجة بيانات الخدمة المنفَّقة. وهي لا تعرض استجابة HTTP منفصلة ينبغي لتطبيقك قراءتها وتجاهلها. وإضافة تبادل CONNECT ثانٍ سترسل نص HTTP إلى الخدمة بعد أن يكون JDK قد أنشأ النفق بالفعل.

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

لا يزال إذن CONNECT ملكًا للوكيل. فقد ترفض نقطة نهاية تمرر طلبات ويب عادية منفذ الخدمة أو تطلب مصادقة قبل فتح نفق. اجعل تلك الإخفاقات منفصلة عن خادم يقبل النفق ثم يرفض بروتوكول تطبيقك لاحقًا.

إذا احتاج ذلك البروتوكول إلى TLS، فتفاوض على TLS عبر المأخذ الموصول باستخدام اسم المضيف المقصود للخدمة وفحوص الشهادات المعتادة. فـ CONNECT وحده لا يشفر التدفق. وبالنسبة لواجهة HTTP API فعلية، يظل عميل HTTP الواجهة الأكثر ملاءمة لأنه يتعامل أيضًا مع رسائل HTTP.