يمر HTTP/2 عبر البروكسيات دون صعوبة لأنه يعمل عبر TCP، وTCP هو بالضبط ما ينقله نفق CONNECT أو اتصال SOCKS5. أما HTTP/3 فلا يمر: فهو يعمل عبر QUIC، الذي يعتمد على UDP، ولا تستطيع بروكسيات HTTP العادية نقل UDP على الإطلاق بينما لا تقوم معظم تطبيقات SOCKS5 بذلك أيضًا. النتيجة العملية هي أن العميل عبر بروكسي يتحدث دائمًا تقريبًا HTTP/2 (أو HTTP/1.1) مع الموقع حتى عندما يدعم الموقع HTTP/3 — حيث يقوم المتصفح بالتبديل التلقائي بصمت. هذا جيد لمعظم الأعمال، لكنه يغير ما يراه الوجهة، ومن الجدير فهمه بدلاً من اكتشافه.
البروتوكولات الثلاثة في دقيقة واحدة
- HTTP/1.1 (1997): نصي، طلب واحد في كل مرة لكل اتصال؛ تفتح المتصفحات عدة اتصالات بالتوازي لتعويض ذلك.
- HTTP/2 (2015): إطار ثنائي، تدفقات متزامنة متعددة مضاعفة عبر اتصال TCP واحد، ضغط الترويسات (HPACK)، دفع الخادم (مهجور الآن إلى حد كبير). نفس TCP + TLS تحته كما في HTTP/1.1.
- HTTP/3 (2022): نفس دلالات HTTP/2 لكن يحمله QUIC، وهو بروتوكول نقل يعمل عبر UDP، ويبني TLS 1.3 في مصافحته، ويتجنب حظر رأس الخط في TCP، ويسمح للاتصال بالبقاء عند تغيير عنوان IP (مثل انتقال الهاتف من Wi-Fi إلى 4G).
يتعلم المتصفح أن الموقع يقدم HTTP/3 بإحدى طريقتين: ترويسة استجابة Alt-Svc: h3=":443" في استجابة HTTP/2 سابقة، أو سجل DNS HTTPS يعلن عنه. بمجرد معرفته، يحاول QUIC في الاتصال التالي ويتذكر النتيجة.
كيف تحمل البروكسيات كل بروتوكول
بروكسي HTTP
بالنسبة لوجهة HTTPS، يرسل العميل CONNECT host:443، ويفتح البروكسي اتصال TCP بالوجهة ويحول نفسه إلى أنبوب بايت بسيط. كل ما يتفاوض عليه العميل والوجهة داخل هذا الأنبوب — TLS 1.3، ثم HTTP/1.1 أو HTTP/2 عبر ALPN — غير مرئي للبروكسي ويعمل دون تغيير. لذا فإن HTTP/2 عبر بروكسي HTTP أمر طبيعي تمامًا.
لا مكان لـ UDP في هذا النموذج. CONNECT ينشئ نفق TCP؛ لا توجد طريقة قياسية لبروكسي HTTP/1.1 عادي ليقول "قم بإعادة توجيه حزم UDP الخاصة بي إلى هذا المضيف." المتصفح الذي تم تكوينه مع بروكسي HTTP ببساطة لا يحاول استخدام QUIC مع المواقع — حيث يقوم Chrome وFirefox بتعطيل HTTP/3 للاتصالات عبر البروكسي — ويستخدم HTTP/2 عبر النفق بدلاً من ذلك. لا خطأ، لا تحذير.
بروكسي SOCKS5
يعرّف SOCKS5 بالفعل أمر UDP ASSOCIATE لإعادة توجيه الحزم. من حيث المبدأ، يمكن لبروكسي SOCKS5 حمل QUIC. عمليًا:
- العديد من بروكسيات SOCKS5 التجارية تنفذ فقط
CONNECT(TCP) وترفض أو تتجاهل UDP ASSOCIATE؛ - يتطلب إعادة توجيه UDP عبر SOCKS5 أن يكون للبروكسي منفذ UDP يمكن الوصول إليه وأن يدعم العميل رقصة الارتباط، وهو ما لا تفعله المتصفحات لـ HTTP/3؛
- يتعامل Chrome وFirefox مع بروكسي SOCKS بنفس طريقة HTTP لهذا الغرض: لا تتم محاولة HTTP/3.
لذا حتى عندما يمكن للبروكسي إعادة توجيه UDP، لن يطلب المتصفح ذلك. يمكن توجيه عملاء QUIC من سطر الأوامر وبعض المكتبات إلى بروكسي SOCKS5 يدعم UDP، لكن هذا تكوين متخصص، وليس الافتراضي. تغطي مقارنة SOCKS5 وHTTP الفرق بين TCP/UDP بشكل أوسع.
ما الذي يمكن أن يحمل HTTP/3: MASQUE وCONNECT-UDP
قامت مجموعة عمل IETF MASQUE بتوحيد CONNECT-UDP (RFC 9298)، وهو امتداد يسمح لبروكسي HTTP/3 (أو HTTP/2) بنقل حمولات UDP — وبالتالي QUIC إلى الوجهة. هذا ما تستخدمه iCloud Private Relay من Apple وبعض بروكسيات الخصوصية الأحدث. الدعم في البروكسيات التجارية العامة وفي إعدادات بروكسي المتصفح لا يزال نادرًا؛ عندما يعلن مزود عن "دعم HTTP/3"، يجدر السؤال عما إذا كانوا يقصدون أن البروكسي يتحدث HTTP/3 معك أو يمكنه نقل HTTP/3 إلى الوجهات — فهذان شيئان مختلفان.
ماذا يحدث فعليًا، خطوة بخطوة
- يطلب متصفحك عبر البروكسي
https://example.com. يفتحCONNECT example.com:443عبر البروكسي. - داخل النفق، يقوم بمصافحة TLS 1.3، ويعرض ALPN
h2وhttp/1.1. تختار الوجهةh2. أنت الآن على HTTP/2. - يحمل الرد
Alt-Svc: h3=":443". يلاحظه المتصفح — وبسبب وجود بروكسي، يتجاهله لأغراض الاتصال. - كل طلب لاحق إلى تلك الوجهة يستمر عبر HTTP/2 عبر النفق.
أوقف تشغيل البروكسي وأعد التحميل: الآن يكرم المتصفح Alt-Svc ويتم تقديم نفس الموقع عبر HTTP/3. لا شيء معطل في كلتا الحالتين؛ البروتوكول مختلف ببساطة.
لماذا يهم هذا
الأداء
مزايا HTTP/3 — مصافحة أسرع، لا حظر رأس الخط على الروابط ذات الفقد، ترحيل الاتصال — تضيع عبر البروكسي. بالنسبة لبروكسيات مراكز البيانات على روابط جيدة، الفرق صغير. بالنسبة لبروكسيات الجوال، حيث تكون القفزة الأخيرة رابط خلوي به فقد، كان QUIC سيساعد أكثر وهو بالضبط حيث لا يمكنك الحصول عليه. خصص مزيدًا من زمن الوصول قليلاً مما قد يظهره اتصال HTTP/3 مباشر؛ راجع المنهجية في كيفية قياس سرعة البروكسي.
بصمة المتصفح والاتساق
هذه هي النقطة الدقيقة. تسجل أنظمة مكافحة الروبوتات البروتوكول الذي استخدمه العميل وشكل إعدادات HTTP/2 الخاصة به (انظر كيف تعمل أنظمة مكافحة الروبوتات). يصل Chrome حديث على اتصال مباشر إلى معظم المواقع الكبيرة عبر HTTP/3. نفس Chrome عبر بروكسي يصل عبر HTTP/2. هذا ليس مريبًا في حد ذاته — فالعديد من المستخدمين الحقيقيين خلف بروكسيات الشركات ولا يستخدمون HTTP/3 أبدًا — لكنه نقطة بيانات إضافية، ويعني أن بصمة HTTP/2 الخاصة بك (قيم SETTINGS، ترتيب الترويسات) أصبحت الآن دائمًا مكشوفة ويجب أن تكون متسقة مع المتصفح الذي تدعيه. يجب على عملاء HTTP الذين يقلدون المتصفحات تقليد طبقة HTTP/2، وليس طبقة TLS فقط، لهذا السبب بالضبط؛ تشرح مقالة بصمة TLS المكدس.
أدوات تجريف الويب
يتحدث requests في Python HTTP/1.1 فقط؛ يمكن لـ httpx القيام بـ HTTP/2 مع إضافة h2؛ aiohttp هو HTTP/1.1. لا يقوم أي منها بـ HTTP/3 عبر بروكسي. نظرًا لأن المتصفح عبر بروكسي يكون على HTTP/2 على أي حال، فإن استخدام HTTP/2 في عميلك (حيث تدعم المكتبة ذلك) يبقيك أقرب إلى ما يبدو عليه المستخدم الحقيقي عبر بروكسي. أمثلة في البروكسيات في Python.
إرشادات عملية
| الموقف | ما تحصل عليه | الإجراء |
|---|---|---|
| متصفح + بروكسي HTTP، موقع HTTP/3 | HTTP/2 عبر نفق CONNECT | لا شيء لتفعله؛ هذا طبيعي |
| متصفح + بروكسي SOCKS5، موقع HTTP/3 | HTTP/2 (المتصفح لا يحاول QUIC عبر SOCKS) | لا شيء لتفعله |
| تحتاج حقًا إلى HTTP/3 إلى وجهة عبر بروكسي | يتطلب دعم CONNECT-UDP/MASQUE من النهاية إلى النهاية | اسأل المزود تحديدًا؛ افترض لا ما لم يتم التأكيد |
| الموقع يتصرف بشكل مختلف عبر بروكسي مقابل مباشر | ربما متعلق بالبروتوكول، على الأرجح متعلق بعنوان IP | قارن مع متصفح حقيقي على نفس البروكسي قبل إلقاء اللوم على HTTP/3 |
| انتحال شخصية عميل للمواقع المحمية | يجب مطابقة إعدادات HTTP/2 وترتيب الترويسات للمتصفح | استخدم عميلًا يقلد HTTP/2، وليس TLS فقط |
| قياس زمن استجابة البروكسي | قارن المثل بالمثل: HTTP/2 مباشر مقابل HTTP/2 عبر بروكسي | لا تقارن HTTP/3 مباشر مع HTTP/2 عبر بروكسي |
الأسئلة الشائعة
هل يعمل HTTP/2 عبر بروكسي؟
نعم. يعمل HTTP/2 عبر TCP وTLS، وهو ما ينقله نفق CONNECT أو اتصال SOCKS5 بشفافية. لا يحتاج البروكسي إلى فهم HTTP/2 على الإطلاق.
هل يعمل HTTP/3 عبر بروكسي؟
بشكل عام لا. يستخدم HTTP/3 QUIC عبر UDP؛ لا تستطيع بروكسيات HTTP نقل UDP ولا تحاول المتصفحات QUIC عند تكوين بروكسي. يتحول المتصفح تلقائيًا إلى HTTP/2. فقط البروكسيات التي تدعم CONNECT-UDP (MASQUE) يمكنها حمل HTTP/3 إلى الوجهات، وهذا نادر.
هل يمكن لبروكسي SOCKS5 حمل QUIC؟
البروتوكول لديه أمر إعادة توجيه UDP، لكن العديد من خدمات SOCKS5 التجارية لا تنفذه ولا تستخدمه المتصفحات لـ HTTP/3. يمكن للعملاء المتخصصين ذلك، إذا كان البروكسي يدعم حقًا UDP ASSOCIATE.
هل استخدام HTTP/2 بدلاً من HTTP/3 سيجعلني مكتشفًا؟
ليس في حد ذاته — فالعديد من المستخدمين الشرعيين خلف بروكسيات تفرض HTTP/2. لكنه يعني أن بصمة HTTP/2 الخاصة بك مرئية دائمًا، لذا يجب أن تكون متسقة مع المتصفح الذي تدعيه.
هل HTTP/3 أسرع عبر بروكسي؟
لا تحصل على HTTP/3 عبر بروكسي عادي، لذا السؤال لا يطرح؛ تحصل على HTTP/2، وهو أبطأ قليلاً على الروابط ذات الفقد من HTTP/3. على روابط مراكز البيانات الجيدة، الفرق لا يكاد يذكر.
ما هو Alt-Svc؟
ترويسة استجابة HTTP يخبر بها الموقع العميل أن نفس المورد متاح عبر بروتوكول أو منفذ آخر — عادةً h3=":443" للإعلان عن HTTP/3. تكرم المتصفحات ذلك على الاتصالات المباشرة وتتجاهله لأغراض الاتصال عند تكوين بروكسي.