أكمل فريق عمل هندسة الإنترنت (IETF)، المسؤول عن تطوير بروتوكولات الإنترنت وهندستها، تشكيل RFC لبروتوكول HTTP/3.0 ونشر المواصفات ذات الصلة تحت المعرفات RFC 9114 (البروتوكول) وRFC 9204 ( تقنية ضغط رأس QPACK لـ HTTP/3). حصلت مواصفات HTTP/3.0 على حالة "المعيار المقترح"، وبعد ذلك سيبدأ العمل على منح RFC حالة مسودة معيار (مسودة قياسية)، وهو ما يعني في الواقع تحقيق الاستقرار الكامل للبروتوكول ومراعاة كافة التعليقات المقدمة. في الوقت نفسه، تم نشر إصدارات محدثة من مواصفات بروتوكولات HTTP/1.1 (RFC 9112) وHTTP/2.0 (RFC 9113)، بالإضافة إلى المستندات التي تحدد دلالات طلبات HTTP (RFC 9110) ورؤوس التحكم في التخزين المؤقت لـ HTTP. (RFC 9111).
يحدد بروتوكول HTTP/3 استخدام بروتوكول QUIC (اتصالات إنترنت UDP السريعة) كوسيلة نقل لـ HTTP/2. QUIC هو امتداد لبروتوكول UDP الذي يدعم تعدد الاتصالات المتعددة ويوفر طرق تشفير مكافئة لـ TLS/SSL. تم إنشاء البروتوكول في عام 2013 بواسطة Google كبديل لمجموعة TCP+TLS للويب، وحل المشكلات المتعلقة بإعداد الاتصال الطويل وأوقات التفاوض في TCP والقضاء على التأخير عند فقدان الحزم أثناء نقل البيانات.
حاليًا، يتم تنفيذ دعم QUIC وHTTP/3.0 بالفعل في جميع متصفحات الويب الشائعة (في Chrome وFirefox وEdge، يتم تمكين دعم HTTP/3 افتراضيًا، وفي Safari يتطلب الإعداد "متقدم > الميزات التجريبية > HTTP/3" للتمكين). على جانب الخادم، تتوفر تطبيقات HTTP/3 لـ nginx (في فرع منفصل وفي شكل وحدة منفصلة)، وCaddy، وIIS، وLiteSpeed. يتم توفير دعم HTTP/3 أيضًا من خلال شبكة تسليم محتوى Cloudflare.
الملامح الرئيسية لQUIC:
- الأمان العالي ، على غرار TLS (في الواقع ، يوفر QUIC القدرة على استخدام TLS عبر UDP) ؛
- التحكم في تكامل الدفق لمنع فقدان الحزمة ؛
- القدرة على إنشاء اتصال على الفور (0-RTT، في حوالي 75% من الحالات، يمكن نقل البيانات مباشرة بعد إرسال حزمة إعداد الاتصال) وتوفير الحد الأدنى من التأخير بين إرسال الطلب وتلقي الاستجابة (RTT، وقت الرحلة ذهابًا وإيابًا)؛
- استخدام رقم تسلسلي مختلف عند إعادة إرسال حزمة، مما يتجنب الغموض في تحديد الحزم المستلمة ويتخلص من المهلات؛
- يؤثر فقدان الحزمة فقط على تسليم الدفق المرتبط به ولا يوقف تسليم البيانات في التدفقات المرسلة بالتوازي عبر الاتصال الحالي ؛
- أدوات تصحيح الأخطاء التي تقلل التأخير بسبب إعادة إرسال الحزم المفقودة. استخدام أكواد خاصة لتصحيح الأخطاء على مستوى الحزمة لتقليل المواقف التي تتطلب إعادة إرسال بيانات الحزمة المفقودة.
- تتم محاذاة حدود كتل التشفير مع حدود حزم QUIC ، مما يقلل من تأثير فقدان الحزمة على فك تشفير محتويات الحزم التالية ؛
- لا توجد مشاكل مع حظر قائمة انتظار TCP ؛
- دعم معرف الاتصال لتقليل وقت إعادة الاتصال للعملاء المتنقلين ؛
- إمكانية توصيل الآليات المتقدمة للتحكم في الحمل الزائد للاتصال ؛
- استخدام تقنيات التنبؤ بعرض النطاق الترددي في كل اتجاه لضمان الكثافة المثلى للحزم المرسلة ، ومنع التدحرج في حالة الازدحام التي يحدث فيها فقد للحزم ؛
- زيادة كبيرة في الأداء والإنتاجية مقارنة بـ TCP. بالنسبة لخدمات الفيديو مثل YouTube، تبين أن QUIC يقلل من عمليات إعادة التخزين المؤقت عند مشاهدة مقاطع الفيديو بنسبة 30%.
من بين التغييرات في مواصفات HTTP/1.1، يمكن ملاحظة الحظر المفروض على الاستخدام المعزول لحرف إرجاع السطر (CR) خارج النص مع المحتوى، أي. في عناصر البروتوكول، لا يمكن استخدام حرف CR إلا مع حرف تغذية السطر (CRLF). تم تحسين خوارزمية تخطيط الطلب المقسم لتبسيط فصل الحقول والأقسام المرفقة بالرؤوس. تمت إضافة توصيات للتعامل مع المحتوى الغامض لمنع هجمات "تهريب طلب HTTP"، والتي تسمح لنا بدمج أنفسنا في محتوى طلبات المستخدمين الآخرين في التدفق بين الواجهة الأمامية والخلفية.
يحدد تحديث مواصفات HTTP/2.0 بشكل صريح دعم TLS 1.3. تم إهمال نظام تحديد الأولويات وحقول الرأس المرتبطة به. تم الإعلان عن أن الآلية غير المستخدمة لتحديث الاتصال بـ HTTP/1.1 قديمة. متطلبات مخفضة للتحقق من أسماء الحقول وقيمها. يُقترح استخدام بعض أنواع الإطارات والمعلمات المحجوزة مسبقًا. يتم تعريف حقول الرأس المحظورة المتعلقة بالاتصال بشكل أكثر دقة.
المصدر: opennet.ru