قام فريق عمل هندسة الإنترنت (IETF)، المسؤول عن تطوير بروتوكولات الإنترنت وبنيتها، بوضع اللمسات النهائية على RFC لبروتوكول QUIC ونشر المواصفات ذات الصلة تحت المعرفات RFC 8999 (خصائص البروتوكول المستقلة عن الإصدار)، RFC 9000 (النقل) عبر UDP)، RFC 9001 (تشفير TLS لقناة اتصال QUIC) وRFC 9002 (التحكم في الازدحام واكتشاف فقدان الحزم أثناء نقل البيانات).
حصلت RFCs على حالة "المعيار المقترح"، وبعد ذلك سيبدأ العمل في منح RFC حالة مسودة معيار (مشروع المعيار)، وهو ما يعني في الواقع تحقيق الاستقرار الكامل للبروتوكول مع مراعاة جميع التعليقات المقدمة. لا يزال بروتوكول HTTP/3، الذي يحدد استخدام بروتوكول QUIC كوسيلة نقل لـ HTTP/2، في مرحلة مواصفات المسودة، ولكن سيتم توحيده أخيرًا بواسطة IETF.
من المتوقع أن يعطي توحيد QUIC حافزًا لاعتماد هذا البروتوكول على نطاق أوسع، بالإضافة إلى تطوير الامتدادات المستندة إليه، مثل WebTransport (تقنية لإرسال واستقبال البيانات بين المتصفح والخادم) وMASQUE (تقنية وكيل اتصال تعمل على توسيع إمكانيات SOCKS وHTTP CONNECT، واستخدام HTTPS عبر QUIC كوسيلة نقل).
دعونا نتذكر أن بروتوكول QUIC (اتصالات الإنترنت السريعة UDP) تم تطويره بواسطة Google منذ عام 2013 كبديل لمجموعة TCP+TLS للويب، وحل المشكلات المتعلقة بأوقات الإعداد والتفاوض الطويلة للاتصالات في TCP والقضاء على التأخير عندما يتم فقدان الحزم أثناء نقل البيانات. QUIC هو امتداد لبروتوكول UDP الذي يدعم تعدد الاتصالات المتعددة ويوفر طرق تشفير مكافئة لـ TLS/SSL. أثناء تطوير معيار IETF، تم إجراء تغييرات على البروتوكول، مما أدى إلى ظهور فرعين متوازيين، أحدهما لـ HTTP/3، والثاني مدعوم من Google (يدعم Chrome كلا الخيارين، ويدعم Firefox إصدار IETF) .
الملامح الرئيسية لQUIC:
- الأمان العالي ، على غرار TLS (في الواقع ، يوفر QUIC القدرة على استخدام TLS عبر UDP) ؛
- التحكم في تكامل الدفق لمنع فقدان الحزمة ؛
- القدرة على إنشاء اتصال على الفور (0-RTT، في حوالي 75% من الحالات، يمكن نقل البيانات مباشرة بعد إرسال حزمة إعداد الاتصال) وتوفير الحد الأدنى من التأخير بين إرسال الطلب وتلقي الاستجابة (RTT، وقت الرحلة ذهابًا وإيابًا)؛
- استخدام رقم تسلسلي مختلف عند إعادة إرسال حزمة، مما يتجنب الغموض في تحديد الحزم المستلمة ويتخلص من المهلات؛
- يؤثر فقدان الحزمة فقط على تسليم الدفق المرتبط به ولا يوقف تسليم البيانات في التدفقات المرسلة بالتوازي عبر الاتصال الحالي ؛
- أدوات تصحيح الأخطاء التي تقلل التأخير بسبب إعادة إرسال الحزم المفقودة. استخدام أكواد خاصة لتصحيح الأخطاء على مستوى الحزمة لتقليل المواقف التي تتطلب إعادة إرسال بيانات الحزمة المفقودة.
- تتم محاذاة حدود كتل التشفير مع حدود حزم QUIC ، مما يقلل من تأثير فقدان الحزمة على فك تشفير محتويات الحزم التالية ؛
- لا توجد مشاكل مع حظر قائمة انتظار TCP ؛
- دعم معرف الاتصال لتقليل وقت إعادة الاتصال للعملاء المتنقلين ؛
- إمكانية توصيل الآليات المتقدمة للتحكم في الحمل الزائد للاتصال ؛
- استخدام تقنيات التنبؤ بعرض النطاق الترددي في كل اتجاه لضمان الكثافة المثلى للحزم المرسلة ، ومنع التدحرج في حالة الازدحام التي يحدث فيها فقد للحزم ؛
- زيادة كبيرة في الأداء والإنتاجية مقارنة بـ TCP. بالنسبة لخدمات الفيديو مثل YouTube، تبين أن QUIC يقلل من عمليات إعادة التخزين المؤقت عند مشاهدة مقاطع الفيديو بنسبة 30%.
المصدر: opennet.ru