HTTP / 3: خيارات النشر العملية (الجزء 3)

مرحبًا ومرحبًا بكم في الجزء الأخير من هذه السلسلة المكونة من ثلاثة أجزاء حول بروتوكولات HTTP / 3 و QUIC الجديدة! إذا كنت مقتنعًا بعد الجزأين السابقين - تاريخ HTTP / 3 والمفاهيم الأساسية وخصائص أداء HTTP / 3 - أن البدء في استخدام البروتوكولات الجديدة فكرة جيدة (ويجب أن تكون كذلك!) ، فإن هذه القطعة الأخيرة تتضمن الكل عليك أن تعرف لكي تبدأ!

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

التغييرات على الصفحات والموارد

لنبدأ ببعض الأخبار الجيدة: إذا كنت تستخدم HTTP / 2 بالفعل ، فربما لن تضطر إلى تغيير أي شيء إلى صفحاتك أو مواردك عند الانتقال إلى HTTP / 3! . هذا لأنه ، كما أوضحنا في الجزء 1 والجزء 2 ، فإن HTTP / 3 يشبه حقًا HTTP / 2-over-QUIC ، وظلت الميزات عالية المستوى للإصدارين كما هي. على هذا النحو ، ستظل أي تغييرات أو تحسينات تم إجراؤها على HTTP / 2 تعمل مع HTTP / 3 والعكس صحيح.

ومع ذلك ، إذا كنت لا تزال تستخدم HTTP / 1.1 ، أو نسيت انتقالك إلى HTTP / 2 ، أو لم تقم أبدًا بتعديل الأشياء لـ HTTP / 2 ، فقد تتساءل عن ماهية هذه التغييرات ولماذا كانت مطلوبة. ومع ذلك ، ستتعرض لضغوط شديدة حتى اليوم للعثور على مقال جيد يعرض تفاصيل أفضل الممارسات الدقيقة . هذا لأنه ، كما ذكرت في مقدمة الجزء الأول ، كان الكثير من محتوى HTTP / 2 المبكر مفرطًا في التفاؤل بشأن مدى نجاحه في الممارسة ، وبعضها ، بصراحة تامة ، كان به أخطاء كبيرة ونصائح سيئة. للأسف ، لا يزال الكثير من هذه المعلومات المضللة قائمًا حتى يومنا هذا. هذا أحد دوافعي الرئيسية في كتابة هذه السلسلة على HTTP / 3 ، للمساعدة في منع حدوث ذلك مرة أخرى.

أفضل مصدر دقيق متعدد الإمكانات لـ HTTP / 2 يمكنني أن أوصي به في هذا الوقت هو كتاب HTTP / 2 in Action من تأليف Barry Pollard. ومع ذلك ، نظرًا لأن هذا مورد مدفوع ولا أريدك أن تترك تخمينًا هنا ، فقد قمت بإدراج بعض النقاط الرئيسية أدناه ، جنبًا إلى جنب مع كيفية ارتباطها بـ HTTP / 3:

1. اتصال واحد

كان الاختلاف الأكبر بين HTTP / 1.1 و HTTP / 2 هو التبديل من 6 إلى 30 وصلة TCP متوازية إلى اتصال TCP أساسي واحد. لقد ناقشنا قليلاً في الجزء 2 كيف يمكن أن يظل الاتصال الفردي بنفس سرعة الاتصالات المتعددة ، بسبب كيف يمكن أن يتسبب التحكم في الازدحام في فقد أكثر أو سابقًا للحزم مع المزيد من الاتصالات (مما يلغي فوائد البداية الأسرع المجمعة). يواصل HTTP / 3 هذا النهج ، ولكن "فقط" يقوم بالتبديل من اتصال TCP واحد إلى اتصال QUIC واحد. هذا الاختلاف في حد ذاته لا يفعل كل هذا القدر (فهو يقلل بشكل أساسي من الحمل على جانب الخادم) ، لكنه يؤدي إلى معظم النقاط التالية.

2. تجزئة الخادم ودمج الاتصال

كان التبديل إلى إعداد الاتصال الفردي صعبًا للغاية من الناحية العملية لأن العديد من الصفحات تم تقسيمها عبر أسماء مضيفين مختلفة وحتى خوادم (مثل img1.example.com و img2.example.com ). كان هذا بسبب أن المتصفحات فتحت فقط ما يصل إلى ستة اتصالات لكل اسم مضيف فردي ، لذلك سمح بعدة اتصالات لمزيد من الاتصالات! بدون تغييرات على إعداد HTTP / 1.1 هذا ، سيظل HTTP / 2 يفتح اتصالات متعددة ، مما يقلل من مدى جودة عمل الميزات الأخرى ، مثل تحديد الأولويات (انظر أدناه).

على هذا النحو ، كانت التوصية الأصلية هي التراجع عن تجزئة الخادم ودمج الموارد على خادم واحد قدر الإمكان. قدم HTTP / 2 ميزة لجعل الانتقال من إعداد HTTP / 1.1 أسهل ، يُطلق عليه اتحاد الاتصال. بشكل تقريبي ، إذا تم حل اسمين مضيفين إلى نفس عنوان IP للخادم (باستخدام DNS) واستخدموا شهادة TLS مماثلة ، فيمكن للمتصفح إعادة استخدام اتصال واحد حتى عبر اسمي المضيفين .

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

3. تجميع الموارد والتضمين

في HTTP / 1.1 ، يمكن أن يكون لديك مورد نشط واحد فقط لكل اتصال ، مما يؤدي إلى حظر رأس الخط (HoL) على مستوى HTTP. نظرًا لأن عدد الاتصالات قد تم تحديده عند حد أدنى من 6 إلى 30 ، فإن تجميع الموارد (حيث يتم دمج المصادر الفرعية الأصغر في مورد واحد أكبر) كان أفضل ممارسة لفترة طويلة. ما زلنا نرى هذا اليوم في المجمعات مثل Webpack. وبالمثل ، غالبًا ما تم تضمين الموارد في موارد أخرى (على سبيل المثال ، تم تضمين CSS الحرجة في HTML).

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

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

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

4. تحديد الأولويات

لتتمكن من تنزيل ملفات متعددة على اتصال واحد ، تحتاج إلى تعدد إرسالها بطريقة أو بأخرى. كما تمت مناقشته في الجزء 2 ، في HTTP / 2 ، يتم توجيه تعدد الإرسال باستخدام نظام تحديد الأولويات الخاص به. هذا هو السبب في أنه من المهم أن يكون لديك أكبر عدد ممكن من الموارد المطلوبة على نفس الاتصال أيضًا - لتتمكن من ترتيب أولوياتها بشكل صحيح بين بعضها البعض! كما رأينا أيضًا ، كان هذا النظام معقدًا للغاية ، مما أدى إلى استخدامه بشكل سيئ وتنفيذه في الممارسة العملية (انظر الصورة أدناه). وهذا بدوره يعني أن بعض التوصيات الأخرى لـ HTTP / 2 - مثل تقليل الحزم ، لأن الطلبات رخيصة ، وتقليل تجزئة الخادم ، للاستفادة المثلى من الاتصال الفردي (انظر أعلاه) - تبين أنها ضعيفة الأداء في ممارسة.

للأسف ، هذا شيء لا يمكنك ، بصفتك مطور ويب متوسط ​​، أن تفعل الكثير بشأنه ، لأنه يمثل مشكلة بشكل أساسي في المتصفحات والخوادم نفسها. ومع ذلك ، يمكنك محاولة التخفيف من المشكلة من خلال عدم استخدام عدد كبير جدًا من الملفات الفردية (مما يقلل من فرص تنافس الأولويات) وباستمرار استخدام التجزئة (المحدودة). هناك خيار آخر وهو استخدام تقنيات مختلفة للتأثير على الأولوية ، مثل التحميل البطيء ، defer JavaScript غير async ، وتلميحات الموارد مثل preload . داخليًا ، تعمل هذه التغييرات بشكل أساسي على تغيير أولويات الموارد بحيث يتم إرسالها مبكرًا أو لاحقًا. ومع ذلك ، يمكن أن تعاني هذه الآليات (وهي كذلك) من الأخطاء. بالإضافة إلى ذلك ، لا تتوقع فرض preload على مجموعة من الموارد وتسريع الأمور: إذا أصبح كل شيء فجأة أولوية عالية ، فلا شيء! حتى أنه من السهل جدًا تأخير الموارد المهمة بالفعل باستخدام أشياء مثل preload .

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

5. دفع الخادم والرحلة الأولى

يسمح دفع الخادم للخادم بإرسال بيانات الاستجابة دون الانتظار أولاً لطلب من العميل. مرة أخرى ، يبدو هذا رائعًا من الناحية النظرية ، ويمكن استخدامه بدلاً من تضمين الموارد (انظر أعلاه). ومع ذلك ، كما تمت مناقشته في الجزء 2 ، من الصعب جدًا استخدام الدفع بشكل صحيح نظرًا لمشاكل التحكم في الازدحام والتخزين المؤقت وتحديد الأولويات والتخزين المؤقت. بشكل عام ، من الأفضل عدم استخدامه لتحميل صفحة الويب العامة إلا إذا كنت تعرف حقًا ما تفعله ، وحتى في هذه الحالة من المحتمل أن يكون تحسينًا دقيقًا. ما زلت أعتقد أنه يمكن أن يكون له مكان به واجهات برمجة تطبيقات (REST) ​​، حيث يمكنك دفع المصادر الفرعية المرتبطة في استجابة (JSON) على اتصال محسن. هذا صحيح لكل من HTTP / 2 و HTTP / 3.

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

ماذا يعني كل ذلك؟

يعود كل ما سبق إلى قاعدة بسيطة: قم بتطبيق معظم توصيات HTTP / 2 النموذجية التي تجدها عبر الإنترنت ، ولكن لا تأخذها إلى أقصى الحدود .

فيما يلي بعض النقاط الملموسة التي تحتوي في الغالب على كل من HTTP / 2 و HTTP / 3:

1. موارد Shard التي تزيد عن واحد إلى ثلاثة اتصالات على المسار الحرج (ما لم يكن المستخدمون في الغالب على شبكات ذات نطاق ترددي منخفض) ، باستخدام الاتصال المسبق preconnect dns-prefetch عند الحاجة.
2. حزم المصادر الفرعية منطقيًا لكل مسار أو ميزة ، أو لكل تردد تغيير. يجب أن يكون خمسة إلى عشرة JavaScript وخمسة إلى عشرة موارد CSS لكل صفحة على ما يرام. يمكن أن يظل تضمين CSS المهم تحسينًا جيدًا.
3. استخدم الميزات المعقدة ، مثل preload ، باعتدال.
4. استخدم خادمًا يدعم تحديد أولويات HTTP / 2 بشكل صحيح. بالنسبة لـ HTTP / 2 ، أوصي بـ H2O. غالبًا ما يكون Apache و NGINX على ما يرام (على الرغم من أنه يمكن أن يعمل بشكل أفضل) ، بينما يجب تجنب Node.js مع HTTP / 2. بالنسبة إلى HTTP / 3 ، تكون الأمور أقل وضوحًا في هذا الوقت (انظر أدناه).
5. تأكد من تمكين TLS 1.3 على خادم الويب HTTP / 2.

كما ترى ، على الرغم من أنه بعيد عن البساطة ، فإن تحسين الصفحات لـ HTTP / 3 (و HTTP / 2) ليس علمًا صارخًا. لكن الأمر الأكثر صعوبة هو إعداد خوادم وعملاء وأدوات HTTP / 3 بشكل صحيح.

الخوادم والشبكات

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

من أهمها واستقرارها ما يلي:

ومع ذلك ، فإن العديد (ربما معظم) من هذه التطبيقات تهتم بشكل أساسي بأشياء HTTP / 3 و QUIC ؛ هم ليسوا خوادم ويب كاملة في حد ذاتها . عندما يتعلق الأمر بخوادمك النموذجية (فكر في NGINX و Apache و Node.js) ، كانت الأمور أبطأ قليلاً ، لعدة أسباب. أولاً ، كان عدد قليل من مطوريهم متورطين في HTTP / 3 منذ البداية ، وعليهم الآن أن يلعبوا لعبة اللحاق بالركب. يتخطى الكثيرون ذلك باستخدام أحد التطبيقات المذكورة أعلاه داخليًا كمكتبات ، ولكن حتى هذا التكامل صعب.

ثانيًا ، تعتمد العديد من الخوادم على مكتبات TLS التابعة لجهات خارجية مثل OpenSSL. هذا ، مرة أخرى ، لأن TLS معقد للغاية ويجب أن يكون آمنًا ، لذلك من الأفضل إعادة استخدام العمل الحالي الذي تم التحقق منه. ومع ذلك ، بينما يتكامل QUIC مع TLS 1.3 ، فإنه يستخدمه بطرق تختلف كثيرًا عن كيفية تفاعل TLS و TCP . هذا يعني أن مكتبات TLS يجب أن توفر واجهات برمجة تطبيقات خاصة بـ QUIC ، والتي لطالما كان مطوروها مترددين أو بطيئين في القيام بها. المشكلة هنا بشكل خاص هي OpenSSL ، التي أجلت دعم QUIC ، لكنها تستخدم أيضًا من قبل العديد من الخوادم. أصبحت هذه المشكلة سيئة للغاية لدرجة أن Akamai قرر بدء تفرع خاص بـ QUIC من OpenSSL ، يسمى quictls. في حين أن الخيارات والحلول الأخرى موجودة ، فإن دعم TLS 1.3 لـ QUIC لا يزال مانعًا للعديد من الخوادم ، ومن المتوقع أن يظل كذلك لبعض الوقت.

فيما يلي قائمة جزئية بخوادم الويب الكاملة التي يجب أن تكون قادرًا على استخدامها خارج الصندوق ، إلى جانب دعم HTTP / 3 الحالي:

• اباتشي
  الدعم غير واضح في هذا الوقت. لم يتم الإعلان عن أي شيء. من المحتمل أيضًا أن تحتاج إلى OpenSSL. (لاحظ أن هناك تطبيق Apache Traffic Server ، بالرغم من ذلك).
• NGINX
  هذا هو تنفيذ مخصص. هذا جديد نسبيًا ولا يزال تجريبيًا للغاية. ومن المتوقع أن يتم دمجه في خط NGINX الرئيسي بحلول نهاية عام 2021. هذا جديد نسبيًا ولا يزال تجريبيًا للغاية. لاحظ أن هناك تصحيحًا لتشغيل مكتبة Cloudflare's quiche على NGINX أيضًا ، والتي ربما تكون أكثر استقرارًا في الوقت الحالي.
• Node.js
  يستخدم هذا مكتبة ngtcp2 داخليًا. تم حظره من خلال تقدم OpenSSL ، على الرغم من أنهم يخططون للتبديل إلى مفترق QUIC-TLS للحصول على شيء يعمل في وقت أقرب.
• IIS
  الدعم غير واضح في الوقت الحالي ، ولم يتم الإعلان عن أي شيء. من المحتمل أن تستخدم مكتبة MsQuic داخليًا ، على الرغم من ذلك.
• هايبركورن
  هذا يدمج aioquic ، مع الدعم التجريبي.
• العلبة
  هذا يستخدم quic-go ، مع دعم كامل.
• H2O
  هذا يستخدم بسرعة ، مع الدعم الكامل.
• لايت سبيد
  هذا يستخدم LSQUIC ، مع دعم كامل.

لاحظ بعض الفروق الدقيقة المهمة:

• حتى "الدعم الكامل" يعني "بالقدر الذي يحصل عليه في الوقت الحالي" ، وليس بالضرورة "جاهز للإنتاج". على سبيل المثال ، لا تدعم العديد من عمليات التنفيذ بالكامل حتى الآن ترحيل الاتصال أو 0-RTT أو دفع الخادم أو تحديد أولوية HTTP / 3 .
• الخوادم الأخرى غير المدرجة ، مثل Tomcat ، لم تصدر (على حد علمي) أي إعلان حتى الآن.
• من بين خوادم الويب المدرجة ، تم تصنيع Litespeed و تصحيح NGINX الخاص بـ Cloudflare و H2O بواسطة أشخاص مشاركين بشكل وثيق في معايير QUIC و HTTP / 3 ، لذلك من المرجح أن تعمل هذه بشكل أفضل في وقت مبكر.
  

كما ترى ، فإن منظر الخادم لم يكتمل بعد ، ولكن هناك بالتأكيد خيارات لإعداد خادم HTTP / 3. ومع ذلك ، فإن مجرد تشغيل الخادم ليس سوى الخطوة الأولى. يعد تكوينه وبقية شبكتك أكثر صعوبة.

تكوين شبكة

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

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

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

كل هذا معقد أكثر من خلال ميزة ترحيل الاتصال. كما رأينا ، تسمح هذه الميزة للاتصال بالاستمرار من عنوان IP جديد دون الحاجة إلى إجراء مصافحة جديدة ، باستخدام معرفات الاتصال (CIDs). ومع ذلك ، بالنسبة لجدار الحماية ، سيبدو هذا كما لو تم استخدام اتصال جديد دون استخدام المصافحة أولاً ، والتي قد تكون مجرد مهاجم يرسل حركة مرور ضارة. لا يمكن أن تستخدم جدران الحماية معرّفات QUIC CIDs فقط ، لأنها تتغير أيضًا بمرور الوقت لحماية خصوصية المستخدمين! على هذا النحو ، ستكون هناك بعض الحاجة إلى أن تتواصل الخوادم مع جدار الحماية الذي يُتوقع بشأن معرفات CID ، ولكن لا يوجد أي من هذه الأشياء حتى الآن.

هناك مخاوف مماثلة لموازنات الأحمال للإعدادات الكبيرة الحجم. توزع هذه الأجهزة الاتصالات الواردة عبر عدد كبير من الخوادم الخلفية. بالطبع ، يجب دائمًا توجيه حركة المرور لاتصال واحد إلى نفس الخادم الخلفي (لن يعرف الآخرون ماذا يفعلون به!). بالنسبة إلى TCP ، يمكن القيام بذلك ببساطة بناءً على 4-tuple ، لأن ذلك لا يتغير أبدًا. مع ترحيل اتصال QUIC ، لم يعد هذا خيارًا. مرة أخرى ، ستحتاج الخوادم وموازنات التحميل إلى الاتفاق بطريقة ما على معرفات CID التي يجب اختيارها للسماح بالتوجيه الحتمي . على عكس تكوين جدار الحماية ، هناك بالفعل اقتراح لإعداد هذا (على الرغم من أن هذا أبعد ما يكون عن التنفيذ على نطاق واسع).

أخيرًا ، هناك اعتبارات أمنية أخرى ذات مستوى أعلى ، خاصة حول هجمات 0-RTT وهجمات رفض الخدمة الموزعة (DDoS). كما تمت مناقشته في الجزء 2 ، يتضمن QUIC عددًا قليلاً من عوامل التخفيف لهذه المشكلات بالفعل ، ولكن من الناحية المثالية ، سيستخدمون أيضًا خطوط دفاع إضافية على الشبكة. على سبيل المثال ، قد تحظر خوادم الوكيل أو الطرفية طلبات 0-RTT معينة من الوصول إلى الأطراف الخلفية الفعلية لمنع هجمات إعادة التشغيل. بدلاً من ذلك ، لمنع هجمات الانعكاس أو هجمات DDoS التي ترسل فقط حزمة المصافحة الأولى ثم تتوقف عن الرد (يسمى تدفق SYN في TCP) ، يتضمن QUIC ميزة إعادة المحاولة. يسمح هذا للخادم بالتحقق من أنه عميل حسن التصرف ، دون الحاجة إلى الاحتفاظ بأي حالة في هذه الأثناء (ما يعادل ملفات تعريف ارتباط TCP SYN). تحدث عملية إعادة المحاولة هذه بشكل أفضل ، بالطبع ، في مكان ما قبل خادم النهاية - على سبيل المثال ، عند موازن التحميل. مرة أخرى ، يتطلب هذا تكوينًا واتصالًا إضافيًا للإعداد.

هذه ليست سوى أبرز المشكلات التي سيواجهها مسؤولو النظام والشبكة مع QUIC و HTTP / 3. هناك العديد من الأشياء الأخرى التي تحدثت عنها. هناك أيضًا نوعان من المستندات المصاحبة المنفصلة لـ QUIC RFCs التي تناقش هذه المشكلات والتخفيف المحتمل (الجزئي).

ماذا يعني كل ذلك؟

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

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

على هذا النحو ، خاصة في الأيام الأولى ، من الأفضل الاعتماد على شركة استضافة كبيرة أو CDN لإعداد البروتوكولات وتكوينها لك. كما تمت مناقشته في الجزء 2 ، هذا هو المكان الذي من المرجح أن تؤتي فيه QUIC ثمارها على أي حال ، واستخدام CDN هو أحد تحسينات الأداء الرئيسية التي يمكنك القيام بها. أوصي شخصيًا باستخدام Cloudflare أو Fastly لأنهم شاركوا بشكل وثيق في عملية التقييس وسيكون لديهم أكثر التطبيقات تقدمًا وضبطًا متاحة.

العملاء و QUIC Discovery

حتى الآن ، نظرنا في دعم جانب الخادم وداخل الشبكة للبروتوكولات الجديدة. ومع ذلك ، يجب أيضًا التغلب على العديد من المشكلات من جانب العميل.

قبل البدء في ذلك ، لنبدأ ببعض الأخبار الجيدة: معظم المتصفحات الشعبية لديها بالفعل (تجريبي) دعم HTTP / 3! على وجه التحديد ، في وقت كتابة هذا التقرير ، إليك حالة الدعم (انظر أيضًا caniuse.com):

• Google Chrome (الإصدار 91+) : ممكّن افتراضيًا.
• Mozilla Firefox (الإصدار 89+) : ممكّن افتراضيًا.
• Microsoft Edge (الإصدار 90+) : ممكّن افتراضيًا (يستخدم Chromium داخليًا).
• Opera (الإصدار 77+) : ممكّن افتراضيًا (يستخدم Chromium داخليًا).
• Apple Safari (الإصدار 14) : خلف العلم اليدوي. سيتم تمكينه افتراضيًا في الإصدار 15 ، الموجود حاليًا في معاينة التقنية.
• متصفحات أخرى : لا توجد إشارات حتى الآن على دراية بها (على الرغم من أن المتصفحات الأخرى التي تستخدم Chromium داخليًا ، مثل Brave ، يمكنها ، من الناحية النظرية ، أن تبدأ أيضًا في تمكينه).

لاحظ بعض الفروق الدقيقة:

• يتم طرح معظم المتصفحات تدريجيًا ، حيث لن يحصل جميع المستخدمين على دعم HTTP / 3 ممكّنًا افتراضيًا من البداية. يتم إجراء ذلك للحد من المخاطر التي يمكن أن تؤثر على خطأ واحد تم تجاهله على العديد من المستخدمين أو زيادة تحميل عمليات نشر الخادم. على هذا النحو ، هناك احتمال ضئيل ، حتى في إصدارات المستعرض الحديثة ، ألا تحصل على HTTP / 3 افتراضيًا وسيتعين عليك تمكينه يدويًا.
• كما هو الحال مع الخوادم ، لا يعني دعم HTTP / 3 أنه تم تنفيذ جميع الميزات أو يتم استخدامها في هذا الوقت. على وجه الخصوص ، قد يظل 0-RTT وترحيل الاتصال ودفع الخادم وضغط رأس QPACK الديناميكي وتحديد أولويات HTTP / 3 مفقودة أو معطلة أو مستخدمة بشكل مقتصد أو سيئة التكوين.
• إذا كنت ترغب في استخدام HTTP / 3 من جانب العميل خارج المتصفح (على سبيل المثال ، في تطبيقك الأصلي) ، فسيتعين عليك دمج إحدى المكتبات المدرجة أعلاه أو استخدام cURL. ستقدم Apple قريبًا دعم HTTP / 3 و QUIC الأصلي إلى مكتبات الشبكات المضمنة الخاصة بها على macOS و iOS ، وتضيف Microsoft QUIC إلى Windows kernel وبيئة .NET الخاصة بهم ، لكن الدعم الأصلي المماثل (على حد علمي) لم يكن كذلك أعلن عن أنظمة أخرى مثل Android.

Alt-Svc

حتى إذا قمت بإعداد خادم متوافق مع HTTP / 3 وكنت تستخدم متصفحًا محدثًا ، فقد تفاجأ عندما تجد أن HTTP / 3 لا يتم استخدامه فعليًا بشكل ثابت . لفهم السبب ، لنفترض أنك المتصفح للحظة. لقد طلب المستخدم الخاص بك أن تنتقل إلى example.com (موقع ويب لم تزره من قبل من قبل) ، وقد استخدمت DNS لتحليل ذلك إلى عنوان IP. تقوم بإرسال واحد أو أكثر من حزم مصافحة QUIC إلى عنوان IP هذا. الآن يمكن أن تسوء عدة أشياء:

1. قد لا يدعم الخادم QUIC.
2. قد تحظر إحدى الشبكات أو جدران الحماية الوسيطة QUIC و / أو UDP تمامًا.
3. قد يتم فقد حزم المصافحة أثناء النقل.

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

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

على هذا النحو ، بالنسبة لـ QUIC و HTTP / 3 ، تفضل المتصفحات تشغيلها بأمان وتجربة QUIC فقط إذا كانوا يعرفون أن الخادم يدعمها . على هذا النحو ، في المرة الأولى التي يتم فيها الاتصال بخادم جديد ، لن يستخدم المتصفح سوى HTTP / 2 أو HTTP / 1.1 عبر اتصال TCP. يمكن للخادم بعد ذلك السماح للمتصفح بمعرفة أنه يدعم أيضًا HTTP / 3 للاتصالات اللاحقة. يتم ذلك عن طريق تعيين رأس HTTP خاص على الاستجابات المرسلة عبر HTTP / 2 أو HTTP / 1.1. يسمى هذا العنوان Alt-Svc ، والذي يرمز إلى "الخدمات البديلة". يمكن استخدام Alt-Svc للسماح للمتصفح بمعرفة أن خدمة معينة يمكن الوصول إليها أيضًا عبر خادم آخر (IP و / أو منفذ) ، ولكنه يسمح أيضًا بالإشارة إلى البروتوكولات البديلة. يمكن ملاحظة ذلك أدناه في الشكل 1.

عند استلام رأس Alt-Svc صالح يشير إلى دعم HTTP / 3 ، سيقوم المتصفح بتخزين هذا مؤقتًا ومحاولة إعداد اتصال QUIC من ذلك الحين فصاعدًا. سيقوم بعض العملاء بذلك في أسرع وقت ممكن (حتى أثناء تحميل الصفحة الأولية - انظر أدناه) ، بينما سينتظر الآخرون حتى يتم إغلاق اتصال (اتصالات) TCP الحالي. هذا يعني أن المتصفح لن يستخدم HTTP / 3 إلا بعد أن يقوم بتنزيل بعض الموارد على الأقل عبر HTTP / 2 أو HTTP / 1.1 أولاً . حتى ذلك الحين ، ليس الأمر سلسًا. يعرف المتصفح الآن أن الخادم يدعم HTTP / 3 ، لكن هذا لا يعني أن الشبكة الوسيطة لن تحظره. على هذا النحو ، لا تزال هناك حاجة إلى سباقات الاتصال في الممارسة. لذلك ، قد لا يزال ينتهي بك الأمر باستخدام HTTP / 2 إذا أخرت الشبكة بطريقة ما مصافحة QUIC بدرجة كافية. بالإضافة إلى ذلك ، إذا فشل اتصال QUIC في التأسيس عدة مرات متتالية ، فإن بعض المتصفحات ستضع إدخال ذاكرة التخزين المؤقت Alt-Svc في قائمة denylist لبعض الوقت ، دون تجربة HTTP / 3 لفترة من الوقت. على هذا النحو ، قد يكون من المفيد مسح ذاكرة التخزين المؤقت للمتصفح يدويًا إذا كانت الأمور تعمل لأن ذلك يجب أن يفرغ أيضًا ارتباطات Alt-Svc . أخيرًا ، ثبت أن Alt-Svc يشكل بعض المخاطر الأمنية الجسيمة. لهذا السبب ، تفرض بعض المتصفحات قيودًا إضافية ، على سبيل المثال ، على المنافذ التي يمكن استخدامها (في Chrome ، يجب أن تكون خوادم HTTP / 2 و HTTP / 3 إما على منفذ أقل من 1024 أو كليهما على منفذ أعلى أو يساوي إلى 1024 ، وإلا سيتم تجاهل Alt-Svc ). يتنوع كل هذا المنطق ويتطور بشكل كبير بين المتصفحات ، مما يعني أن الحصول على اتصالات HTTP / 3 متسقة قد يكون أمرًا صعبًا ، مما يجعل اختبار الإعدادات الجديدة أمرًا صعبًا أيضًا.

هناك عمل مستمر لتحسين عملية Alt-Svc من خطوتين إلى حد ما. الفكرة هي استخدام سجلات DNS جديدة تسمى SVCB و HTTPS ، والتي ستحتوي على معلومات مشابهة لما هو موجود في Alt-Svc . على هذا النحو ، يمكن للعميل اكتشاف أن الخادم يدعم HTTP / 3 أثناء خطوة تحليل DNS بدلاً من ذلك ، مما يعني أنه يمكنه تجربة QUIC من تحميل الصفحة الأولى بدلاً من الاضطرار أولاً إلى المرور عبر HTTP / 2 أو HTTP / 1.1. لمزيد من المعلومات حول هذا و Alt-Svc ، راجع فصل تقويم الويب للعام الماضي على HTTP / 2.

كما ترى ، يضيف Alt-Svc وعملية اكتشاف HTTP / 3 طبقة من التعقيد لنشر خادم QUIC الذي يمثل تحديًا بالفعل ، وذلك للأسباب التالية:

• ستحتاج دائمًا إلى نشر خادم HTTP / 3 بجوار خادم HTTP / 2 و / أو HTTP / 1.1 ؛
• ستحتاج إلى تكوين خوادم HTTP / 2 و HTTP / 1.1 لتعيين رؤوس Alt-Svc الصحيحة على استجاباتهم.

في حين أن ذلك يجب أن يكون قابلاً للإدارة في عمليات الإعداد على مستوى الإنتاج (لأنه ، على سبيل المثال ، من المحتمل أن يدعم مثيل Apache أو NGINX واحد جميع إصدارات HTTP الثلاثة في نفس الوقت) ، فقد يكون الأمر مزعجًا أكثر في مجموعة الاختبار (المحلية )- شكا (يمكنني بالفعل أن أرى نفسي نسيت إضافة رؤوس Alt-Svc أو العبث بها). تتفاقم هذه المشكلة بسبب النقص (الحالي) في سجلات أخطاء المتصفح ومؤشرات DevTools ، مما يعني أن معرفة سبب عدم عمل الإعداد بالضبط قد يكون صعبًا.

قضايا إضافية

كما لو لم يكن ذلك كافيًا ، هناك مشكلة أخرى ستجعل الاختبار المحلي أكثر صعوبة: يجعل Chrome من الصعب جدًا عليك استخدام شهادات TLS الموقعة ذاتيًا لـ QUIC . هذا لأن شهادات TLS غير الرسمية غالبًا ما تستخدم من قبل الشركات لفك تشفير حركة مرور TLS لموظفيها (حتى يتمكنوا ، على سبيل المثال ، من فحص جدران الحماية الخاصة بهم داخل حركة المرور المشفرة). ومع ذلك ، إذا بدأت الشركات في فعل ذلك باستخدام QUIC ، فسنحصل مرة أخرى على تطبيقات مخصصة للصندوق الأوسط تضع افتراضاتها الخاصة حول البروتوكول. قد يؤدي ذلك إلى كسر دعم البروتوكول في المستقبل ، وهو بالضبط ما حاولنا منعه من خلال تشفير QUIC على نطاق واسع في المقام الأول! As such, Chrome takes a very opinionated stance on this: If you're not using an official TLS certificate (signed by a certificate authority or root certificate that is trusted by Chrome, such as Let's Encrypt), then you cannot use QUIC . This, sadly, also includes self-signed certificates, which are often used for local test set-ups.

It is still possible to bypass this with some freaky command-line flags (because the common --ignore-certificate-errors doesn't work for QUIC yet), by using per-developer certificates (although setting this up can be tedious), or by setting up the real certificate on your development PC (but this is rarely an option for big teams because you would have to share the certificate's private key with each developer). Finally, while you can install a custom root certificate, you would then also need to pass both the --origin-to-force-quic-on and --ignore-certificate-errors-spki-list flags when starting Chrome (see below). Luckily, for now, only Chrome is being so strict, and hopefully, its developers will loosen their approach over time.

If you are having problems with your QUIC set-up from inside a browser, it's best to first validate it using a tool such as cURL. cURL has excellent HTTP/3 support (you can even choose between two different underlying libraries) and also makes it easier to observe Alt-Svc caching logic.

ماذا يعني كل ذلك؟

Next to the challenges involved with setting up HTTP/3 and QUIC on the server-side, there are also difficulties in getting browsers to use the new protocols consistently. This is due to a two-step discovery process involving the Alt-Svc HTTP header and the fact that HTTP/2 connections cannot simply be “upgraded” to HTTP/3, because the latter uses UDP.

Even if a server supports HTTP/3, however, clients (and website owners!) need to deal with the fact that intermediate networks might block UDP and/or QUIC traffic. As such, HTTP/3 will never completely replace HTTP/2 . In practice, keeping a well-tuned HTTP/2 set-up will remain necessary both for first-time visitors and visitors on non-permissive networks. Luckily, as we discussed, there shouldn't be many page-level changes between HTTP/2 and HTTP/3, so this shouldn't be a major headache.

What could become a problem, however, is testing and verifying whether you are using the correct configuration and whether the protocols are being used as expected. This is true in production, but especially in local set-ups. As such, I expect that most people will continue to run HTTP/2 (or even HTTP/1.1) development servers , switching only to HTTP/3 in a later deployment stage. Even then, however, validating protocol performance with the current generation of tools won't be easy.

Tools and Testing

As was the case with many major servers, the makers of the most popular web performance testing tools have not been keeping up with HTTP/3 from the start. Consequently, few tools have dedicated support for the new protocol as of July 2021, although they support it to a certain degree.

منارة جوجل

First, there is the Google Lighthouse tool suite. While this is an amazing tool for web performance in general, I have always found it somewhat lacking in aspects of protocol performance. This is mostly because it simulates slow networks in a relatively unrealistic way, in the browser (the same way that Chrome's DevTools handle this). While this approach is quite usable and typically “good enough” to get an idea of the impact of a slow network, testing low-level protocol differences is not realistic enough. Because the browser doesn't have direct access to the TCP stack, it still downloads the page on your normal network, and it then artificially delays the data from reaching the necessary browser logic. This means, for example, that Lighthouse emulates only delay and bandwidth, but not packet loss (which, as we've seen, is a major point where HTTP/3 could potentially differ from HTTP/2). Alternatively, Lighthouse uses a highly advanced simulation model to guesstimate the real network impact, because, for example, Google Chrome has some complex logic that tweaks several aspects of a page load if it detects a slow network. This model has, to the best of my knowledge, not been adjusted to handle IETF QUIC or HTTP/3 yet. As such, if you use Lighthouse today for the sole purpose of comparing HTTP/2 and HTTP/3 performance, then you are likely to get erroneous or oversimplified results, which could lead you to wrong conclusions about what HTTP/3 can do for your website in practice. The silver lining is that, in theory, this can be improved massively in the future, because the browser does have full access to the QUIC stack, and thus Lighthouse could add much more advanced simulations (including packet loss!) for HTTP/3 down the line. For now, though, while Lighthouse can, in theory, load pages over HTTP/3, I would recommend against it.

WebPageTest

Secondly, there is WebPageTest. This amazing project lets you load pages over real networks from real devices across the world, and it also allows you to add packet-level network emulation on top, including aspects such as packet loss! As such, WebPageTest is conceptually in a prime position to be used to compare HTTP/2 and HTTP/3 performance. However, while it can indeed already load pages over the new protocol, HTTP/3 has not yet been properly integrated into the tooling or visualizations . For example, there are currently no easy ways to force a page load over QUIC, to easily view how Alt-Svc was actually used, or even to see QUIC handshake details. In some cases, even seeing whether a response used HTTP/3 or HTTP/2 can be challenging. Still, in April, I was able to use WebPageTest to run quite a few tests on facebook.com and see HTTP/3 in action, which I'll go over now.

First, I ran a default test for facebook.com , enabling the “repeat view” option. As explained above, I would expect the first page load to use HTTP/2, which will include the Alt-Svc response header. As such, the repeat view should use HTTP/3 from the start. In Firefox version 89, this is more or less what happens. However, when looking at individual responses, we see that even during the first page load, Firefox will switch to using HTTP/3 instead of HTTP/2 ! As you can see in figure 2, this happens from the 20th resource onwards. This means that Firefox establishes a new QUIC connection as soon as it sees the Alt-Svc header, and it switches to it once it succeeds. If you scroll down to the connection view, it also seems to show that Firefox even opened two QUIC connections: one for credentialed CORS requests and one for no-CORS requests. This would be expected because, as we discussed above, even for HTTP/2 and HTTP/3, browsers will open multiple connections due to security concerns. However, because WebPageTest doesn't provide more details in this view, it's difficult to confirm without manually digging through the data. Looking at the repeat view (second visit), it starts by directly using HTTP/3 for the first request, as expected.

Next, for Chrome, we see similar behavior for the first page load, although here Chrome already switches on the 10th resource, much earlier than Firefox. It's a bit more unclear here whether it switches as soon as possible or only when a new connection is needed (for example, for requests with different credentials), because, unlike for Firefox, the connection view also doesn't seem to show multiple QUIC connections. For the repeat view, we see some weirder things. Unexpectedly, Chrome starts off using HTTP/2 there as well , switching to HTTP/3 only after a few requests! I performed a few more tests on other pages as well, to confirm that this is indeed consistent behaviour. This could be due to several things: It might just be Chrome's current policy, it might be that Chrome “raced” a TCP and QUIC connection and TCP won initially, or it might be that the Alt-Svc cache from the first view was unused for some reason. At this point, there is, sadly, no easy way to determine what the problem really is (and whether it can even be fixed).

Another interesting thing I noticed here is the apparent connection coalescing behavior. As discussed above, both HTTP/2 and HTTP/3 can reuse connections even if they go to other hostnames, to prevent downsides from hostname sharding. However, as shown in figure 3, WebPageTest reports that, for this Facebook load, connection coalescing is used over HTTP/3 for facebook.com and fbcdn.net , but not over HTTP/2 (as Chrome opens a secondary connection for the second domain). I suspect this is a bug in WebPageTest, however, because facebook.com and fbcnd.net resolve to different IPs and, as such, can't really be coalesced.

The figure also shows that some key QUIC handshake information is missing from the current WebPageTest visualization.

Note : As we see, getting “real” HTTP/3 going can be difficult sometimes. Luckily, for Chrome specifically, we have additional options we can use to test QUIC and HTTP/3, in the form of command-line parameters.

On the bottom of WebPageTest's “Chromium” tab, I used the following command-line options:

 --enable-quic --quic-version=h3-29 --origin-to-force-quic-on=www.facebook.com:443,static.xx.fbcdn.net:443

The results from this test show that this indeed forces a QUIC connection from the start, even in the first view, thus bypassing the Alt-Svc process. Interestingly, you will notice I had to pass two hostnames to --origin-to-force-quic-on . In the version where I didn't, Chrome, of course, still first opened an HTTP/2 connection to the fbcnd.net domain, even in the repeat view. As such, you'll need to manually indicate all QUIC origins in order for this to work !

We can see even from these few examples that a lot of stuff is going on with how browsers actually use HTTP/3 in practice. It seems they even switch to the new protocol during the initial page load, abandoning HTTP/2 either as soon as possible or when a new connection is needed. As such, it's difficult not only getting a full HTTP/3 load, but also getting a pure HTTP/2 load on a set-up that supports both ! Because WebPageTest doesn't show much HTTP/3 or QUIC metadata yet, figuring out what's going on can be challenging, and you can't trust the tools and visualizations at face value either.

So, if you use WebPageTest, you'll need to double-check the results to make sure which protocols were actually used. Consequently, I think this means that it's too early to really test HTTP/3 performance at this time (and especially too early to compare it to HTTP/2). This belief is strengthened by the fact that not all servers and clients have implemented all protocol features yet. Due to the fact that WebPageTest doesn't yet have easy ways of showing whether advanced aspects such as 0-RTT were used, it will be tricky to know what you're actually measuring. This is especially true for the HTTP/3 prioritization feature, which isn't implemented properly in all browsers yet and which many servers also lack full support for. Because prioritization can be a major aspect driving web performance, it would be unfair to compare HTTP/3 to HTTP/2 without making sure that at least this feature works properly (for both protocols!). This is just one aspect, though, as my research shows how big the differences between QUIC implementations can be. If you do any comparison of this sort yourself (or if you read articles that do), make 100% sure that you've checked what's actually going on .

Finally, also note that other higher-level tools (or data sets such as the amazing HTTP Archive) are often based on WebPageTest or Lighthouse (or use similar methods), so I suspect that most of my comments here will be widely applicable to most web performance tooling. Even for those tool vendors announcing HTTP/3 support in the coming months, I would be a bit skeptical and would validate that they're actually doing it correctly. For some tools, things are probably even worse, though; for example, Google's PageSpeed Insights only got HTTP/2 support this year, so I wouldn't wait for HTTP/3 arriving anytime soon.

Wireshark و qlog و qvis

كما توضح المناقشة أعلاه ، قد يكون من الصعب تحليل سلوك HTTP / 3 بمجرد استخدام Lighthouse أو WebPageTest في هذه المرحلة. لحسن الحظ ، تتوفر أدوات أخرى ذات مستوى أدنى للمساعدة في ذلك. أولاً ، تتمتع أداة Wireshark الممتازة بدعم متقدم لـ QUIC ، ويمكنها أيضًا تشريح HTTP / 3 تجريبيًا. يسمح لك هذا بمراقبة حزم QUIC و HTTP / 3 التي تمر فعليًا عبر السلك. ومع ذلك ، لكي يعمل ذلك ، تحتاج إلى الحصول على مفاتيح فك تشفير TLS لاتصال معين ، والتي تسمح لك معظم التطبيقات (بما في ذلك Chrome و Firefox) باستخراجها باستخدام متغير بيئة SSLKEYLOGFILE . في حين أن هذا يمكن أن يكون مفيدًا لبعض الأشياء ، فإن معرفة ما يحدث حقًا ، خاصة للاتصالات الأطول ، قد يستلزم الكثير من العمل اليدوي. ستحتاج أيضًا إلى فهم متقدم جدًا للأعمال الداخلية للبروتوكولات.

لحسن الحظ ، هناك خيار آخر ، qlog و qvis. qlog هو تنسيق تسجيل يستند إلى JSON خصيصًا لـ QUIC و HTTP / 3 وهو مدعوم من قبل غالبية تطبيقات QUIC. بدلاً من النظر إلى الحزم التي تمر عبر الأسلاك ، يلتقط qlog هذه المعلومات على العميل والخادم مباشرةً ، مما يسمح له بتضمين بعض المعلومات الإضافية (على سبيل المثال ، تفاصيل التحكم في الازدحام). عادةً ، يمكنك تشغيل إخراج qlog عند بدء تشغيل الخوادم والعملاء باستخدام متغير بيئة QLOGDIR . (لاحظ أنه في Firefox ، تحتاج إلى تعيين تفضيل network.http.http3.enable_qlog . تستخدم أجهزة Apple و Safari QUIC_LOG_DIRECTORY بدلاً من ذلك. لا يدعم Chrome حتى الآن qlog.)

يمكن بعد ذلك تحميل ملفات qlog هذه إلى مجموعة أدوات qvis على qvis.quictools.info. هناك ، ستحصل على عدد من التصورات التفاعلية المتقدمة التي تسهل تفسير حركة مرور QUIC و HTTP / 3 . يحتوي qvis أيضًا على دعم لتحميل لقطات حزمة Wireshark (ملفات .pcap ) ، ولديه دعم تجريبي لملفات netlog الخاصة بـ Chrome ، بحيث يمكنك أيضًا تحليل سلوك Chrome. البرنامج التعليمي الكامل حول qlog و qvis خارج نطاق هذه المقالة ، ولكن يمكن العثور على مزيد من التفاصيل في شكل تعليمي ، كورقة ، وحتى في شكل برنامج حواري. يمكنك أيضًا أن تسألني عنها مباشرة لأنني المنفذ الرئيسي لـ qlog و qvis. ؛)

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

ماذا يعني كل ذلك؟

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

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

على هذا النحو ، أوصي بترك قياسات أداء HTTP / 2 مقابل HTTP / 3 بمفردها لبضعة أشهر أخرى والتركيز بدلاً من ذلك على التأكد من أن إعدادات جانب الخادم لدينا تعمل كما هو متوقع . لهذا ، من الأسهل استخدام WebPageTest مع معلمات سطر أوامر Google Chrome ، مع وجود احتياطي لحل المشكلات المحتملة - وهذا هو الإعداد الأكثر اتساقًا الذي يمكنني العثور عليه حاليًا.

الخلاصة والوجبات الجاهزة

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

ملخص

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

ثانيًا ، في الجزء 2 ، ألقينا نظرة نقدية على هذه الميزات الجديدة ، لا سيما الآثار المترتبة على أدائها . أولاً ، رأينا أن استخدام QUIC لـ UDP لا يجعله أسرع (ولا أبطأ) بطريقة سحرية لأن QUIC تستخدم آليات التحكم في الازدحام التي تشبه إلى حد بعيد TCP لمنع التحميل الزائد على الشبكة. ثانيًا ، المصافحة الأسرع و 0-RTT هي المزيد من التحسينات الدقيقة ، لأنها في الحقيقة رحلة واحدة ذهابًا وإيابًا أسرع من مكدس TCP + TLS المحسّن ، ويتأثر 0-RTT الحقيقي لـ QUIC بمجموعة من المخاوف الأمنية التي يمكن أن تحد فائدته. ثالثًا ، لا يلزم ترحيل الاتصال إلا في حالات قليلة محددة ، ولا يزال هذا يعني إعادة تعيين معدلات الإرسال لأن التحكم في الازدحام لا يعرف مقدار البيانات التي يمكن للشبكة الجديدة التعامل معها. رابعًا ، تعتمد فعالية إزالة حظر رأس الخط في QUIC بشكل كبير على كيفية مضاعفة بيانات التدفق وتحديد أولوياتها. تبدو الأساليب المثلى للتعافي من فقد الحزمة ضارة بحالات الاستخدام العامة لأداء تحميل صفحات الويب والعكس صحيح ، على الرغم من الحاجة إلى مزيد من البحث. خامسًا ، يمكن أن يكون QUIC أبطأ في إرسال الحزم بسهولة من TCP + TLS ، لأن واجهات برمجة تطبيقات UDP أقل نضجًا وتقوم QUIC بتشفير كل حزمة على حدة ، على الرغم من أنه يمكن تخفيف ذلك إلى حد كبير في الوقت المناسب. سادساً ، HTTP / 3 نفسه لا يجلب بالفعل أي ميزات أداء جديدة رئيسية إلى الجدول ، ولكنه يعمل بشكل أساسي على إعادة صياغة وتبسيط العناصر الداخلية لميزات HTTP / 2 المعروفة. أخيرًا ، لا تعد بعض الميزات المتعلقة بالأداء الأكثر إثارة والتي تتيحها QUIC (متعدد المسارات ، والبيانات غير الموثوق بها ، ونقل الويب ، وتصحيح الأخطاء إلى الأمام ، وما إلى ذلك) جزءًا من معايير QUIC و HTTP / 3 الأساسية ، ولكنها بالأحرى ملحقات مقترحة تتطلب بعض الوقت ليكون متاحًا. في الختام ، هذا يعني أن QUIC ربما لن يحسن الأداء كثيرًا للمستخدمين على الشبكات عالية السرعة ، ولكنه سيكون مهمًا بشكل أساسي لمن لديهم شبكات بطيئة وأقل استقرارًا .

أخيرًا ، في هذا الجزء 3 ، نظرنا في كيفية استخدام ونشر QUIC و HTTP / 3 عمليًا . أولاً ، رأينا أن أفضل الممارسات والدروس المستفادة من HTTP / 2 يجب أن تنتقل إلى HTTP / 3. ليست هناك حاجة لتغيير استراتيجية التجميع أو المضمنة ، ولا لتوحيد مزرعة الخوادم الخاصة بك أو تقسيمها. لا يزال دفع الخادم ليس هو أفضل ميزة للاستخدام ، ويمكن أن يكون preload بالمثل أداة قوية. ثانيًا ، لقد ناقشنا أنه قد يستغرق الأمر بعض الوقت قبل أن توفر حزم خادم الويب الجاهزة دعم HTTP / 3 الكامل (جزئيًا بسبب مشكلات دعم مكتبة TLS) ، على الرغم من توفر الكثير من خيارات المصدر المفتوح للمتبنين الأوائل و العديد من شبكات CDN الرئيسية لديها عرض ناضج. ثالثًا ، من الواضح أن معظم المتصفحات الرئيسية لديها دعم HTTP / 3 (أساسي) ، حتى أنه يتم تمكينه افتراضيًا. هناك اختلافات كبيرة في كيفية ووقت استخدامهم لـ HTTP / 3 وميزاته الجديدة عمليًا ، لذلك قد يكون فهم سلوكهم أمرًا صعبًا. رابعًا ، ناقشنا أن هذا الأمر يزداد سوءًا بسبب نقص دعم HTTP / 3 الواضح في الأدوات الشائعة مثل Lighthouse و WebPageTest ، مما يجعل من الصعب بشكل خاص مقارنة أداء HTTP / 3 مع HTTP / 2 و HTTP / 1.1 في هذا الوقت. في الختام ، ربما لا يكون HTTP / 3 و QUIC جاهزين تمامًا لوقت الذروة حتى الآن ، لكنهما سيكونان قريبًا .

التوصيات

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

أولاً ، كما تمت مناقشته في نهاية الجزء 2 ، على الرغم من أن المستخدم "المتوسط" الخاص بك قد لا يواجه مكاسب كبيرة في الأداء (اعتمادًا على السوق المستهدف) ، فمن المحتمل أن يرى جزء كبير من جمهورك تحسينات رائعة . قد يوفر 0-RTT رحلة واحدة ذهابًا وإيابًا ، ولكن هذا قد يعني عدة مئات من المللي ثانية لبعض المستخدمين. قد لا يحافظ ترحيل الاتصال على التنزيلات السريعة باستمرار ، ولكنه سيساعد بالتأكيد الأشخاص الذين يحاولون جلب ملف PDF هذا في قطار عالي السرعة. قد يكون فقد الحزمة على الكبل سريعًا ، لكن الروابط اللاسلكية قد تستفيد أكثر من إزالة حظر رأس الخط من QUIC. علاوة على ذلك ، هؤلاء المستخدمون هم أولئك الذين سيواجهون عادةً أسوأ أداء لمنتجك ، وبالتالي سيكونون الأكثر تأثراً به. إذا كنت تتساءل عن سبب أهمية ذلك ، فاقرأ حكاية أداء الويب الشهيرة لكريس زاكرياس.

ثانيًا ، سيصبح QUIC و HTTP / 3 أفضل وأسرع بمرور الوقت . ركز الإصدار 1 على إنجاز البروتوكول الأساسي ، مع الاحتفاظ بميزات أداء أكثر تقدمًا في وقت لاحق. على هذا النحو ، أشعر أنه من المفيد البدء في الاستثمار في البروتوكولات الآن ، للتأكد من أنه يمكنك استخدامها والميزات الجديدة لتحقيق التأثير الأمثل عندما تصبح متاحة في المستقبل. نظرًا لتعقيد البروتوكولات وجوانب نشرها ، سيكون من الجيد أن تمنح نفسك بعض الوقت للتعرف على المراوغات الخاصة بها. حتى إذا كنت لا ترغب في جعل يديك متسخين تمامًا حتى الآن ، فإن العديد من موفري CDN الرئيسيين يقدمون دعم HTTP / 3 الناضج "flip the switch" (على وجه الخصوص ، Cloudflare و Fastly). أجد صعوبة في العثور على سبب لعدم تجربة ذلك إذا كنت تستخدم CDN (والذي ، إذا كنت تهتم بالأداء ، فيجب أن تكون كذلك).

على هذا النحو ، على الرغم من أنني لن أقول أنه من الضروري البدء في استخدام QUIC و HTTP / 3 في أقرب وقت ممكن ، إلا أنني أشعر أن هناك الكثير من الفوائد التي يمكن الحصول عليها بالفعل ، وستزداد فقط في المستقبل .

قراءة متعمقة

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

ستجد أدناه قائمة بالموارد الإضافية للتعلم المستمر ، بشكل أو بآخر بترتيب العمق الفني التصاعدي:

• "شرح HTTP / 3" ، دانيال ستينبيرج
  يلخص هذا الكتاب الإلكتروني ، من قبل مبتكر cURL ، البروتوكول.
• "HTTP / 2 في العمل" ، باري بولارد
  يحتوي هذا الكتاب الشامل الممتاز على HTTP / 2 على نصائح قابلة لإعادة الاستخدام وقسم على HTTP / 3.
• programmingart ، تويتر
  معظم تغريداتي مخصصة لأداء QUIC و HTTP / 3 والويب (بما في ذلك الأخبار) بشكل عام. انظر على سبيل المثال موضوعاتي الأخيرة حول ميزات QUIC.
• "يوتيوب" روبن ماركس
  تغطي أكثر من 10 محادثات متعمقة جوانب مختلفة من البروتوكولات.
• "مدونة Cloudlare"
  هذا هو المنتج الرئيسي لشركة تدير أيضًا CDN على الجانب.
• "مدونة فاستلي"
  تحتوي هذه المدونة على مناقشات ممتازة للجوانب التقنية ، المضمنة في السياق الأوسع.
• QUIC ، RFCs الفعلية
  ستجد روابط إلى مستندات IETF QUIC و HTTP / 3 RFC وغيرها من الامتدادات الرسمية.
• مدونة المهندسين IIJ: تفسيرات تقنية عميقة ممتازة لتفاصيل ميزة QUIC.
• أوراق HTTP / 3 و QUIC الأكاديمية ، روبن ماركس
  تغطي أوراق البحث الخاصة بي اختلافات تعدد الإرسال وتحديد الأولويات والأدوات والتنفيذ.
• QUIPS و EPIQ 2018 و EPIQ 2020
  تحتوي هذه الأوراق من ورش العمل الأكاديمية على بحث متعمق حول الأمان والأداء وامتدادات البروتوكولات.

مع ذلك ، أترك لك ، عزيزي القارئ ، بفهم آمل أن يكون قد تحسن كثيرًا لهذا العالم الجديد الشجاع. أنا منفتح دائمًا على التعليقات ، لذا يرجى إعلامي برأيك في هذه السلسلة!