HTTP/2 مقابل HTTP/3 ما تغير حقًا (وهل يهم تطبيقك)

الإجابة القصيرة: إذا كنت وراء CDN، فإن HTTP/3 قد تم التعامل معه بالفعل ولا حاجة للتكوين. إذا كنت تدير خادمًا خاصًا، فإن HTTP/2 تغطي حالة 95%، وتحسين HTTP/3 مفيد لكنه ليس طارئًا.

النسخ الطويل، لأن التصميم التقني للفرق مثير للاهتمام — وفهمه يساعدك على اتخاذ قرارات أفضل حول أين يهم تواجد نسخة البروتوكول.

ما الذي حلّه HTTP/2 فعليًا؟

كانت HTTP/1.1 تواجه مشكلتين تم حلها بشكل صحيح في HTTP/2.

كثرة الاتصالات TCP لتحميل صفحة واحدة. كان المتصفح يفتح 6 إلى 8 اتصالات TCP لكل مصدر فقط لتحميل الموارد بشكل متوازي. كل اتصال يحمل تكلفة إعداد (مُحادثة TCP، تفاوض TLS)، وكان هذا النهج غير فعّال عند التوسع. استبدال HTTP/2 هذا بـ "التنويع": اتصال TCP واحد، مع تدفق متوازي لطلبات وردود. لا حاجة لتنقل الاتصالات.

أوامر رأسية مكررة في كل طلب. في HTTP/1.1، يرسل كل طلب جميع رؤوسه — User-Agent, Accept-Encoding, Authorizationكلها — حتى لو لم تكن هناك تغييرات من الطلب السابق. يُقلل تطبيق HTTP/2 للضغط من خلال تبادل رؤوس متماثلة باستخدام جدول مشاركة بين العميل والخادم. في حالة تطبيق يُرسل نفس Authorization: Bearer ... الرمز في كل طلب، يُقلل هذا التكلفة بشكل كبير في حركة المرور العالية.

كان "الإرسال المسبق" مفترضًا كمكسب ثالث (إرسال الموارد التي يحتاجها العميل قبل طلبه)، لكنه لم يُستخدم فعليًا. أوقفت كروم الدعم في 2022. اعتبره مُعتمدًا ولا تبني أي شيء عليه.

المشكلة التي لم يُحلها HTTP/2

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

على اتصال موثوق عبر كابل، تكون معدلات فقدان الحزم منخفضة جدًا بحيث لا تؤثر كثيرًا. ولكن على الشبكات المحمولة، أو الاتصالات السATELLITE، أو أي مسار يعاني من فقدان حزم ملحوظ، تنهار ميزة تعدد الحزم في HTTP/2. يمكنك تعدد 20 حزمة على اتصال واحد، وفقدان حزمة واحدة يوقف جميع الحزم 20. 😬

هذا ليس محدودية يمكن إصلاحها. إنه مبني على بنية بروتوكول طلب متوازي يعمل على نقل بيانات بسيط لا يعرف ما هو "الطلب".

ما الذي تغيره HTTP/3 فعليًا؟

لا يُعدّ HTTP/3 مجرد تعديل في تنسيق الإطار أو إضافة ميزة جديدة. إنه يُستبدل TCP بـ QUIC — بروتوكول نقل يعمل على UDP.

يُعالج QUIC التوسع على مستوى النقل، لذا فإن فقدان حزمة فقط يُوقف الطلب الذي ينتمي إليه، وليس كل الطلب على الاتصال. يتم حل مشكلة توقف الرأس على مستوى الصحيح. هذا هو النقطة الأساسية.

أيضًا يجلب QUIC بعض الميزات الأخرى:

• الانتقال بين الاتصالات. يحدد QUIC الاتصالات بـ "معرّف الاتصال"، وليس بـ 4 أزواج من عنصر الاتصال (عنوان المصدر، مفتاح المصدر، عنوان الوجهة، مفتاح الوجهة). عند التحول من واي فاي إلى شبكة متنقلة أثناء نقل البيانات، يبقى الاتصال مُحافظًا. هذا مهم للتطبيقات المحمولة؛ أما بالنسبة للاتصالات بين الخوادم، فهو غير مهم بشكل كبير.
• الاتصالات بـ 0-RTT. لأي اتصال مع خادم معروف، يمكن لـ QUIC تجاهل التفاوض على التشفير وبدء إرسال البيانات فورًا. يُحقق فائدة حقيقية في إعادة الاتصال. ملاحظة: يحتوي 0-RTT على مخاطر تكرار الاتصال — لا تستخدمه للنطاقات غير المُعادلة دون فهم التنازلات.
• التوثيق المطلوب لـ TLS 1.3. لا يدعم QUIC الاتصالات غير المشفرة. لا يوجد HTTP/3 بدون TLS، تمامًا.

تم تغيير ضغط الرؤوس أيضًا: يستخدم HTTP/3 QPACK بدلًا من HPACK. الفرق تقني — يتجنب QPACK مشكلة توقف في HPACK عند ضغط الرؤوس عبر الطلب. في الممارسة، لن تلاحظ فرقًا؛ إنه تحسين للبنية.

مقارنة الميزات

ميزة	HTTP/1.1	HTTP/2	HTTP/3
بروتوكول النقل	TCP	TCP	QUIC (UDP)
التوسع في الطلبات	لا (مُتعدد الاتصالات)	نعم	نعم
توقف الرأس على مستوى الطلبات	مُستوى الطلب	مُستوى TCP (يوجد ما زال)	لا أحد
ضغط الرؤوس	لا أحد	HPACK	QPACK
التوثيق المطلوب	لا	لا (في المواصفة)، نعم (في المتصفحات)	نعم (مُلزَم)
الاتصال بـ 0-RTT	لا	لا	نعم
الانتقال بين الاتصالات	لا	لا	نعم
الإرسال المسبق	لا	نعم (مُعتمد)	لا (مُحذوف)

ما المقصود بهذا بالنسبة للتأخير في الاتصالات مع الـ API؟

يساعد HTTP/3 بشكل خاص في ظروف محددة. لا يُحسن كل شيء بشكل عام.

الشبكات التي تفقد حزم البيانات. سيشهد العملاء المحمولون الذين يُصلون إلى خدمة الـ API عبر LTE أو 5G بجودة محدودة تحسن قابل للقياس. الاتصالات بين المراكز في شبكة موثوقة حيث معدل فقدان الحزم يساوي صفرًا؟ الفرق غير ملحوظ.

الاتصالات الباردة والاتصالات المُعاد تنشئها. إذا كان عميلك يُعيد الاتصال بشكل متكرر — مثل الوظائف المُستقلة ذات المدة القصيرة، أو إعادة تشغيل تطبيقات الهاتف، أو الأكواد المؤقتة — فإن 0-RTT يقلل من تكلفة الإعداد. الاتصالات الطويلة التي تبقى مفتوحة لدقائق لا تُستفيد من هذا.

مدى حجم الطلبات مهم. تُظهر HTTP/2 وHTTP/3 فوائد كبيرة عندما يُرسل العميل طلبات متوازية. يرى المتصفح الذي يُحمل 80 موردًا متوازيًا فوائد كبيرة من التوسع. يرى الـ API الذي يُرسل 3 طلبات متسلسلة فوائد أصغر. كلما زاد عدد الطلبات المتوازية التي يُرسلها العميل، زادت أهمية تحسينات النقل.

كيف تتعامل مع ذلك في CDNs؟

دعم Cloudflare لـ HTTP/3 بدأ في 2019 وتم تفعيله بشكل افتراضي. أضافت AWS CloudFront الدعم في 2022. Fastly، Akamai، BunnyCDN — كلها تدعمه.

البنية مهمة هنا: يُنهي CDN الاتصال من العميل في الحافة. حتى لو اتصل العميل بـ CDN عبر HTTP/3 باستخدام QUIC، فإن الاتصال من CDN إلى المصدر يُفترض أنه HTTP/1.1 أو HTTP/2 على TCP. لذا، لا يتطلب تفعيل HTTP/3 على CDN أي تغييرات على الخادم المُصدر.

إذا كنت على Cloudflare، فتحقق من إعدادات السرعة → التحسينات — HTTP/3 (مع QUIC) هو تبديل مُفعّل بشكل افتراضي في معظم المناطق. أما في CDNs الأخرى، فتختلف. هذا هو التغيير الأكثر فعالية الذي يمكن أن يفعله معظم الفرق: بدون تغييرات على الخادم المُصدر، وفوائد فورية للعملاء على الشبكات المحمولة أو ذات التأخير العالي.

هل يجب أن تفعل شيئًا فعليًا؟

وراء CDN: تحقق من تفعيل HTTP/3 وانهِ. يستغرق 30 ثانية.

إذا كنت تستخدم nginx خاصًا: يتطلب HTTP/3 من nginx 1.25+ (الفرع الرئيسي — الوضع المستقر خلف في QUIC). ستحتاج إلى --with-http_v3_module مفتاح التجميع وتعليمات listen 443 quic reuseport إضافة إلى الاستماع إلى TCP. تأكد من أن مدخل UDP 443 مفتوح في جدار الحماية — بعض التكوينات تمنعه. يُعتبر مفيدًا إذا كنت تُقدم خدمة للعملاء المحمولين؛ لكنه ليس يستحق التحديث إذا كنت تتعامل فقط مع الاتصالات بين الخوادم.

إذا كنت تستخدم Caddy: يتم تفعيل HTTP/3 بشكل افتراضي دون أي إعداد. لا حاجة للعمل.

إذا كنت تبني عميلًا يُتصل بـ APIs خارجية: هل تُحصل على HTTP/3 يعتمد على الخادم الذي تُتصل به، وليس على الكود. يدعم curl لـ HTTP/3 من إصدار 7.86.0 مع مكون متوافق (nghttp3 أو quiche). لا يدعم معظم مكتبات الاتصال في Python وNode بشكل مدمج بعد. لا يدعم مكتبة Go القياسية؛ هناك مكتبة منفصلة إذا كنت بحاجة إليها. net/http ملاحظة عملية: إذا كنت تختبر أي نسخة من البروتوكول التي يتفاوضها الخادم، أو تبني أوامر curl مع quic-go معلمات،

على iotools.cloud مفيد لبناء الطلب الصحيح دون البحث عن صيغة المعلمات بدقة كل مرة. --http3 العلم، منشئ أوامر cURL على iotools.cloud يُستخدم لبناء الأمر الصحيح دون الحاجة إلى البحث عن صيغة العلم بدقة كل مرة.

قد يعجبك أيضاً