كيف يمكن لمنفذ وكيل واحد أن يستقبل HTTP وSOCKS معًا
شرح كيف يمكن لمستمع مختلط عن قصد أن يميز بين HTTP وSOCKS، بينما لا يستطيع مستمع عادي ببروتوكول واحد ذلك.
يمكن للمستمع الوكيل المختلط استقبال HTTP وSOCKS على منفذ TCP واحد لأن الخادم يفحص بايتات البروتوكول الأولية. رقم المنفذ لا يقوم بهذا التمييز.
يبدأ طلب وكيل HTTP بطريقة HTTP، مثل GET أو CONNECT. تبدأ تحية SOCKS بحقول بروتوكول ثنائية. البرمجيات المصممة لهذه المدخلات يمكنها توجيه الاتصال إلى المعالج المناسب.
هذه ميزة تنفيذ صريحة. مستمع Squid HTTP العادي لا يصبح مختلطًا لأن منفذه غُيّر إلى 1080، ومستمع SOCKS فقط لا يتعلم HTTP من إعداد المتصفح.
يضيف TLS حدًا آخر: اتصال الوكيل المشفر يبدأ بـ TLS، لا بطريقة HTTP مرئية. دعمه على نفس نقطة النهاية يتطلب معالجة إضافية متعمدة؛ والتعرف على HTTP وSOCKS النصيين لا يثبت تلك القدرة.
استخدم بروتوكول العميل الموثق لنقطة النهاية. إذا نجح كلاهما، فذلك دليل على المستمع المختلط لذلك الخادم، وليس سببًا لترك البروتوكول غير محدد في كل عميل.
يقدم مستمع Glider المختلط مثالًا ملموسًا: فهو ينظر إلى بايت واحد دون استهلاكه، ويرسل 0x05 إلى معالج SOCKS5، وإلا يستدعي محلل HTTP الخاص به. لا يزال ذلك المحلل يتحقق من الطلب الوارد؛ اختيار التوجيه لا يجعل المدخلات العشوائية HTTP صالحًا.
مشاركة مستمع TCP لا توفر بحد ذاتها اقتران UDP في SOCKS5. يبدأ Glider مستمع UDP الخاص به بشكل منفصل. اختيار بروتوكول TCP وترحيل مخططات البيانات اللاحق قدرتان منفصلتان.