HTTP / 3: تحسينات الأداء (الجزء 2)

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

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

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

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

كتاب تمهيدي عن السرعة

يمكن أن تصبح مناقشة الأداء و "السرعة" معقدة بسرعة ، لأن العديد من الجوانب الأساسية تساهم في تحميل صفحة الويب "ببطء". نظرًا لأننا نتعامل مع بروتوكولات الشبكة هنا ، فسننظر بشكل أساسي في جوانب الشبكة ، والتي يعتبر اثنان منها أكثر أهمية: الكمون وعرض النطاق الترددي.

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

على وجه الأرض ، يعني هذا أن فترات الانتقال النموذجية صغيرة من الناحية المفاهيمية ، وتتراوح ما بين 10 و 200 مللي ثانية تقريبًا. ومع ذلك ، فهذه طريقة واحدة فقط: يجب أيضًا أن تعود الردود على الحزم. غالبًا ما يُطلق على وقت الاستجابة في الاتجاهين وقت رحلة الذهاب والإياب (RTT) .

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

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

كثيرا ما تستخدم استعارة لأنبوب يستخدم لنقل المياه. طول الأنبوب هو الكمون ، بينما عرض الأنبوب هو عرض النطاق الترددي. ومع ذلك ، على الإنترنت ، لدينا عادةً سلسلة طويلة من الأنابيب المتصلة ، يمكن أن يكون بعضها أوسع من البعض الآخر (مما يؤدي إلى ما يسمى بالاختناقات في أضيق الروابط). على هذا النحو ، فإن عرض النطاق الترددي من طرف إلى طرف بين النقطتين A و B غالبًا ما يكون مقيدًا بأبطأ الأقسام الفرعية.

في حين أن الفهم الكامل لهذه المفاهيم ليس ضروريًا لبقية هذا المنشور ، فإن وجود تعريف مشترك عالي المستوى سيكون جيدًا. لمزيد من المعلومات ، أوصي بمراجعة الفصل الممتاز لـ Ilya Grigorik عن زمن الانتقال وعرض النطاق الترددي في كتابه High Performance Browser Networking .

التحكم في الازدحام

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

هل كنت تعلم؟

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

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

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

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

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

في بداية الاتصال ، يرسل عددًا قليلاً فقط من الحزم (عمليًا ، تتراوح بين 10 و 100 حزمة ، أو حوالي 14 و 140 كيلوبايت من البيانات) وينتظر رحلة واحدة ذهابًا وإيابًا حتى يرسل المستلم إقرارات هذه الحزم. إذا تم الاعتراف بهم جميعًا ، فهذا يعني أن الشبكة يمكنها التعامل مع معدل الإرسال هذا ، ويمكننا محاولة تكرار العملية ولكن مع المزيد من البيانات (عمليًا ، يتضاعف معدل الإرسال عادةً مع كل تكرار).

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

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

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

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

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

وقد أدى ذلك إلى العديد من المقالات التي تدعي أن QUIC أيضًا لا تستخدم التحكم في الازدحام ، وأن QUIC يمكنها بدلاً من ذلك البدء في إرسال البيانات بمعدل أعلى بكثير عبر UDP (بالاعتماد على إزالة حظر HOL للتعامل مع فقدان الحزمة) ، وهذا هو السبب. QUIC أسرع بكثير من TCP.

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

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

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

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

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

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

هل كنت تعلم؟

يحدد QUIC Recovery RFC 9002 الرسمي استخدام خوارزمية NewReno للتحكم في الازدحام. في حين أن هذا النهج قوي ، إلا أنه قديم إلى حد ما ولم يعد يستخدم على نطاق واسع في الممارسة بعد الآن. إذن ، لماذا هو موجود في QUIC RFC؟ السبب الأول هو أنه عند بدء QUIC ، كان NewReno هو أحدث خوارزمية للتحكم في الازدحام تم توحيدها في حد ذاتها. الخوارزميات الأكثر تقدمًا ، مثل BBR و CUBIC ، إما لا تزال غير موحدة أو أصبحت مؤخرًا RFCs فقط.

السبب الثاني هو أن NewReno عبارة عن إعداد بسيط نسبيًا. نظرًا لأن الخوارزميات تحتاج إلى بعض التعديلات للتعامل مع اختلافات QUIC عن TCP ، فمن الأسهل شرح هذه التغييرات باستخدام خوارزمية أبسط. على هذا النحو ، يجب قراءة RFC 9002 بشكل أكبر على أنها "كيفية تكييف خوارزمية التحكم في الازدحام مع QUIC" ، بدلاً من "هذا هو الشيء الذي يجب عليك استخدامه لـ QUIC". في الواقع ، جعلت معظم تطبيقات QUIC على مستوى الإنتاج تطبيقات مخصصة لكل من Cubic و BBR.

وتجدر الإشارة إلى أن خوارزميات التحكم في الازدحام ليست خاصة بـ TCP أو QUIC ؛ يمكن استخدامها من خلال أي من البروتوكولين ، والأمل هو أن التطورات في QUIC ستجد طريقها في النهاية إلى مكدسات TCP أيضًا.

هل كنت تعلم؟

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

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

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

إعداد اتصال 0-RTT

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

هل كنت تعلم؟

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

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

قد تتساءل عن سبب عدم إمكانية دمج مصافحة TCP + TLS ببساطة ، ويتم إجراؤها في نفس الرحلة ذهابًا وإيابًا. في حين أن هذا ممكن من الناحية المفاهيمية (QUIC يفعل ذلك بالضبط) ، لم يتم تصميم الأشياء في البداية على هذا النحو ، لأننا نحتاج إلى أن نكون قادرين على استخدام TCP مع وبدون TLS في الأعلى. بعبارة أخرى ، لا يدعم TCP ببساطة إرسال أشياء بخلاف TCP أثناء المصافحة. كانت هناك جهود لإضافة هذا بامتداد TCP Fast Open ؛ ومع ذلك ، كما تمت مناقشته في الجزء الأول ، فقد تبين أنه من الصعب نشره على نطاق واسع.

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

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

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

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

إنه يسمح بتحسين قوي: يمكننا الآن إرسال طلب HTTP الأول بأمان مع مصافحة QUIC / TLS ، مما يوفر رحلة ذهابًا وإيابًا أخرى ! بالنسبة إلى TLS 1.3 ، فإن هذا يزيل بشكل فعال وقت انتظار مصافحة TLS. غالبًا ما يُطلق على هذه الطريقة اسم 0-RTT (على الرغم من أنها ، بالطبع ، لا تزال تستغرق رحلة واحدة ذهابًا وإيابًا حتى تبدأ بيانات استجابة HTTP في الوصول).

مرة أخرى ، كل من استئناف الجلسة و 0-RTT هما من الأشياء التي رأيتها غالبًا ما تم شرحها بشكل خاطئ على أنها ميزات خاصة بـ QUIC. في الواقع ، هذه في الواقع ميزات TLS كانت موجودة بالفعل في شكل ما في TLS 1.2 وهي الآن كاملة في TLS 1.3.

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

أسوأ جزء هو أنه عند استخدام 0-RTT ، لا يمكن لـ QUIC حقًا استخدام تلك الرحلة المكتسبة ذهابًا وإيابًا بشكل جيد بسبب الأمان. لفهم هذا ، نحتاج إلى فهم أحد أسباب وجود مصافحة TCP. أولاً ، يسمح للعميل بالتأكد من أن الخادم متاح بالفعل على عنوان IP المحدد قبل إرسال أي بيانات ذات طبقة أعلى.

ثانيًا ، والأهم هنا ، أنه يسمح للخادم بالتأكد من أن العميل الذي يفتح الاتصال هو في الواقع من وأين يقولون إنه موجود قبل إرسال البيانات. إذا كنت تتذكر كيف حددنا الاتصال بـ 4-tuple في الجزء 1 ، فستعرف أن العميل يتم تحديده بشكل أساسي من خلال عنوان IP الخاص به. وهذه هي المشكلة: يمكن انتحال عناوين IP !

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

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

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

على هذا النحو ، يجب أن تكون QUIC متحفظة في الرد على طلبات 0-RTT ، مما يحد من كمية البيانات التي ترسلها استجابةً إلى أن يتم التحقق من أن العميل عميل حقيقي وليس ضحية. بالنسبة إلى QUIC ، تم تعيين مقدار هذه البيانات على ثلاثة أضعاف المبلغ المستلم من العميل.

بعبارة أخرى ، تمتلك QUIC "عامل تضخيم" أقصى ثلاثة ، والذي تم تحديده ليكون بمثابة مقايضة مقبولة بين فائدة الأداء ومخاطر الأمان (خاصةً بالمقارنة مع بعض الحوادث التي كان لها عامل تضخيم يزيد عن 51000 مرة). نظرًا لأن العميل يرسل عادةً حزمة واحدة إلى حزمتين فقط ، فسيتم تحديد رد RTT الخاص بخادم QUIC من 4 إلى 6 كيلوبايت فقط (بما في ذلك QUIC و TLS الأخرى!) ، وهو أقل من مثير للإعجاب إلى حد ما.

بالإضافة إلى ذلك ، يمكن أن تؤدي مشكلات الأمان الأخرى ، على سبيل المثال ، إلى "هجمات إعادة التشغيل" ، والتي تحد من نوع طلب HTTP الذي يمكنك القيام به. على سبيل المثال ، لا تسمح Cloudflare إلا بطلبات HTTP GET بدون معلمات الاستعلام في 0-RTT. هذه تحد من فائدة 0-RTT أكثر.

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

هل كنت تعلم؟

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

هل كنت تعلم؟

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

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

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

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

يعد إعداد اتصال QUIC الأسرع مع 0-RTT بمثابة تحسين جزئي أكثر من كونه ميزة ثورية جديدة. مقارنةً بأحدث إعداد TCP + TLS 1.3 ، فإنه سيوفر رحلة واحدة ذهابًا وإيابًا كحد أقصى. كمية البيانات التي يمكن إرسالها فعليًا في أول رحلة ذهابًا وإيابًا محدودة بالإضافة إلى ذلك بعدد من الاعتبارات الأمنية.

على هذا النحو ، سوف تتألق هذه الميزة في الغالب إما إذا كان المستخدمون لديك على شبكات بزمن انتقال عالٍ جدًا (على سبيل المثال ، شبكات الأقمار الصناعية التي تحتوي على أكثر من 200 مللي ثانية من RTTs) أو إذا كنت لا ترسل عادةً الكثير من البيانات. بعض الأمثلة على هذا الأخير هي مواقع الويب المخبأة بشكل كبير ، بالإضافة إلى تطبيقات الصفحة الواحدة التي تجلب بشكل دوري تحديثات صغيرة عبر واجهات برمجة التطبيقات والبروتوكولات الأخرى مثل DNS-over-QUIC. أحد الأسباب التي دفعت Google إلى رؤية نتائج 0-RTT جيدة جدًا لـ QUIC هو أنها اختبرتها على صفحة البحث المُحسّنة بشكل كبير بالفعل ، حيث تكون إجابات الاستعلامات صغيرة جدًا.

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

ترحيل الاتصال

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

كما تمت مناقشته في الجزء الأول ، تسمح معرفات الاتصال (CID) الخاصة بـ QUIC لها بإجراء ترحيل الاتصال عند تبديل الشبكات . لقد أوضحنا ذلك من خلال انتقال عميل من شبكة Wi-Fi إلى شبكة 4G أثناء تنزيل ملف كبير. على TCP ، قد يتم إلغاء هذا التنزيل ، بينما قد يستمر لـ QUIC.

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

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

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

نظرًا لوجود بعض الوقت المتداخل بين انقطاع الشبكة 1 وإتاحة الشبكة 2 ، يمكن لتطبيقات الفيديو فتح اتصالات متعددة (1 لكل شبكة) ، ومزامنتها قبل اختفاء الشبكة القديمة تمامًا. سيظل المستخدم يلاحظ التبديل ، لكنه لن يسقط بث الفيديو بالكامل.

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

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

هل كنت تعلم؟

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

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

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

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

يتم ذلك للسماح لكل نقطة نهاية باختيار تنسيق CID الخاص بها ومحتوياتها ، والتي بدورها ضرورية للسماح لمنطق التوجيه وموازنة الحمل المتقدم. مع ترحيل الاتصال ، لم يعد بإمكان أرصدة التحميل إلقاء نظرة على 4-tuple لتحديد اتصال وإرساله إلى خادم الجهة الخلفية الصحيح. ومع ذلك ، إذا كانت جميع اتصالات QUIC ستستخدم معرّفات CID عشوائية ، فسيؤدي ذلك إلى زيادة متطلبات الذاكرة بشكل كبير عند موازن التحميل ، لأنه سيحتاج إلى تخزين تعيينات CIDs على الخوادم الخلفية. بالإضافة إلى ذلك ، لن يعمل هذا مع ترحيل الاتصال ، حيث تتغير CIDs إلى قيم عشوائية جديدة.

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

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

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

ومع ذلك ، اعتمادًا على حالة الاستخدام أو ملف تعريف المستخدم ، يمكن أن يكون له تأثير كبير. إذا تم استخدام موقع الويب أو التطبيق الخاص بك غالبًا أثناء التنقل (على سبيل المثال ، شيء مثل Uber أو خرائط Google) ، فمن المحتمل أن تستفيد أكثر مما لو كان المستخدمون يجلسون عادةً خلف مكتب. Similarly, if you're focusing on constant interaction (be it video chat, collaborative editing, or gaming), then your worst-case scenarios should improve more than if you have a news website.

Head-of-Line Blocking Removal

The fourth performance feature is intended to make QUIC faster on networks with a high amount of packet loss by mitigating the head-of-line (HoL) blocking problem. While this is true in theory, we will see that in practice this will probably only provide minor benefits for web-page loading performance.

To understand this, though, we first need to take a detour and talk about stream prioritization and multiplexing.

Stream Prioritization

As discussed in part 1, a single TCP packet loss can delay data for multiple in-transit resources because TCP's bytestream abstraction considers all data to be part of a single file. QUIC, on the other hand, is intimately aware that there are multiple concurrent bytestreams and can handle loss on a per-stream basis. However, as we've also seen, these streams are not truly transmitting data in parallel: Rather, the stream data is multiplexed onto a single connection. This multiplexing can happen in many different ways.

For example, for streams A, B, and C, we might see a packet sequence of ABCABCABCABCABCABCABCABC , where we change the active stream in each packet (let's call this round-robin). However, we might also see the opposite pattern of AAAAAAAABBBBBBBBCCCCCCCC , where each stream is completed in full before starting the next one (let's call this sequential). Of course, many other options are possible in between these extremes ( AAAABBCAAAAABBC… , AABBCCAABBCC… , ABABABCCCC… , etc.). The multiplexing scheme is dynamic and driven by an HTTP-level feature called stream prioritization (discussed later in this article).

As it turns out, which multiplexing scheme you choose can have a huge impact on website loading performance. You can see this in the video below, courtesy of Cloudflare, as every browser uses a different multiplexer. The reasons why are quite complex, and I've written several academic papers on the topic, as well as talked about it in a conference. Patrick Meenan, of Webpagetest fame, even has a three-hour tutorial on just this topic.

Luckily, we can explain the basics relatively easily. As you may know, some resources can be render blocking. This is the case for CSS files and for some JavaScript in the HTML head element. While these files are loading, the browser cannot paint the page (or, for example, execute new JavaScript).

What's more, CSS and JavaScript files need to be downloaded in full in order to be used (although they can often be incrementally parsed and compiled). As such, these resources need to be loaded as soon as possible, with the highest priority. Let's contemplate what would happen if A, B, and C were all render-blocking resources.

If we use a round-robin multiplexer (the top row in figure 6), we would actually delay each resource's total completion time, because they all need to share bandwidth with the others. Since we can only use them after they are fully loaded, this incurs a significant delay. However, if we multiplex them sequentially (the bottom row in figure 6), we would see that A and B complete much earlier (and can be used by the browser), while not actually delaying C's completion time.

However, that doesn't mean that sequential multiplexing is always the best, because some (mostly non-render-blocking) resources (such as HTML and progressive JPEGs) can actually be processed and used incrementally . In those (and some other) cases, it makes sense to use the first option (or at least something in between).

Still, for most web-page resources, it turns out that sequential multiplexing performs best . This is, for example, what Google Chrome is doing in the video above, while Internet Explorer is using the worst-case round-robin multiplexer.

Packet Loss Resilience

Now that we know that all streams aren't always active at the same time and that they can be multiplexed in different ways, we can consider what happens if we have packet loss. As explained in part 1, if one QUIC stream experiences packet loss, then other active streams can still be used (whereas, in TCP, all would be paused).

However, as we've just seen, having many concurrent active streams is typically not optimal for web performance, because it can delay some critical (render-blocking) resources, even without packet loss! We'd rather have just one or two active at the same time, using a sequential multiplexer. However, this reduces the impact of QUIC's HoL blocking removal.

Imagine, for example, that the sender could transmit 12 packets at a given time (see figure 7 below) — remember that this is limited by the congestion controller). If we fill all 12 of those packets with data for stream A (because it's high priority and render-blocking — think main.js ), then we would have only one active stream in that 12-packet window.

If one of those packets were to be lost, then QUIC would still end up fully HoL blocked because there would simply be no other streams it could process besides A : All of the data is for A , and so everything would still have to wait (we don't have B or C data to process), similar to TCP.

We see that we have a kind of contradiction: Sequential multiplexing ( AAAABBBBCCCC ) is typically better for web performance, but it doesn't allow us to take much advantage of QUIC's HoL blocking removal. Round-robin multiplexing ( ABCABCABCABC ) would be better against HoL blocking, but worse for web performance. As such, one best practice or optimization can end up undoing another .

And it gets worse. Up until now, we've sort of assumed that individual packets get lost one at a time. However, this isn't always true, because packet loss on the Internet is often “bursty”, meaning that multiple packets often get lost at the same time .

As discussed above, an important reason for packet loss is that a network is overloaded with too much data, having to drop excess packets. This is why the congestion controller starts sending slowly. However, it then keeps growing its send rate until… there is packet loss!

Put differently, the mechanism that's intended to prevent overloading the network actually overloads the network (albeit in a controlled fashion). On most networks, that occurs after quite a while, when the send rate has increased to hundreds of packets per round trip. When those reach the limit of the network, several of them are typically dropped together, leading to the bursty loss patterns.

Did You Know?

This is one of the reasons why we wanted to move to using a single (TCP) connection with HTTP/2, rather than the 6 to 30 connections with HTTP/1.1. Because each individual connection ramps up its send rate in pretty much the same way, HTTP/1.1 could get a good speed-up at the start, but the connections could actually start causing massive packet loss for each other as they caused the network to become overloaded.

At the time, Chromium developers speculated that this behaviour caused most of the packet loss seen on the Internet. This is also one of the reasons why BBR has become an often used congestion-control algorithm, because it uses fluctuations in observed RTTs, rather than packet loss, to assess available bandwidth.

Did You Know?

Other causes of packet loss can lead to fewer or individual packets becoming lost (or unusable), especially on wireless networks. There, however, the losses are often detected at lower protocol layers and solved between two local entities (say, the smartphone and the 4G cellular tower), rather than by retransmissions between the client and the server. These usually don't lead to real end-to-end packet loss, but rather show up as variations in packet latency (or “jitter”) and reordered packet arrivals.

So, let's say we are using a per-packet round-robin multiplexer ( ABCABCABCABCABCABCABCABC… ) to get the most out of HoL blocking removal, and we get a bursty loss of just 4 packets. We see that this will always impact all 3 streams (see figure 8, middle row)! In this case, QUIC's HoL blocking removal provides no benefits, because all streams have to wait for their own retransmissions .

To lower the risk of multiple streams being affected by a lossy burst, we need to concatenate more data for each stream. For example, AABBCCAABBCCAABBCCAABBCC… is a small improvement, and AAAABBBBCCCCAAAABBBBCCCC… (see bottom row in figure 8 above) is even better. You can again see that a more sequential approach is better, even though that reduces the chances that we have multiple concurrent active streams.

In the end, predicting the actual impact of QUIC's HoL blocking removal is difficult, because it depends on the number of streams, the size and frequency of the loss bursts, how the stream data is actually used, etc. However, most results at this time indicate it will not help much for the use case of web-page loading, because there we typically want fewer concurrent streams.

If you want even more detail on this topic or just some concrete examples, please check out my in-depth article on HTTP HoL blocking.

Did You Know?

As with the previous sections, some advanced techniques can help us here. For example, modern congestion controllers use packet pacing. This means that they don't send, for example, 100 packets in a single burst, but rather spread them out over an entire RTT. This conceptually lowers the chances of overloading the network, and the QUIC Recovery RFC strongly recommends using it. Complementarily, some congestion-control algorithms such as BBR don't keep increasing their send rate until they cause packet loss, but rather back off before that (by looking at, for example, RTT fluctuations, because RTTs also rise when a network is becoming overloaded).

While these approaches lower the overall chances of packet loss, they don't necessarily lower its burstiness.

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

While QUIC's HoL blocking removal means, in theory, that it (and HTTP/3) should perform better on lossy networks, in practice this depends on a lot of factors. Because the use case of web-page loading typically favours a more sequential multiplexing set-up, and because packet loss is unpredictable, this feature would, again, likely affect mainly the slowest 1% of users . However, this is still a very active area of research, and only time will tell.

Still, there are situations that might see more improvements. These are mostly outside of the typical use case of the first full page load — for example, when resources are not render blocking, when they can be processed incrementally, when streams are completely independent, or when less data is sent at the same time.

Examples include repeat visits on well-cached pages and background downloads and API calls in single-page apps. For example, Facebook has seen some benefits from HoL blocking removal when using HTTP/3 to load data in its native app.

أداء UDP و TLS

يتعلق جانب الأداء الخامس لـ QUIC و HTTP / 3 بمدى كفاءة وأداء إنشاء الحزم وإرسالها على الشبكة. سنرى أن استخدام QUIC لـ UDP والتشفير الثقيل يمكن أن يجعله أبطأ قليلاً من TCP (لكن الأمور تتحسن).

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

كما تمت مناقشته أعلاه ، عادةً ما يتم تنفيذ TCP و UDP مباشرةً في النواة السريعة لنظام التشغيل. في المقابل ، تكون تطبيقات TLS و QUIC في الغالب في مساحة مستخدم أبطأ (لاحظ أن هذا ليس ضروريًا حقًا لـ QUIC - يتم ذلك في الغالب لأنه أكثر مرونة بكثير). هذا يجعل QUIC بالفعل أبطأ قليلاً من TCP.

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

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

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

على عكس النقطة الأولى ، حيث يمكننا إضافة واجهات برمجة تطبيقات إضافية لجعل UDP (وبالتالي QUIC) أسرع ، هنا ، سيكون لـ QUIC دائمًا عيب ملازم لـ TCP + TLS. ومع ذلك ، يمكن أيضًا التحكم في هذا الأمر في الممارسة العملية ، على سبيل المثال ، مكتبات التشفير المُحسّنة والطرق الذكية التي تسمح بتشفير رؤوس حزم QUIC بكميات كبيرة.

نتيجة لذلك ، بينما كانت إصدارات QUIC الأولى من Google لا تزال بطيئة مرتين مثل TCP + TLS ، فقد تحسنت الأمور بالتأكيد منذ ذلك الحين. على سبيل المثال ، في الاختبارات الأخيرة ، تمكنت مكدس QUIC المحسّن بشكل كبير من Microsoft من الحصول على 7.85 جيجابت في الثانية ، مقارنة بـ 11.85 جيجابت في الثانية لـ TCP + TLS على نفس النظام (لذلك هنا ، QUIC هو حوالي 66٪ أسرع من TCP + TLS).

هذا مع تحديثات Windows الأخيرة ، والتي جعلت UDP أسرع (للمقارنة الكاملة ، كان معدل نقل UDP على هذا النظام 19.5 جيجابت في الثانية). يعد الإصدار الأكثر تحسينًا من حزمة QUIC من Google أبطأ بنسبة 20٪ من TCP + TLS. الاختبارات السابقة التي أجرتها Fastly على نظام أقل تقدمًا ومع بعض الحيل تدعي أداءً متساويًا (حوالي 450 ميجابت في الثانية) ، مما يدل على أنه اعتمادًا على حالة الاستخدام ، يمكن لـ QUIC بالتأكيد منافسة TCP.

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

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

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

وبالمثل ، قال Facebook أنه من المحتمل أن يتم استخدام QUIC بشكل أساسي بين المستخدمين النهائيين وحافة CDN ، ولكن ليس بين مراكز البيانات أو بين العقد الطرفية والخوادم الأصلية ، نظرًا لزيادة حجمها. بشكل عام ، من المحتمل أن تستمر سيناريوهات النطاق الترددي العالي جدًا في تفضيل TCP + TLS ، خاصة في السنوات القليلة المقبلة.

هل كنت تعلم؟

تحسين مكدسات الشبكة هو ثقب أرنب عميق وتقني يخدش ما ورد أعلاه السطح فقط (ويفتقد الكثير من الفروق الدقيقة). إذا كنت شجاعًا بما يكفي أو إذا كنت تريد معرفة المصطلحات مثل GRO/GSO و SO_TXTIME و kernel bypass و sendmmsg() و recvmmsg() أن أوصي ببعض المقالات الممتازة حول تحسين QUIC بواسطة Cloudflare و Fastly أيضًا ككود تجول شامل من Microsoft ، ومحادثة متعمقة من Cisco. أخيرًا ، قدم أحد مهندسي Google كلمة رئيسية شيقة للغاية حول تحسين تنفيذ QUIC بمرور الوقت.

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

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

HTTP / 3 الميزات

حتى الآن ، تحدثنا بشكل أساسي عن ميزات الأداء الجديدة في QUIC مقابل TCP. ومع ذلك ، ماذا عن HTTP / 3 مقابل HTTP / 2؟ كما تمت مناقشته في الجزء الأول ، فإن HTTP / 3 هو في الواقع HTTP / 2-over-QUIC ، وعلى هذا النحو ، لم يتم تقديم ميزات جديدة كبيرة حقيقية في الإصدار الجديد. هذا على عكس الانتقال من HTTP / 1.1 إلى HTTP / 2 ، والذي كان أكبر بكثير وقدم ميزات جديدة مثل ضغط الرأس ، وتحديد أولويات البث ، ودفع الخادم. لا تزال جميع هذه الميزات في HTTP / 3 ، ولكن هناك بعض الاختلافات المهمة في كيفية تنفيذها تحت الغطاء.

هذا في الغالب بسبب كيفية عمل إزالة QUIC لحظر HoL. كما ناقشنا ، لم تعد الخسارة في الدفق B تعني أن التدفقات A و C يجب أن تنتظر إعادة إرسال B ، كما فعلت عبر TCP. على هذا النحو ، إذا أرسل كل من A و B و C حزمة QUIC بهذا الترتيب ، فقد يتم تسليم بياناتهم (ومعالجتها بواسطة) المتصفح كـ A و C و B! بعبارة أخرى ، على عكس TCP ، لم يعد QUIC مرتبًا بالكامل عبر التدفقات المختلفة!

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

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

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

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

بينما ، مرة أخرى ، يقدم النهجان نفس الميزة الأساسية (توجيه تعدد إرسال البث) ، فإن الأمل هو أن يؤدي إعداد HTTP / 3 الأسهل إلى تقليل أخطاء التنفيذ.

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

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

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

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

التطورات المستقبلية التي يجب البحث عنها

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

• تصحيح الخطأ المرسل
  هذا الغرض من هذه التقنية ، مرة أخرى ، هو تحسين مرونة QUIC لفقدان الحزم . يقوم بذلك عن طريق إرسال نسخ مكررة من البيانات (على الرغم من تشفيرها وضغطها بذكاء بحيث لا تكون كبيرة). بعد ذلك ، إذا فقدت حزمة ولكن وصلت البيانات الزائدة عن الحاجة ، لم تعد هناك حاجة لإعادة الإرسال.
  
  كان هذا في الأصل جزءًا من Google QUIC (وأحد الأسباب التي تجعل الناس يقولون إن QUIC مفيد ضد فقدان الحزمة) ، ولكن لم يتم تضمينه في الإصدار 1 من QUIC القياسي لأن تأثيره في الأداء لم يثبت بعد. يقوم الباحثون الآن بإجراء تجارب نشطة عليه ، على الرغم من ذلك ، ويمكنك مساعدتهم باستخدام تطبيق PQUIC-FEC Download Experiments.

• Multipath QUIC
  لقد ناقشنا سابقًا ترحيل الاتصال وكيف يمكن أن يساعد عند الانتقال من شبكة Wi-Fi مثلاً إلى شبكة خلوية. ومع ذلك ، ألا يعني ذلك أيضًا أننا قد نستخدم كل من شبكة Wi-Fi والخلية في نفس الوقت ؟ في نفس الوقت ، فإن استخدام كلتا الشبكتين من شأنه أن يمنحنا المزيد من النطاق الترددي المتوفر والمتانة المتزايدة! هذا هو المفهوم الرئيسي وراء تعدد المسارات.
  
  هذا ، مرة أخرى ، شيء جربته Google ولكنه لم يصل إلى الإصدار 1 من QUIC نظرًا لتعقيده المتأصل. ومع ذلك ، فقد أظهر الباحثون منذ ذلك الحين إمكاناته العالية ، وقد يتم تحويله إلى الإصدار الثاني من QUIC. لاحظ أن تعدد مسارات TCP موجود أيضًا ، ولكن هذا استغرق ما يقرب من عقد من الزمان ليصبح قابلاً للاستخدام عمليًا.

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

• WebTransport
  لا تعرض المستعرضات TCP أو UDP لجافا سكريبت بشكل مباشر ، ويرجع ذلك أساسًا إلى مخاوف أمنية. بدلاً من ذلك ، يتعين علينا الاعتماد على واجهات برمجة التطبيقات على مستوى HTTP مثل Fetch وبروتوكولات WebSocket و WebRTC الأكثر مرونة إلى حد ما. الأحدث في هذه السلسلة من الخيارات يسمى WebTransport ، والذي يسمح لك بشكل أساسي باستخدام HTTP / 3 (وبالتالي ، QUIC) بطريقة منخفضة المستوى (على الرغم من أنه يمكن أيضًا الرجوع إلى TCP و HTTP / 2 إذا لزم الأمر ).
  
  بشكل حاسم ، سيتضمن القدرة على استخدام بيانات غير موثوقة عبر HTTP / 3 (انظر النقطة السابقة) ، مما يجعل تنفيذ أشياء مثل الألعاب أسهل قليلاً في المتصفح. بالنسبة إلى مكالمات API العادية (JSON) ، ستستمر بالطبع في استخدام Fetch ، والذي سيستخدم أيضًا HTTP / 3 تلقائيًا عندما يكون ذلك ممكنًا. لا يزال WebTransport قيد المناقشة المكثفة في الوقت الحالي ، لذا لم يتضح بعد كيف سيبدو في النهاية. من بين المتصفحات ، يعمل Chromium فقط حاليًا على تنفيذ إثبات المفهوم العام.

• دفق فيديو DASH و HLS
  بالنسبة للفيديو غير المباشر (مثل YouTube و Netflix) ، تستخدم المتصفحات عادةً بروتوكولات البث الديناميكي التكيفي عبر HTTP (DASH) أو HTTP Live Streaming (HLS). كلاهما يعني بشكل أساسي أنك تقوم بترميز مقاطع الفيديو الخاصة بك إلى أجزاء أصغر (من 2 إلى 10 ثوانٍ) ومستويات جودة مختلفة (720p ، 1080p ، 4K ، إلخ).
  
  في وقت التشغيل ، يقدر المتصفح أعلى جودة يمكن لشبكتك التعامل معها (أو أفضل جودة لحالة استخدام معينة) ، ويطلب الملفات ذات الصلة من الخادم عبر HTTP. نظرًا لأن المتصفح ليس لديه وصول مباشر إلى مكدس TCP (كما يتم تطبيقه عادةً في النواة) ، فإنه يرتكب أحيانًا بعض الأخطاء في هذه التقديرات ، أو يستغرق بعض الوقت للرد على ظروف الشبكة المتغيرة (مما يؤدي إلى توقف الفيديو) .
  
  نظرًا لأنه يتم تنفيذ QUIC كجزء من المتصفح ، يمكن تحسين ذلك قليلاً ، من خلال منح مقدرات التدفق الوصول إلى معلومات البروتوكول منخفضة المستوى (مثل معدلات الخسارة وتقديرات النطاق الترددي ، وما إلى ذلك). قام باحثون آخرون بتجربة خلط البيانات الموثوقة وغير الموثوقة لتدفق الفيديو أيضًا ، مع بعض النتائج الواعدة.

• بروتوكولات أخرى غير HTTP / 3
  نظرًا لأن QUIC هو بروتوكول نقل للأغراض العامة ، يمكننا أن نتوقع العديد من بروتوكولات طبقة التطبيقات التي تعمل الآن عبر TCP ليتم تشغيلها أعلى QUIC أيضًا. تتضمن بعض الأعمال الجارية DNS-over-QUIC و SMB-over-QUIC وحتى SSH-over-QUIC. نظرًا لأن هذه البروتوكولات عادةً ما تحتوي على متطلبات مختلفة جدًا عن HTTP وتحميل صفحات الويب ، فإن تحسينات أداء QUIC التي ناقشناها قد تعمل بشكل أفضل مع هذه البروتوكولات.

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

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

خاتمة

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

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

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

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

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

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

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

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

مقتنع أخيرا؟ ثم تابع إلى الجزء 3 من السلسلة لتقرأ عن كيفية استخدام البروتوكولات الجديدة في الممارسة العملية.