الأداء والكفاءة: العمل مع HTTP / 3

HTTP / 3 يلوح في الأفق ، يتبعه في أعقاب HTTP / 2 - والذي يمكن القول أنه لا يزال صغيرًا جدًا. بالنظر إلى أن الأمر استغرق 16 عامًا للانتقال من HTTP / 1.1 إلى HTTP / 2 ، فهل ينبغي لأي شخص حقًا أن يهتم بـ HTTP / 3؟

الإجابة المختصرة: نعم ، إنها مهمة ، ويجب أن تكون على دراية بها. يشبه الأمر تمامًا الطريقة التي أجرى بها HTTP / 2 تغييرات مهمة من HTTP / 1.1 عن طريق التبديل من ASCII إلى نظام ثنائي. يقوم HTTP / 3 مرة أخرى بإجراء تغييرات مهمة ، هذه المرة عن طريق تبديل النقل الأساسي من TCP إلى UDP.

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

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

القضية الرئيسية: الأداء والكفاءة

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

يمكن أن يؤدي التأخير البالغ 100 مللي ثانية في وقت تحميل موقع الويب إلى الإضرار بمعدلات التحويل بنسبة 7 بالمائة.

تقرير أداء البيع بالتجزئة عبر الإنترنت من Akamai: المللي ثانية بالغة الأهمية (2017)

بعبارة أخرى ، فإن موقع التجارة الإلكترونية الذي تبلغ مبيعاته 40 ألف دولار في اليوم سيخسر مليون دولار سنويًا بسبب هذا التأخير.

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

وجدت الأبحاث أيضًا أن:

• يتوقع 47٪ من المستهلكين تحميل صفحة الويب في ثانيتين أو أقل.
• يغادر 40٪ من الأشخاص موقع الويب الذي يستغرق تحميله أكثر من 3 ثوانٍ.

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

HTTP / 2؟ …ما هذا؟

يعد الفهم الجيد لبروتوكول HTTP / 2 أمرًا بالغ الأهمية لفهم HTTP / 3. بادئ ذي بدء ، لماذا كانت هناك حاجة إلى HTTP / 2؟

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

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

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

مايك بيلشي

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

في المقابل ، فإن تقليل وقت الاستجابة له فائدة مستمرة ويحقق أفضل النتائج.

HTTP HOL: مشكلة حظر رأس الخط

السبب الرئيسي لوقت الاستجابة ضمن بروتوكول HTTP / 1 هو مشكلة حظر رأس الخط. تتطلب صفحات الويب (دائمًا تقريبًا) موارد متعددة: CSS ، و JavaScript ، والخطوط ، والصور ، و AJAX / XMR ، وما إلى ذلك. وهذا يعني أن متصفح الويب يحتاج إلى تقديم طلبات متعددة إلى الخادم. ومع ذلك ، ليست كل الموارد مطلوبة لكي تصبح الصفحة مفيدة.

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

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

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

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

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

HTTP / 2's HTTP HOL Blocking Solution. حل حظر HTTP HOL الخاص بـ HTTP / 2

قدم HTTP / 2 تعدد إرسال استجابة للطلب عبر اتصال واحد. لا يمكن للمتصفح فقط بدء طلب جديد في أي وقت ، ولكن يمكن تلقي الردود بأي ترتيب - يتم إلغاء الحظر تمامًا على مستوى التطبيق.

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

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

HTTP / 2 تأطير ثنائي

يحول HTTP / 2 معيار بروتوكول HTTP من نموذج استجابة الطلب ASCII غير الفعال القابل للقراءة البشرية إلى تأطير ثنائي فعال. لم يعد مجرد طلب واستجابة:

باستخدام HTTP / 2 ، تتحدث المتصفحات مع الخوادم عبر تدفقات ثنائية الاتجاه برسائل متعددة ، كل منها يتكون من إطارات متعددة.

HTTP / 2 HPACK (ضغط الرأس)

يوفر ضغط رأس HTTP / 2 الجديد ، باستخدام تنسيق HPACK ، قدرًا كبيرًا من النطاق الترددي لمعظم المواقع. وذلك لأن غالبية الرؤوس هي نفسها للطلبات المرسلة ضمن اتصال.

تبلغ Cloudflare عن توفير كبير في النطاق الترددي بفضل HPACK وحده:

• 76٪ ضغط لدخول الرؤوس
• انخفاض بنسبة 53٪ في إجمالي حركة الدخول
• 69٪ ضغط لرؤوس الخروج
• 1.4٪ إلى 15٪ انخفاض في إجمالي حركة الخروج

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

HTTP / 2 أولوية البث ودفع الخادم

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

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

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

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

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

لسوء الحظ ، تحتاج كلتا هاتين الميزتين إلى الكثير من التكوين الدقيق من قبل مطوري الويب لتحقيق النجاح حقًا. مجرد تمكينهم لا يكفي.

من الواضح أن HTTP / 2 يجلب العديد من المزايا المحتملة - بعضها أرخص في الاستفادة من البعض الآخر. كيف حالهم في العالم الحقيقي؟

HTTP مقابل اعتماد HTTP / 2

تم إنشاء SPDY في عام 2009. تم توحيد HTTP / 2 في عام 2015. أصبح SPDY اسم فرع التطوير غير المستقر من الكود ، وأصبح HTTP / 2 هو الإصدار النهائي. والنتيجة هي أن SPDY قد عفا عليه الزمن ، و HTTP / 2 هو المعيار الذي يتبعه الجميع.

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

نقص دعم المستعرض لـ HTTP / 2 Clear Text Mode

كان هناك العديد من المكالمات لـ HTTP / 2 لجعل التشفير جزءًا مطلوبًا من المعيار. بدلاً من ذلك ، حدد المعيار كلا الوضعين المشفر (h2) والنص الواضح (h2c). على هذا النحو ، يمكن أن يحل HTTP / 2 محل HTTP / 1 تمامًا.

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

لماذا HTTP / 3؟ وكيف تختلف؟

مع إصلاح مشكلة حظر رأس سطر HTTP الآن بواسطة HTTP / 2 ، حوّل مطورو البروتوكول انتباههم إلى أكبر مشغل زمن انتقال: مشكلة حظر رأس سطر TCP .

بروتوكول التحكم في الإرسال (TCP)

تعتمد شبكات IP (بروتوكول الإنترنت) على فكرة إرسال أجهزة الكمبيوتر للحزم الأخرى. الحزمة هي مجرد بيانات مع بعض معلومات العنونة المرفقة بالأعلى.

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

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

في تشرين الأول (أكتوبر) من عام 1986 ، كان الإنترنت أول ما أصبح سلسلة من "انهيارات الازدحام". خلال هذه الفترة ، انخفض معدل نقل البيانات من LBL إلى جامعة كاليفورنيا في بيركلي (مواقع مفصولة بـ 400 ياردة وثلاث قفزات IMP) من 32 كيلوبت في الثانية إلى 40 نقطة في الثانية.

جاكوبسون (1988)

هذا هو المكان الذي تأتي فيه مشكلة حظر رأس خط TCP.

مشكلة حظر TCP HOL

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

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

يهدف مشروع آخر من Google إلى حل هذه المشكلة من خلال تقديم بروتوكول يسمى QUIC.

تم إنشاء بروتوكول QUIC أعلى UDP بدلاً من TCP ، وتشكل QUIC الأساس لـ HTTP / 3.

ما هو UDP؟

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

والغرض منه هو أن يكون خفيف الوزن ويوفر الحد الأدنى من الميزات اللازمة للسماح بالاتصال. بهذه الطريقة يمكن للتطبيق تنفيذ الضمانات الخاصة به. غالبًا ما يكون هذا مفيدًا جدًا في تطبيقات الوقت الفعلي. على سبيل المثال ، في المكالمات الهاتفية ، يفضل المستخدمون عمومًا تلقي 90٪ من البيانات على الفور ، بدلاً من 100٪ من البيانات في النهاية.

حل TCP HOL الخاص بـ HTTP / 3

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

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

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

مشفر دائما

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

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

تأثير HTTP / 3 على البنية التحتية للشبكات

HTTP / 3 لا يخلو من الجدل. المخاوف الرئيسية تتعلق بالبنية التحتية للشبكات.

HTTP / 3 من جانب العميل

من جانب العميل ، من الشائع جدًا أن تكون حركة مرور UDP محدودة و / أو محظورة بشكل كبير. تطبيق هذه القيود على HTTP / 3 يهزم نقطة البروتوكول.

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

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

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

HTTP / 3 من جانب الخادم

من جانب الخادم ، من الأفضل حظر أي منافذ وبروتوكولات لا تتوقع حركة مرور ، مما يعني أن مسؤولي الخادم يحتاجون الآن إلى فتح UDP 443 لـ HTTP / 3 ، بدلاً من الاعتماد على قواعد TCP 443 الحالية الخاصة بهم.

ثانيًا ، يمكن للبنية التحتية للشبكة أن تجعل جلسات TCP ثابتة ، مما يعني أنه سيتم توجيهها دائمًا إلى نفس الخادم حتى مع تغير أولويات التوجيه. نظرًا لأن HTTP / 3 يعمل عبر UDP - وهو بدون جلسة - تحتاج البنية التحتية للشبكة إلى التحديث لتتبع معرفات الاتصال الخاصة بـ HTTP / 3 ، والتي تُركت غير مشفرة على وجه التحديد للمساعدة في التوجيه الثابت.

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

أخيرًا ، يعترض الكثير من المسؤولين على الاضطرار إلى إدارة المزيد من شهادات SSL ، على الرغم من أن هذه مشكلة أقل الآن مع توفر خدمات مثل Let's Encrypt.

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

تأثير HTTP / 3 على تطوير الويب

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

باستخدام HTTP / 3 الآن

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

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

1. إعداد DNS. احصل على اسم مضيف عامل ومباشر على الإنترنت ، على سبيل المثال yourhostname.example.com IN A 192.0.2.1 .
2. إنشاء ملف العلبة. يجب أن تحتوي على هذه الأسطر:

 yourhostname.example.com log stdout errors stdout ext .html .htm .md .txt browse gzip tls [email protected]

1. Running Caddy: docker run -v Caddyfile:/etc/Caddyfile -p 80:80 -p 443:443 abiosoft/caddy --quic - أو خارج Docker، caddy --quic .
2. تشغيل الكروم مع تمكين QUIC: chromium --enable-quic
3. (اختياري) تثبيت ملحق بروتوكول مؤشر.
4. الانتقال إلى الخادم الذي يدعم QUIC ، حيث يجب أن يكون متصفح الملفات مرئيًا.

يمكن للمطورين أيضًا اختبار خوادمهم باستخدام الأدوات المفيدة التالية:

• اختبار HTTP / 2 الخاص بـ Keycdn
• LiteSpeed's HTTP3Check
• اختبار خادم SSL من Qualys

شكرا للقراءة!