لقد مرت ثلاث سنوات ونصف منذ اعتماد معيار HTTP / 2: تم نشر مواصفات RFC 7540 في مايو 2015 ، ولكن لم يتم استخدامها بعد في كل مكان. تم تنفيذ البروتوكول في جميع المتصفحات منذ نهاية عام 2015 ، وبعد ثلاث سنوات ، يدعم 31.2٪ فقط من المواقع الـ 10 الأكثر شعبية على الإنترنت HTTP / 2. من أكثر المواقع شعبية ، تحولت Google و Youtube و Wikipedia و Twitter و Vk.com وغيرها إلى ذلك.

ومع ذلك ، لا يقف التقدم ثابتًا - والعمل جار بالفعل على الإصدار التالي من HTTP / 3. كما أصبح معروفًا الآن ، حقق مطورو خيارين بديلين التوافق ، ويغير بروتوكول HTTP-over-QUIC الآن اسمه ويسمى رسميًا HTTP / 3 . وفقًا لذلك ، في إصدار مستقبلي من HTTP ، سيتم استبدال نقل TCP بـ QUIC.

الخلط بين خيارات QUIC المختلفة

QUIC هو بديل TCP يعمل على UDP. في البداية ، تم إنشاء هذه التقنية من قبل مهندسي Google ، مثل بروتوكول SPDY السابق ، الذي أصبح أساس HTTP / 2. في البداية ، كانت QUIC تسمى "HTTP / 2-encrypted-over-UDP".

ثم تم نقل تطوير QUIC إلى IETF من أجل التوحيد القياسي. هنا تم تقسيمها إلى قسمين: النقل و HTTP. الفكرة هي أنه يمكن أيضًا استخدام بروتوكول النقل لنقل البيانات الأخرى ، وليس فقط حصريًا لبروتوكولات HTTP أو HTTP. ومع ذلك ، يظل الاسم كما هو: QUIC. تم تطوير بروتوكول النقل بواسطة مجموعة عمل QUIC التابعة لمجلس هندسة الإنترنت (IETF).

في الوقت نفسه ، واصلت Google العمل على تنفيذها - ونفذته في متصفح Chrome. على الرغم من أن الاختبارات تُظهر أن تنفيذ QUIC من Google أسوأ بكثير من TCP ، إذا كانت الشبكة لا تضمن تسليم الحزم .


فرق الأداء بين QUIC مع TCP (في المائة) على شبكة ذات 112 ms RTT و 10 ms jitter jitter ، المصدر


فرق الأداء بين QUIC مع TCP (في المئة) على شبكة مع RTT 112 ms و 10 ms jitter ، مما يغير ترتيب الحزم ، المصدر

يصف بعض المطورين عمومًا أي إصدار من QUIC على UDP بأنه "تجربة أكثر وحشية" .

يتم شرح الخلاف في إصدارات QUIC والتسمية من قبل دانييل ستينبيرج ، مطور تجعيد الشعر الرئيسي في Mozilla الذي يتابع هذه القصة لفترة طويلة.

ووفقًا له ، فقد انتشرت الأسماء غير الرسمية لنسختين من QUIC بين المطورين ، حيث تختلف الخيارات من IETF و Google بشكل كبير في تفاصيل التنفيذ:

• iQUIC (إصدار IETF)
• gQUIC (إصدار Google)

لطالما كان بروتوكول إرسال HTTP عبر iQUIC (إصدار IETF) يسمى "hq" (HTTP-over-QUIC).

بشكل عام ، لم يكن هناك اسم ثابت لإصدارات مختلفة. في ندوة ورشة عمل QUIC ، أخاف مايك بيشوب الجميع بشريحة مثل الشعار.


شريحة من عرض مايك بيشوب

طلب ميسرو ورشة العمل من مايك عدم عرضها مرة أخرى .

ومع ذلك ، في 7 نوفمبر 2018 ، أعلن أحد المطورين الرائدين للبروتوكول ، دميتري تيخونوف ، أن LiteSpeed ​​Tech و Facebook حققوا توافق البروتوكول ، والآن سيستمر التطوير على نفس المنوال.

تم الجمع بين iQUIC و gQUIC المسمى HTTP / 3 في سبتمبر اقترحه مارك نوتنغهام ، أحد أكثر مهندسي IETF تأثيرًا ، والمؤلف المشارك للعديد من معايير الويب. ووفقا له ، فإن هذا سيساعد على القضاء على الخلط بين نقل QIUC ومجمع QUIC لـ HTTP.

وبالتالي ، فإن HTTP / 3 هو الإصدار الجديد من HTTP الذي سيستخدم النقل QUIC .

النقل QUIC

ما هي مزايا بروتوكول النقل QUIC عبر TCP؟ هناك العديد من المزايا ، ووفقًا لمارك نوتينجهام نفسه ، فإن الانتقال من بروتوكول TCP القديم إلى البروتوكولات الجديدة أمر لا مفر منه ، حيث أصبح من الواضح الآن أن برنامج التعاون الفني يعاني من مشاكل عدم الكفاءة.

"بما أن TCP هو بروتوكول تسليم حزم بالترتيب ، فقد يتداخل فقد حزمة واحدة مع تسليم الحزم اللاحقة من المخزن المؤقت إلى التطبيق. في بروتوكول متعدد الإرسال ، يمكن أن يؤدي هذا إلى خسارة كبيرة في الأداء "، يوضح مارك نوتنغهام. "تحاول QUIC حل هذه المشكلة عن طريق إعادة بناء دلالات TCP بشكل فعال (إلى جانب بعض جوانب نموذج دفق HTTP / 2) عبر UDP."



بالإضافة إلى تبديل كمية كبيرة من حركة المرور من TCP إلى UDP ، يتطلب كل من Google QUIC (gQUIC) و IETF QUIC (iQUIC) تشفيرًا إلزاميًا: لا يوجد QUIC غير مشفر على الإطلاق . يستخدم iQUIC TLS 1.3 لتعيين مفاتيح الجلسة ثم تشفير كل حزمة. ولكن نظرًا لأنه يستند إلى UDP ، يتم تشفير الكثير من معلومات الجلسة والبيانات الوصفية المفتوحة في TCP في QUIC.

في مقالة "مستقبل بروتوكولات الإنترنت" ، يتحدث مارك نوتنجهام عن التحسينات الأمنية المهمة مع التحول إلى QUIC:

في الواقع ، فإن iQUIC الحالي "رأس قصير" - الذي يستخدم لجميع الحزم باستثناء المصافحة - يعطي فقط رقم الحزمة ومعرف الاتصال الاختياري وبايت الحالة ، وهو ضروري لعمليات مثل تغيير مفاتيح التشفير ونوع الحزمة (والتي يمكن أيضًا تشفيرها). كل شيء آخر مشفر - بما في ذلك حزم ACK ، التي ترفع بشكل كبير من مستوى الهجمات مع تحليل حركة المرور .

بالإضافة إلى ذلك ، يصبح من المستحيل تقييم RTT وخسارة الحزم بشكل سلبي بمجرد مراقبة الاتصال ؛ لا توجد معلومات كافية لذلك.

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

أحد الاقتراحات لحل هذه المشكلة هو إدخال بت تدور . هذا قليلاً في العنوان الذي يغير قيمته مرة واحدة في رحلة ذهاب وعودة ، بحيث يمكن للمراقب تقييم RTT. نظرًا لأنه غير مرتبط بحالة التطبيق ، يجب ألا ينتج أي معلومات حول نقاط النهاية ، باستثناء تقدير تقريبي لموقع الشبكة.

ربما كان اعتماد معيار QUIC سيحدث في وقت سابق لو لم تتسرع Google في تنفيذ تطبيقه في متصفح Chrome ، لذا فإن الإصدار المحمي من iQUIC يمثل الآن أكثر من 7٪ من حركة المرور على الإنترنت.

ومع ذلك ، فإن التقدم أمر لا مفر منه - وفي السنوات القادمة ، سيستمر التقييس والتنفيذ الواسع النطاق لبروتوكولات الجيل الجديد المختلفة ، بما في ذلك HTTP / 3 حول نقل QUIC.

---