ترجمة طلب SOCKS5 إلى نفق HTTP

يمكن لواجهة SOCKS5 الأمامية أن تستخدم وكيل HTTP كوسيلة نقل لاحقة. فهي تعمل كخادم SOCKS تجاه العميل، وكعميل HTTP CONNECT تجاه الأب. ينتهي تبادلا التحكم قبل أن يبدأ تدفق التطبيق.

يوفّر طلب SOCKS CONNECT مسبقًا المضيف الوجهة أو العنوان والمنفذ. ولغرض التوضيح، تبادل HTTP/1.1 مع الأب:

client → adapter: SOCKS5 CONNECT service.example.net:443
adapter → parent:
    CONNECT service.example.net:443 HTTP/1.1
    Host: service.example.net:443

parent → adapter: HTTP/1.1 200 Connection Established
                 [end of headers]
adapter → client: SOCKS5 success reply

client ↔ adapter ↔ parent ↔ service: application bytes

ترجم النتيجة عند الحد

يُكمل المحوّل أي مصادقة مطلوبة عند الأب وينتظر نتيجة CONNECT. يستقرئ رد ناجح من فئة 2xx نفق الأب. وعندئذ فقط ينبغي أن يعيد رد النجاح المقابل بصيغة SOCKS إلى العميل الأدنى.

وإذا رفض الأب العملية، فأرسل رد فشل SOCKS محددًا، ثم أنهِ اتصال العميل فورًا. يشترط SOCKS5 أن يتم ذلك الإغلاق خلال عشر ثوانٍ من اكتشاف الفشل. أبقِ حالة HTTP الخاصة بالأب كمعلومة تشخيصية للمحوّل. أما تمرير سطر الحالة ذلك كبيانات تطبيق فسيضع رسالة تحكم HTTP داخل تدفق يتوقع عميله تأطير SOCKS.

قبل نتيجة CONNECT الناجحة، لا يزال الأب يتحدث HTTP، بما في ذلك تأطير أي رد تحدٍّ أو خطأ. وبعد فاصل ترويسات النتيجة الناجحة يصبح الاتصال هو النفق؛ ولا يوجد جسم استجابة HTTP يُستهلك أولًا.

احفظ البايتات التي تلي الترويسات

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

بعد إرسال رد نجاح SOCKS، مرّر تدفق التطبيق في الاتجاهين. لا يحتاج المحوّل إلى تبادل رسالة عميل واحدة برسالة خادم واحدة، ولا يحتاج إلى فهم سجلات TLS لتمريرها. كان عملُه البروتوكولي هو إنشاء تفاوضي النفق وترجمتهما.