وكلاء SOCKS وHTTP: الفروق والسرعة واختيار البروتوكول

يربط وكلاء HTTP وSOCKS التطبيق بالوجهة عبر خادم وسيط. وللمتصفح أو برنامج جمع البيانات أو عميل API، يعد وكيل HTTP الذي يدعم CONNECT نقطة بداية عملية. ويفيد SOCKS5 عندما يتوقع التطبيق SOCKS أو يحتاج إلى بروتوكولات TCP أخرى أو يدعم تمرير UDP. ويمكن لكليهما نقل البيانات إلى مواقع HTTPS.

يحدد البروتوكول كيفية تواصل البرنامج مع الوكيل. أما مصدر عنوان IP للخروج والتدوير والوصول المشترك أو المخصص فهي اختيارات منفصلة يشرحها دليل أنواع الوكلاء واختيار الإعداد. ولا يغيّر الانتقال من HTTP إلى SOCKS أيًا من تلك الخصائص بحد ذاته.

كيف يتعامل HTTP وSOCKS مع الاتصال

تمرير HTTP: يعالج الوكيل طلب ويب

في طلب HTTP عادي غير مشفر، يرسل التطبيق العميل إلى الوكيل عنوان URL المستهدف والطريقة والرؤوس. ويعالج الوكيل الطلب ويحصل على الاستجابة من الوجهة. ويمكنه تطبيق قواعد HTTP أو تغيير الرؤوس أو استخدام ذاكرة مؤقتة إذا ضُبط لذلك. وهذه وظائف محتملة لوكيل HTTP؛ ولا تفعّل الخدمة جميعها بالضرورة.

SOCKS5: يفتح الوكيل اتصالًا للتطبيق

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

HTTPS عبر CONNECT: يتقارب الأسلوبان

عند فتح موقع HTTPS عبر وكيل HTTP تقليدي، يرسل التطبيق العميل عادةً طلب CONNECT. وبعد قبول الوكيل للنفق، ينشئ التطبيق TLS مع الموقع داخله. ويمرّر الوكيل البيانات المشفرة. ويمكن لSOCKS5 تمرير تبادل TLS نفسه بعد إتمام إعداده الخاص.

يهم ذلك عند مقارنة السرعة والخصوصية: فوكيل HTTP الذي ينقل HTTPS داخل نفق لا يحلل كل طلب صفحة مشفر. وكلا النوعين يمرّر البيانات المحمية. وتشرح مقالة وكلاء HTTP وHTTPS التسلسل والفرق بين تمرير HTTP وإنشاء الأنفاق.

نظرة سريعة على HTTP وSOCKS5

تستخدم المقارنة التالية SOCKS5. أما SOCKS4 وSOCKS4a الأقدم فلهما قدرات أقل، وتبرز أهميتهما حين تتطلبهما البرامج الموجودة.

أيهما أسرع: HTTP أم SOCKS5؟

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

الاتصالات الجديدة: عدّ التبادلات

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

لذلك يضيف SOCKS5، وفق هذه الافتراضات، دورة ذهاب وإياب واحدة بين التطبيق العميل والوكيل دون مصادقة، أو دورتين مع المصادقة القياسية باسم المستخدم وكلمة المرور. ودورة الذهاب والإياب، أو RTT، هي زمن انتقال رسالة إلى الوكيل وعودة ردها. وعند RTT توضيحي قدره 50 ms، تضيف تلك التبادلات نحو 50 أو 100 ms. وهذا تقدير من تسلسل البروتوكول، وليس قياسًا مرجعيًا لخدمة وكلاء أو الزمن الإجمالي للطلب.

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

الاتصالات المعاد استخدامها: يتوزع الفرق الأولي على الطلبات

تُبقي مجموعة الاتصالات الاتصالات المناسبة متاحة للطلبات اللاحقة. وتتجنب إعادة استخدام اتصال HTTPS تكرار TCP والتفاوض مع الوكيل ومصافحة TLS للموقع لكل طلب. ومع دعم HTTP/2 لدى التطبيق العميل والوجهة، تستطيع عدة تدفقات طلبات مشاركة اتصال قائم واحد. ويعمل ذلك داخل نفق HTTP CONNECT أو اتصال SOCKS5؛ ولا يحتاج الوكيل إلى تحليل رسائل HTTP/2 داخل TLS.

قد يؤدي إنشاء كائن عميل HTTP جديد لكل URL إلى فقد مجموعة اتصالاته. وتعني إعادة استخدام العميل هنا إبقاء الكائن البرمجي واتصالاته، لا مطالبة الوكيل بالاحتفاظ بعنوان IP للخروج. وعندما تتصل دفعة مرارًا بالمضيفين أنفسهم، قد توفر إعادة استخدام الاتصالات عمل إعداد أكثر مما يوفره تغيير بروتوكولات الوكيل. وقد تظل الوجهات الجديدة والاتصالات المغلقة وإعدادات الوكيل المتغيرة بحاجة إلى أنفاق جديدة.

النقل الكبير: انظر إلى عرض النطاق المتاح

بعد إنشاء النفق، تعتمد سرعة التنزيل على المسار وفقدان الرزم وعرض النطاق المتاح وحمل الوكيل وحدود الخدمة. وتمرير HTTPS عبر CONNECT هو أصلًا مهمة تمرير بايتات. ووصف SOCKS5 بأنه أسرع لأنه «لا يقرأ HTTP» يتجاهل هذه الحالة.

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

أي بروتوكول ينبغي أن يستخدمه برنامج ويب كبير؟

يبقى برنامج الويب يرسل طلبات HTTP عندما يستخدم SOCKS5؛ فخيار الوكيل يغيّر كيفية الوصول إلى الخادم. ولبرنامج جديد يجلب صفحات ويب أو يستدعي واجهات HTTPS API، ابدأ بعميل HTTP ناضج وHTTP CONNECT ما لم يوجهك متطلب محدد إلى غير ذلك. وأبق اختيار الوكيل ضمن الإعدادات حتى يمكن اختبار SOCKS5 بمنطق الطلبات نفسه. واختر مكتبة تدعم كليهما إذا كانت المقارنة مهمة للمشروع.

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

كيفية مقارنة السرعة قبل التوسع

1. استخدم البرنامج نفسه والطلبات المستهدفة وأحجام الاستجابات ودرجة التزامن نفسها. وحيث أمكن، قارن نقاط اتصال البروتوكولين بعنوان IP للخروج والمسار نفسيهما؛ وإلا فاجعل منطقة الخروج وحدود الخدمة قابلة للمقارنة وسجل الفرق.
2. أجرِ سلسلة باتصالات جديدة، وأخرى باستخدام التجميع العادي بعد مرحلة الإحماء. وأبق سلوك DNS وحماية TLS والمصادقة وإصدار HTTP وسياسة إعادة المحاولة متكافئة، أو وثّق سبب اختلافها.
3. قِس العمليات الناجحة المكتملة في الثانية وزمن الدفعة كلها، بما يشمل إعادة المحاولات. وسجل أيضًا وسيط زمن الإكمال والمئين 95، والمهل المنتهية والعمليات الفاشلة. ويبين المئين 95 الزمن الذي تنتهي خلاله 95% من العمليات المقاسة.
4. للتنزيل، سجل البايتات المفيدة المستلمة في الثانية. وللطلبات القصيرة، افصل إعداد الاتصال عن الزمن حتى أول بايت وزمن الاستجابة الكاملة. ويشمل الزمن حتى أول بايت أيضًا انتظار الوجهة لتوليد الاستجابة.
5. كرر التشغيل بالتناوب عبر الإعدادين وتحقق من مسار الوكيل المقصود. وإذا استخدم اختبار مجموعة خروج مختلفة أو رجع إلى اتصال مباشر، فلا تعزل نتيجته أثر بروتوكول الوكيل.

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

لماذا يأتي دعم التطبيق أولًا

الحقل المسمى «proxy» لا يعد بكل بروتوكول أو طريقة مصادقة. فمثلًا، تدعم معالجة SOCKS5 المدمجة في Chrome طلبات TCP، لكنها لا تنفذ مصادقة SOCKS5 باسم المستخدم وكلمة المرور أو تمرير UDP. ولا تستطيع خدمة SOCKS5 توفر هذه الميزات جعل وضع متصفح غير داعم يستخدمها.

في SSH أو نقل الملفات أو تطبيق TCP آخر، قد يكون دعم SOCKS الأصلي ملائمًا. ويستطيع HTTP CONNECT نقل بروتوكولات TCP أخرى أيضًا، بشرط قدرة البرنامج على إنشاء النفق وسماح الوكيل بمنفذ الوجهة. ولذلك لا يعني «وكيل HTTP» دائمًا «حركة ويب فقط».

كذلك لا تغطي إعدادات وكيل المتصفح تلقائيًا برنامجًا آخر أو كل ميزة داخل المتصفح. ولمحولات الاتصال الخارجية نطاق تغطية وقيود خاصان بها. وتتناول مقالة وكلاء SOCKS5 وSOCKS4 فروق الإصدارات والتفاوض.

من يحلل اسم مضيف الوجهة؟

مع SOCKS5، يستطيع التطبيق تحليل الوجهة محليًا وإرسال عنوان IP، أو إرسال اسم مضيف ليحلله الوكيل. وفي curl، يختار socks5:// التحليل المحلي للوجهة، بينما يطلب socks5h:// التحليل عبر الوكيل. ويختار الحرف الإضافي سلوك العميل، ولا ينشئ بروتوكول SOCKS جديدًا.

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

أي اتصال مشفر؟

افصل حماية محتوى الموقع عن حماية الاتصال بالوكيل. فعادةً يُبقي موقع HTTPS بيانات التطبيق مشفرة بين التطبيق العميل والموقع عبر أي من نوعي النفق. ويفترض ذلك التحقق المعتاد من الشهادات وعدم إعداد اعتراض TLS.

يضيف وكيل HTTPS اتصال TLS بين التطبيق العميل والوكيل. ويحمي طلب الوكيل وبيانات الاعتماد في ذلك الجزء من المسار. وفي عنوان وكيل، يدل https:// عادةً على هذا الاتصال المحمي. أما الإعداد الموصوف فقط بأنه «وكيل لمواقع HTTPS» فقد يعني بدلًا من ذلك وكيل HTTP عاديًا يدعم CONNECT.

يمكن لمن يراقب مسار الشبكة غير المحمي قراءة بيانات اعتماد HTTP Basic المرسلة إلى وكيل HTTP عادي، والتبادل القياسي لاسم المستخدم وكلمة المرور في SOCKS5. ولا يحمي اتصال TLS اللاحق بالموقع تسجيل الدخول إلى الوكيل بأثر رجعي. ويحتاج SOCKS5 العادي إلى نقل آمن منفصل عندما تكون هذه الحماية مطلوبة.

يبقى الوكيل نقطة نهاية لاتصال TLS الخاص به، ويعرف الوجهة المطلوب الاتصال بها. وإذا كانت الوجهة النهائية تستخدم HTTP عاديًا، فلا يشفر TLS إلى الوكيل اتصال HTTP اللاحق من الوكيل إلى الوجهة. وكذلك لا يخفي تمرير SOCKS المحتوى غير المشفر لمجرد أن الوكيل لا يحتاج إلى تحليله.

هل يغيّر UDP أو HTTP/3 الاختيار؟

للتطبيق الذي يحتاج فعليًا إلى UDP، يعرّف SOCKS5 الأمر UDP ASSOCIATE. ويجب أن ينفذه التطبيق العميل والخدمة، وأن ينقل مسار الشبكة رزم البيانات. أما HTTP CONNECT العادي فينقل نفق TCP. ويمكن تمرير UDP عبر HTTP بآليات إضافية مثل CONNECT-UDP، لكن يجب أن ينفذها الطرفان.

يستخدم HTTP/3 بروتوكول QUIC عبر UDP. ولا يثبت تحميل صفحة HTTPS بنجاح عبر وكيل أن HTTP/3 يعمل: فقد يكون التطبيق العميل استخدم HTTP/2 أو HTTP/1.1 عبر TCP. وقد يناسب هذا الرجوع برنامج ويب؛ لكنه لا يحل محل UDP لميزة تتطلب رزم بيانات. وانظر UDP وQUIC عبر الوكلاء لمسارات التمرير وقيودها.

هل يخفي SOCKS العميل بصورة أفضل؟

عند تمرير HTTP غير مشفر، يستطيع الوكيل إضافة رأس مثل Forwarded يحمل معلومات عن التطبيق العميل الأصلي. ولا يستطيع نفق HTTPS CONNECT تقليدي إدراج ذلك الرأس في الطلب المشفر دون إنهاء اتصال TLS الخاص بالموقع. كذلك لا يضيف SOCKS5 رؤوس HTTP تلقائيًا.

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

كيفية اتخاذ القرار النهائي

ابدأ بالبروتوكولات وطرق الوصول التي يدعمها التطبيق. ولأتمتة الويب المعتادة، يعد HTTP CONNECT خيارًا أوليًا مناسبًا؛ ولتطبيق مبني على SOCKS أو وضع UDP مدعوم، قد يكون SOCKS5 أنسب. ثم اختر سلوك DNS المطلوب وحماية الاتصال بالوكيل، وقارن الأداء بحمل العمل الفعلي.

استخدم اسم المضيف والمنفذ الفعليين للخدمة للبروتوكول المختار. ولا يؤدي استبدال http:// بsocks5:// في إعداد إلى تفعيل SOCKS على خادم لا يوفره. وقبل التوسع، تأكد من خروج الطلبات عبر الوكيل المتوقع ومن أن فشل الوكيل لا يطلق بصمت مسارًا مباشرًا غير مرغوب فيه.