Get best of the week

مقارنة أداء HTTP / 3 و HTTP / 2



أعلنا في Cloudflare عن دعم HTTP / 3 في سبتمبر الماضي عندما كنا نحتفل بعيد ميلادنا التاسع . كان هدفنا دائمًا تحسين الإنترنت. التعاون في مجال المعايير هو جزء مهم من العملية ، ونحن محظوظون لمشاركتنا في تطوير HTTP / 3.

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

أطلقنا في البداية بروتوكول HTTP / 3 بالشراكة مع Google ، والذي تضمن أيضًا دعمًا تجريبيًا لمتصفح Chrome Canary. منذ ذلك الحين ، أضاف المزيد والمزيد من المتصفحات دعمًا تجريبيًا: ظهر في Firefox Nightly Builds ، وفي العديد من المتصفحات القائمة على Chromium مثل Opera و Edge (عبر محرك Chromium الأساسي) ، وفي إصدارات Safari الأولية . نحن نراقب هذه التطورات عن كثب ونساعد حيثما أمكننا. إن امتلاك شبكة كبيرة من المواقع التي مكنت HTTP / 3 يمنح مطوري المتصفح أرضية اختبار ممتازة للتحقق من صحة الشفرة.

إذن ما هو الوضع الحالي؟


تتضمن عملية توحيد IETF سلسلة من المسودات لإعداد "مسودة نهائية" جاهزة للتوسيم كمعيار RFC. يعمل أعضاء فريق QUIC معًا على التحليل والتنفيذ والتشغيل البيني لتحديد المشاكل المحتملة. أطلقنا دعم البروتوكول في مرحلة الإصدار 23 من المسودة ، ثم تابعنا جميع التغييرات ، وفي وقت كتابة هذا التقرير (14 أبريل 2020) كان الإصدار الأخير هو الإصدار 27. مع كل مسودة ، تحسن جودة تعريفات QUIC وتقترب من "إجماع تقريبي" حول كيفية سلوك البروتوكول. لتجنب التحليل الدائم مع إعدادات dopilivaniya إلى ما لا نهاية إلى المثالية ، مع كل نسخة جديدة من المسودة ، يزداد الشريط لإجراء تغييرات على المواصفات. هذا يعني أنه مع كل إصدار هناك تغييرات أقل ، وسوف يتوافق RFC النهائي بشكل وثيق مع البروتوكول الذي أطلقناه بالفعل في الإنتاج.

فوائد


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

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

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



في المثال الثاني ، يتم تلقي طلبات الموارد عبر HTTP / 3. يتم فقدان حزمة واحدة ، مما يمنع نقل المورد الأصفر ، ولكن دون التأثير على الأخضر.



التحسينات في إجراء التفاوض على جلسة تعني أن "الاتصالات" مع الخوادم يتم إنشاؤها بشكل أسرع ، أي أن البيانات تصل بشكل أسرع في المتصفح. شعرنا بالفضول لمعرفة مدى انعكاس ذلك على حركة المرور الحقيقية ، لذلك أجرينا العديد من الاختبارات. لتقييم مساهمة 0-RTT ، أطلقنا العديد من اختبارات التحكم لقياس الوقت للبايت الأول (الوقت للبايت الأول ، TTFB). في المتوسط ​​، عبر HTTP / 3 ، تظهر البايت الأولى بعد 176 مللي ثانية. في حالة HTTP / 2 ، نرى 201 مللي ثانية ، أي أن HTTP / 3 هنا يقلل من التأخير بنسبة 12.4٪!



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

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

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

يتم تحميل صفحة اختبار صغيرة بحجم 15 كيلوبايت عبر HTTP / 3 في المتوسط ​​443 مللي ثانية ، مقارنة بـ 458 مللي ثانية لـ HTTP / 2. ولكن إذا قمت بزيادة حجم الصفحة إلى 1 ميجابايت ، فستختفي هذه الميزة: على وجه التحديد في شبكتنا ، يعمل بروتوكول HTTP / 3 الآن بشكل أبطأ قليلاً من HTTP / 2 - 2.33 ثانية مقابل 2.30 ثانية.







تعتبر المقاييس الاصطناعية مثيرة للاهتمام ، ولكن من المثير للاهتمام كيف يظهر HTTP / 3 نفسه في العالم الحقيقي.

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

كحالة اختبار لقياس الأداء ، أخذنا مدونتنا الخاصة . قمنا بإعداد مثيلات WebPageTest الخاصة بنا لتحميل الموقع من مواقع حول العالم ، سواء عبر HTTP / 2 أو عبر HTTP / 3. تضمين HTTP / 3 و Insights Browser. وهكذا ، في كل مرة يقوم فيها متصفح يدعم HTTP / 3 بتحميل الصفحة ، تطلب البرامج النصية التجريبية بيانات تحليلية مجمعة من المتصفح. تم تكرار نفس الإجراء لـ HTTP / 2 بحيث يمكن مقارنته.

يوضح الرسم البياني التالي وقت التحميل لصفحة blog.cloudflare.com الفعلية مع مقارنة مقاييس HTTP / 3 و HTTP / 2. لدينا مثل هذه المقاييس لنقاط جغرافية مختلفة.



كما ترى ، لا يزال أداء HTTP / 3 أدنى من أداء HTTP / 2. الفرق حوالي 1-4٪ في المتوسط ​​في أمريكا الشمالية. نتائج مماثلة في أوروبا وآسيا وأمريكا الجنوبية. نشك في أن هذا قد يكون بسبب اختلاف في خوارزميات التحكم في الازدحام: يعمل BBR v1 على HTTP / 2 ، و CUBIC على HTTP / 3. في المستقبل ، سنحاول تنفيذ نفس خوارزمية التحكم في الحمل الزائد على كلا البروتوكولين من أجل الحصول على مقارنة أكثر دقة للتفاح مع التفاح.

استنتاج


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

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

More articles:


All Articles