أعلنت Mozilla عن نيتها البدء التدريجي في HTTP/3 وQUIC مع إصدار Firefox 88، المقرر إصداره في 19 أبريل (كان من المتوقع في الأصل إصداره في 20 أبريل، ولكن وفقًا للجدول الزمني، سيتم تأجيله لمدة يوم واحد). سيتم تمكين دعم HTTP/3 لنسبة صغيرة فقط من المستخدمين في البداية، وباستثناء أي مشكلات غير متوقعة، سيتم طرحه للجميع بحلول نهاية شهر مايو. في الإصدارات الليلية والإصدارات التجريبية، تم تمكين HTTP/3 افتراضيًا في نهاية شهر مارس.
دعونا نتذكر أن تنفيذ HTTP/3 في Firefox يعتمد على مشروع neqo الذي طورته Mozilla، والذي يوفر تنفيذ العميل والخادم لبروتوكول QUIC. تمت كتابة رمز المكون لدعم HTTP/3 وQUIC بلغة Rust. للتحكم في تمكين HTTP/3، يوفر about:config خيار "network.http.http3.enabled". من برنامج العميل، تمت إضافة الدعم التجريبي لـ HTTP/3 أيضًا إلى Chrome وcurl، وهو متاح للخوادم في nginx، وكذلك في شكل وحدة nginx وخادم اختبار من Cloudflare. ومن ناحية موقع الويب، يتوفر دعم HTTP/3 بالفعل على خوادم Google وFacebook.
لا يزال بروتوكول HTTP/3 في مرحلة مسودة المواصفات ولم يتم توحيده بالكامل بعد بواسطة IETF. يتطلب HTTP/3 دعم العميل والخادم لنفس الإصدار من مسودة معيار QUIC وHTTP/3، المحدد في رأس Alt-Svc (يدعم Firefox مسودات المواصفات من 27 إلى 32).
يحدد HTTP/3 استخدام بروتوكول QUIC كوسيلة نقل لـ HTTP/2. تم تطوير بروتوكول QUIC (اتصالات الإنترنت السريعة UDP) بواسطة Google منذ عام 2013 كبديل لمجموعة TCP+TLS للويب، وحل المشكلات المتعلقة بأوقات الإعداد والتفاوض الطويلة للاتصالات في TCP والقضاء على التأخير عند فقدان الحزم أثناء البيانات تحويل. QUIC هو امتداد لبروتوكول UDP الذي يدعم تعدد الاتصالات المتعددة ويوفر طرق تشفير مكافئة لـ TLS/SSL. أثناء تطوير معيار IETF، تم إجراء تغييرات على البروتوكول، مما أدى إلى ظهور فرعين متوازيين، أحدهما لـ HTTP/3، والثاني مدعوم من Google (يدعم Chrome كلا الخيارين).
الملامح الرئيسية لQUIC:
- الأمان العالي ، على غرار TLS (في الواقع ، يوفر QUIC القدرة على استخدام TLS عبر UDP) ؛
- التحكم في تكامل الدفق لمنع فقدان الحزمة ؛
- القدرة على إنشاء اتصال على الفور (0-RTT، في حوالي 75% من الحالات، يمكن نقل البيانات مباشرة بعد إرسال حزمة إعداد الاتصال) وتوفير الحد الأدنى من التأخير بين إرسال الطلب وتلقي الاستجابة (RTT، وقت الرحلة ذهابًا وإيابًا)؛
- استخدام رقم تسلسلي مختلف عند إعادة إرسال حزمة، مما يتجنب الغموض في تحديد الحزم المستلمة ويتخلص من المهلات؛
- يؤثر فقدان الحزمة فقط على تسليم الدفق المرتبط به ولا يوقف تسليم البيانات في التدفقات المرسلة بالتوازي عبر الاتصال الحالي ؛
- أدوات تصحيح الأخطاء التي تقلل التأخير بسبب إعادة إرسال الحزم المفقودة. استخدام أكواد خاصة لتصحيح الأخطاء على مستوى الحزمة لتقليل المواقف التي تتطلب إعادة إرسال بيانات الحزمة المفقودة.
- تتم محاذاة حدود كتل التشفير مع حدود حزم QUIC ، مما يقلل من تأثير فقدان الحزمة على فك تشفير محتويات الحزم التالية ؛
- لا توجد مشاكل مع حظر قائمة انتظار TCP ؛
- دعم معرف الاتصال لتقليل وقت إعادة الاتصال للعملاء المتنقلين ؛
- إمكانية توصيل الآليات المتقدمة للتحكم في الحمل الزائد للاتصال ؛
- استخدام تقنيات التنبؤ بعرض النطاق الترددي في كل اتجاه لضمان الكثافة المثلى للحزم المرسلة ، ومنع التدحرج في حالة الازدحام التي يحدث فيها فقد للحزم ؛
- زيادة كبيرة في الأداء والإنتاجية مقارنة بـ TCP. بالنسبة لخدمات الفيديو مثل YouTube، تبين أن QUIC يقلل من عمليات إعادة التخزين المؤقت عند مشاهدة مقاطع الفيديو بنسبة 30%.
المصدر: opennet.ru