نحو QUIC: ما الذي يكمن وراء HTTP / 3

يبدأ معلم جديد في تاريخ الإنترنت أمام أعيننا: يمكننا أن نفترض أنه تم بالفعل الإعلان عن HTTP / 3. في نهاية أكتوبر ، اقترح مارك نوتنغهام من IETF اتخاذ قرار بالفعل بشأن اسم البروتوكول الجديد الذي تم بناء IETF عليه منذ عام 2015. لذلك بدلاً من الأسماء المشابهة لـ QUIC ، ظهر HTTP / 3 بصوت عالٍ. لقد كتبت المنشورات الغربية بالفعل عن هذا وأكثر من مرة . بدأ تاريخ QUIC في أحشاء شركة Good في عام 2012 ، ومنذ ذلك الحين دعمت خوادم Google فقط اتصالات HTTP-over-QUIC ، ولكن الوقت مضى وبدأ بالفعل في تطبيق هذه التقنية (7 نوفمبر ، قام Facebook و LiteSpeed بإجراء أول تفاعل عبر HTTP / 3 ) ؛ وحالياً ، تبلغ حصة المواقع التي تدعم QUIC 1.2٪. وأخيرًا ، تتطلع مجموعة عمل WebRTC أيضًا إلى QUIC (بالإضافة إلى الاطلاع على واجهة برمجة تطبيقات QUIC ) ، لذلك في الفيديو / الصوت في الوقت الفعلي المتوقع في المستقبل ، ستمر عبر QUIC بدلاً من RTP / RTCP. لذلك ، قررنا أنه سيكون من الرائع الكشف عن تفاصيل IETF QUIC: خصيصًا لحبر ، قمنا بإعداد ترجمة للنقط الطويل i. استمتع!

QUIC (Quick UDP Internet Connections) هو بروتوكول طبقة نقل افتراضي جديد ومشفّر يحتوي على العديد من تحسينات HTTP: لتسريع حركة المرور وزيادة الأمان. لدى QUIC أيضًا هدف طويل المدى - وهو استبدال TCP و TLS في النهاية. في هذه المقالة ، سنلقي نظرة على كل من شرائح QUIC الرئيسية وسبب استفادة الويب منها ، بالإضافة إلى مشاكل دعم هذا البروتوكول الجديد تمامًا.

في الواقع ، هناك بروتوكولان يحملان نفس الاسم: Google QUIC (gQUIC) ، وهو البروتوكول الأصلي الذي طوره مهندسو Google منذ عدة سنوات ، والذي تم اعتماده بعد سلسلة من التجارب بواسطة فريق هندسة الإنترنت (IETF) للتوحيد القياسي.

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

لذا ، ما هي التحسينات التي تقدمها QUIC؟

الأمن المتكامل (والأداء)

أحد أهم الاختلافات الملحوظة بين QUIC و TCP الموقر هو الهدف المعلن أصلاً لكونه بروتوكول نقل آمن افتراضيًا . يحقق QUIC ذلك باستخدام المصادقة والتشفير ، والذي يحدث عادة على مستوى أعلى (على سبيل المثال ، في TLS) ، وليس في بروتوكول النقل نفسه.

تجمع مصافحة QUIC الأصلية بين الاتصال ثلاثي الاتجاهات المعتاد عبر TCP مع مصافحة TLS 1.3 ، التي توفر مصادقة المشاركين ، بالإضافة إلى تنسيق معلمات التشفير. بالنسبة لأولئك الذين هم على دراية بـ TLS: يستبدل QUIC مستوى تسجيل TLS بتنسيق الإطار الخاص به ، ولكن في نفس الوقت يستخدم مصافحة TLS.

هذا لا يسمح فقط بتشفير الاتصال ومصادقته دائمًا ، ولكن أيضًا بشكل أسرع لإجراء الاتصال الأولي: إن تبادل تأكيد الاتصال العادي QUIC يجعل التبادل بين العميل والخادم بتمريرة واحدة ، بينما يقوم TCP + TLS 1.3 بإجراء مرورين.


ومع ذلك ، يذهب QUIC إلى أبعد من ذلك كما يقوم بتشفير بيانات تعريف الاتصال التي يمكن اختراقها بسهولة من قبل طرف ثالث. على سبيل المثال ، يمكن للمهاجمين استخدام أرقام الحزم لتوجيه المستخدمين عبر مسارات شبكة متعددة عند استخدام ترحيل الاتصال (انظر أدناه). يشفر QUIC أرقام الحزم ، لذلك لا يمكن تصحيحها من قبل أي شخص آخر غير المشاركين الحقيقيين في الاتصال.

يمكن أن يكون التشفير فعالًا أيضًا ضد "الركود" - وهي ظاهرة لا تسمح باستخدام مرونة البروتوكول عمليًا بسبب الافتراضات غير الصحيحة في عمليات التنفيذ (التعظم - لهذا السبب تم وضع TLS 1.3 لفترة طويلة . لقد قمنا بنشره فقط بعد بعض التغييرات التي منع الكتل غير المرغوب فيها لمراجعات TLS الجديدة).

حجب بداية الطابور (حجب رأس الخط)

أحد التحسينات الرئيسية التي جلبها لنا HTTP / 2 هي القدرة على الجمع بين طلبات HTTP المختلفة في اتصال TCP واحد. يسمح هذا لتطبيقات HTTP / 2 بمعالجة الطلبات بالتوازي والاستفادة بشكل أفضل من قناة الشبكة.

بالطبع ، كانت هذه خطوة مهمة إلى الأمام. نظرًا لأن التطبيقات السابقة كانت بحاجة إلى بدء العديد من اتصالات TCP + TLS إذا أرادت معالجة العديد من طلبات HTTP في نفس الوقت (على سبيل المثال ، عندما يحتاج المتصفح إلى تلقي CSS وجافا سكريبت لعرض الصفحة). يتطلب إنشاء اتصالات جديدة مصافحات متعددة ، بالإضافة إلى تهيئة نافذة التحميل الزائد: وهذا يعني إبطاء عرض الصفحة. تجنب طلبات HTTP المدمجة ذلك.



ومع ذلك ، هناك عيب: نظرًا لأن العديد من الطلبات / الاستجابات يتم إرسالها عبر نفس اتصال TCP ، فإنها تعتمد بشكل متساوٍ على فقدان الحزمة ، حتى إذا كانت البيانات المفقودة تتعلق بواحد فقط من الطلبات. وهذا ما يسمى "منع بداية قائمة الانتظار".

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

وبالتالي ، من الممكن تقليل الوقت بشكل كبير ، على سبيل المثال ، للعرض الكامل لصفحة الويب (CSS وجافا سكريبت والصور والموارد الأخرى) ، خاصة في حالة الشبكة الزائدة مع فقدان حزم عالية.

بهذه البساطة ، هاه؟

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

تم تصميم QUIC ليتم تسليمه عبر مخططات بيانات UDP لتسهيل التطوير وتجنب المشاكل مع أجهزة الشبكة التي تسقط حزم البروتوكولات غير المعروفة (لأن معظم الأجهزة تدعم UDP). كما يسمح لـ QUIC بالعيش في مساحة المستخدم ، لذلك ، على سبيل المثال ، ستتمكن المتصفحات من تنفيذ ميزات البروتوكول الجديدة ونقلها إلى المستخدمين النهائيين ، دون انتظار تحديثات نظام التشغيل.

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

واحد NAT للاجتماع معًا والتوحد بإرادة سوداء واحدة

بشكل عام ، تعمل أجهزة توجيه NAT مع اتصالات TCP باستخدام مجموعة من 4 قيم (IP المصدر والمنفذ بالإضافة إلى IP ومنفذ الوجهة) ، بالإضافة إلى مراقبة حزم TCP SYN و ACK و FIN المرسلة عبر الشبكة ؛ يمكن لأجهزة التوجيه تحديد وقت إنشاء اتصال جديد ومتى ينتهي. لذلك ، من الممكن إدارة دقيقة لربط NAT (الاتصالات بين IP الداخلية والخارجية والمنافذ).

في حالة QUIC ، هذا غير ممكن ، لأنه لا تعرف أجهزة توجيه NAT الحديثة حتى الآن عن QUIC ، لذلك عادة ما يتم الرجوع إلى الإصدار الافتراضي ومعالجة UDP الأقل دقة ، مما يعني انتهاء مهلة التعسفي (أحيانًا قصيرة) ، والتي يمكن أن تؤثر على الاتصالات طويلة المدى.

عند حدوث إعادة ربط (على سبيل المثال ، بسبب انتهاء المهلة) ، يبدأ الجهاز خارج محيط NAT في تلقي الحزم من مصدر آخر ، مما يجعل من المستحيل الحفاظ على الاتصال باستخدام مجموعة من 4 قيم فقط.


وهي ليست NAT فقط! إحدى ميزات QUIC تسمى ترحيل الاتصال وتسمح للأجهزة بنقل الاتصالات إلى عناوين / مسارات IP الأخرى حسب تقديرها. على سبيل المثال ، سيتمكن عميل الهاتف المحمول من نقل اتصال QUIC من شبكة هاتف محمول إلى شبكة WiFi معروفة بالفعل (دخل المستخدم إلى مقهى مفضل ، وما إلى ذلك).

تحاول QUIC حل هذه المشكلة بمفهوم معرف الاتصال: معلومة ذات طول عشوائي ، يتم إرسالها في حزم QUIC والسماح بتحديد الاتصال. يمكن لأجهزة Endpoint استخدام هذا المعرّف لتتبع اتصالاتها دون التصالح مع tuple. من الناحية العملية ، يجب أن يكون هناك العديد من المعرفات التي تشير إلى نفس الاتصال ، على سبيل المثال ، لتجنب توصيل مسارات مختلفة عند ترحيل الاتصال - لأن العملية بأكملها يتم التحكم فيها فقط من خلال الأجهزة النهائية ، وليس من خلال الصناديق الوسطى.

ومع ذلك ، قد تكون هناك مشكلة لمشغلي الاتصالات الذين يستخدمون أي بث وتوجيه ECMP ، حيث يمكن أن يحدد عنوان IP واحد مئات أو الآلاف من الخوادم. نظرًا لأن أجهزة توجيه الحدود في هذه الشبكات لا تعرف حتى الآن كيفية معالجة حركة مرور QUIC ، فقد يحدث أن يتم إرسال حزم UDP من نفس اتصال QUIC ، ولكن مع مجموعات مختلفة ، إلى خوادم مختلفة ، مما يعني قطع الاتصال.



لتجنب ذلك ، قد يحتاج المشغلون إلى تطبيق موازن أكثر ذكاءً. يمكن تحقيق ذلك برمجيًا دون التأثير على أجهزة التوجيه الحدودية نفسها (على سبيل المثال ، راجع مشروع Katran من Facebook).

Qpack

ميزة أخرى مفيدة لـ HTTP / 2 هي ضغط الرأس (HPACK) ، والتي تسمح للأجهزة النهائية بتقليل حجم البيانات التي يتم إرسالها عن طريق تجاهل الطلبات والاستجابات غير الضرورية.

على وجه الخصوص ، من بين التقنيات الأخرى ، تستخدم HPACK جداول ديناميكية مع رؤوس تم إرسالها / تلقيها بالفعل من طلبات / استجابات HTTP السابقة ، مما يسمح للأجهزة بالإشارة في الطلبات / الاستجابات الجديدة إلى الرؤوس التي تمت مواجهتها سابقًا (بدلاً من إرسالها مرة أخرى) .

يجب مزامنة جداول HPACK بين المشفر (الطرف الذي يرسل الطلب / الاستجابة) ومفكك التشفير (الجانب المستقبل) ، وإلا فإن وحدة فك التشفير لا يمكنها ببساطة فك تشفير ما تستقبله.

في حالة HTTP / 2 عبر TCP ، تكون هذه المزامنة شفافة لأن طبقة النقل (TCP) تقدم الطلبات / الاستجابات بنفس الترتيب الذي تم إرسالها به. أي أنه يمكنك إرسال تعليمات إلى وحدة فك الترميز لتحديث الجداول في طلب / رد بسيط. ولكن مع QUIC ، تصبح الأمور أكثر تعقيدًا.

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

على سبيل المثال ، إذا أرسل العميل طلب HTTP A في الدفق QUIC A ، بالإضافة إلى الطلب B في الدفق B ، فبسبب تبويب الحزمة أو خسائر الشبكة ، سيتلقى الخادم الطلب B قبل الطلب A. وإذا تم ترميز الطلب B على أنه تمت الإشارة إليه في رأس الطلب "أ" ، فلن يتمكن الخادم ببساطة من فك ترميز الطلب "ب" ، حيث إنه لم يرَ الطلب "أ" بعد.

حل بروتوكول gQUIC هذه المشكلة ببساطة عن طريق جعل جميع رؤوس طلبات HTTP / الردود المتسلسلة ( وليس نصوصها) متسلسلة ضمن تدفق gQUIC واحد. هذا يضمن أن جميع الرؤوس تأتي بالترتيب الصحيح ، بغض النظر عما يحدث. هذا مخطط بسيط للغاية ، بمساعدته ، يمكن للحلول الحالية أن تستمر في استخدام التعليمات البرمجية التي تم صقلها تحت HTTP / 2 ؛ من ناحية أخرى ، هذا يزيد من احتمال حجب بداية قائمة الانتظار ، والتي تم تصميم QUIC للحد منها. لذلك ، قامت مجموعة عمل IETF QUIC بتطوير تعيين جديد بين HTTP و QUIC (HTTP / QUIC) ، بالإضافة إلى مبدأ ضغط رأس جديد ، QPACK.

في المسودة النهائية لمواصفات HTTP / QUIC و QPACK ، يستخدم كل تبادل طلب / استجابة HTTP تدفق QUIC ثنائي الاتجاه الخاص به ، لذلك لا يتم حظر بدء قائمة الانتظار. أيضًا ، من أجل دعم QPACK ، يقوم كل مشارك بإنشاء تدفقات QUIC إضافية أحادية الاتجاه ، أحدهما لإرسال تحديثات الجدول ، والآخر لتأكيد الاستلام. وبالتالي ، لا يمكن لبرنامج التشفير QPACK استخدام الرابط إلى الجدول الديناميكي إلا بعد تأكيد مفكك التشفير على استلامه.

الانكسار الانكسار

مشكلة شائعة في البروتوكولات المستندة إلى UDP هي قابليتها لهجمات الانعكاس ، عندما يجبر المهاجم الخادم على إرسال كمية كبيرة من البيانات إلى الضحية. يقوم المهاجم بانتحال عنوان IP الخاص به بحيث يعتقد الخادم أن طلب البيانات جاء من عنوان الضحية.


يمكن أن يكون هذا النوع من الهجوم فعّالًا للغاية عندما تكون استجابة الخادم أكبر من الطلب. في هذه الحالة ، يتحدثون عن "الكسب".

لا يتم استخدام بروتوكول TCP عادةً لمثل هذه الهجمات ، لأن الحزم في مصافحة اليد الأصلية (SYN ، SYN + ACK ، ...) لها نفس الطول ، لذلك ليس لديها إمكانية "التضخيم".

من ناحية أخرى ، فإن مصافحة QUIC غير متماثلة للغاية: كما هو الحال في TLS ، يرسل خادم QUIC أولاً سلسلة الشهادات الخاصة به ، والتي يمكن أن تكون كبيرة جدًا ، على الرغم من حقيقة أن العميل يجب أن يرسل عددًا قليلاً من وحدات البايت (رسالة من عميل ClientHello TLS مدمجة في حزمة QUIC ) لهذا السبب ، يجب زيادة حزمة QUIC الأصلية إلى حد أدنى معين للطول ، حتى إذا كانت محتويات الحزمة أصغر بكثير. مع ذلك ، لا يزال هذا الإجراء غير فعال للغاية ، نظرًا لأن استجابة الخادم النموذجية تحتوي على عدة حزم وبالتالي قد تكون أكثر من حزمة عميل موسعة.

يحدد بروتوكول QUIC أيضًا آلية التحقق من المصدر الصريح: فبدلاً من إعطاء استجابة كبيرة ، يرسل الخادم حزمة إعادة محاولة فقط برمز فريد ، يرسله العميل بعد ذلك إلى الخادم في حزمة جديدة. لذا فإن الخادم لديه ثقة أكبر في أن العميل ليس لديه عنوان IP بديل ويمكنك إنهاء المصافحة. ناقص القرار - يزيد وقت المصافحة ، بدلاً من تمرير واحد ، مطلوب بالفعل اثنين.

الحل البديل هو تقليل استجابة الخادم لحجم يصبح فيه هجوم الانعكاس أقل فعالية - على سبيل المثال ، باستخدام شهادات ECDSA (عادة ما تكون أصغر بكثير من RSA). لقد جربنا أيضًا آلية ضغط شهادة TLS باستخدام خوارزميات ضغط جاهزة مثل zlib و brotli ؛ هذه ميزة ظهرت لأول مرة في gQUIC ولكنها غير مدعومة حاليًا في TLS.

أداء UDP

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

ومع ذلك ، فهي مسألة وقت فقط قبل أن تتجاوز تطبيقات QUIC هذه التحسينات والفوائد. ألق نظرة على الجهود الأخيرة لتنفيذ إلغاء تحميل UDP على Linux ، الأمر الذي سيسمح للتطبيقات بدمج ونقل العديد من مقاطع UDP بين مساحة المستخدم ومكدس الشبكة kernel-space بتكلفة حوالي قطعة واحدة ؛ مثال آخر هو دعم النسخ المبتكر للمقابس على Linux ، بفضل التطبيقات التي يمكنها تجنب تكلفة نسخ ذاكرة مساحة المستخدم إلى مساحة kernel.

الخلاصة

مثل HTTP / 2 و TLS 1.3 ، يجب أن يجلب بروتوكول QUIC الكثير من الميزات الجديدة التي ستحسن أداء وأمان كل من مواقع الويب والمشاركين الآخرين في البنية التحتية للإنترنت. تنوي مجموعة عمل IETF طرح الإصدار الأول من مواصفات QUIC بحلول نهاية العام ، لذلك حان الوقت للتفكير في كيفية تحقيق أقصى استفادة من مزايا QUIC.