مقدمة عن HTTP/2

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

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

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

لماذا لا يتم استخدام HTTP/1.2؟

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

ومع ذلك، لن تلاحظ أي اختلاف ما لم تكن تنفّذ خادم ويب (أو برنامجًا مخصصًا) من خلال العمل باستخدام مقابس TCP الأولية، فلن ترى أي اختلاف: يتم تنفيذ جميع الإطارات الجديدة منخفضة المستوى بواسطة العميل والخادم نيابةً عنك. وستتمثل الاختلافات الوحيدة الملحوظة في تحسين الأداء وتوفُّر الإمكانات الجديدة مثل تحديد أولويات الطلبات والتحكم في التدفق وإرسال الخادم.

لمحة تاريخية عن SPDY وHTTP/2

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

• استهداف تقليل وقت تحميل الصفحة (PLT) بنسبة 50%
• تجنب الحاجة إلى إجراء أي تغييرات على المحتوى من قبل مؤلفي الموقع.
• يمكنك تقليل تعقيدات النشر وتجنُّب التغييرات في البنية الأساسية للشبكة.
• يمكنك تطوير هذا البروتوكول الجديد بالشراكة مع منتدى البرامج مفتوحة المصدر.
• جمع بيانات الأداء الحقيقية (في) التحقق من البروتوكول التجريبي.

بعد الإعلان الأولي، شارك مايك بلشي وروبرتو بيون، وهما مهندسا برمجيات في Google، النتائج الأولى والوثائق والرمز المصدر للتطبيق التجريبي لبروتوكول SPDY الجديد:

حتى الآن لم نختبر سوى SPDY في الظروف المعملية. كانت النتائج الأولية مشجّعة للغاية، فعندما ننزّل أفضل 25 موقعًا إلكترونيًا من خلال محاكاة اتصالات الشبكات المنزلية، نلاحظ تحسنًا كبيرًا في الأداء، إذ يتم تحميل الصفحات بشكل أسرع بنسبة تصل إلى% 55. (مدونة Chromium)

في عام 2012، ظهر البروتوكول التجريبي الجديد في متصفّح Chrome وFirefox وOpera، وكان هناك عدد متزايد من المواقع الإلكترونية الكبيرة (مثل Google وTwitter وFacebook) والصغيرة. في الواقع، كان SPDY على المسار الصحيح كي يصبح معيارًا فعليًا من خلال الاعتماد المتزايد على هذا المجال.

ومن خلال ملاحظة هذا الاتجاه، شرعت مجموعة عمل HTTP (HTTP-WG) في بذل جهد جديد لاستخلاص الدروس المستفادة من SPDY، وتصميمها وتحسينها، وتقديم معيار "HTTP/2" رسمي. تمت صياغة ميثاق جديد، وتم تقديم طلب مفتوح لاقتراحات HTTP/2، وبعد الكثير من المناقشات داخل مجموعة العمل، تم اعتماد مواصفات SPDY كنقطة بداية لبروتوكول HTTP/2 الجديد.

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

• آذار (مارس) 2012: طلب عروض HTTP/2
• تشرين الثاني (نوفمبر) 2012: أول مسودة لـ HTTP/2 (استنادًا إلى SPDY)
• آب (أغسطس) 2014: تم نشر مسودة HTTP/2 17 وHPACK مسودّة-12
• آب (أغسطس) 2014: النداء الأخير لمجموعة العمل لبروتوكول HTTP/2
• شباط (فبراير) 2015: مسودات HTTP/2 وHPACK المعتمدة من IESG
• أيار (مايو) 2015: تم نشر RFC 7540 (HTTP/2) وRFC 7541 (HPACK)

في مطلع عام 2015، راجع فريق IESG معيار HTTP/2 الجديد ووافق عليه لجهة النشر. بعد ذلك بفترة وجيزة، أعلن فريق Google Chrome عن جدوله الزمني لإيقاف إضافة SPDY وNPN لطبقة النقل الآمنة:

تركّز التغييرات الأساسية في HTTP/2 على HTTP/1.1 على تحسين الأداء. وقد تطوّرت بعض الميزات الرئيسية مثل تعدد الإرسال وضغط العنوان وتحديد الأولوية وتفاوض البروتوكول من العمل الذي تم تنفيذه في بروتوكول مفتوح ولكن غير عادي يسمى SPDY. لقد أصبح Chrome متوافقًا مع بروتوكول SPDY بدايةً من متصفّح Chrome 6، ولكن بما أنّ معظم المزايا متوفّرة في HTTP/2، حان الوقت لإيقافهما. ونخطط لإزالة التوافق مع بروتوكول SPDY في بدايات عام 2016، كما نخطّط أيضًا لإزالة إتاحة إضافة بروتوكول أمان طبقة النقل (TLS) المسماة NPN لصالح ALPN في Chrome في الوقت نفسه. ننصح مطوّري برامج الخادم بأهمية الانتقال إلى HTTP/2 وALPN.

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

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

الأهداف الفنية والأهداف

وقد تم تصميم الإصدارات السابقة من بروتوكول HTTP عمدًا لتيسير التنفيذ: كان HTTP/0.9 بروتوكولاً من سطر واحد لتشغيل شبكة الويب العالمية، ووثّق HTTP/1.0 الإضافات الشائعة لبروتوكول HTTP/0.9 في معيار إعلامي، فيما قدّم HTTP/1.1 معيارًا رسميًا لمجموعة مهندسي شبكة الإنترنت (IETF)، ويمكنك الاطّلاع على سجلّ موجز لبروتوكول HTTP. وبناءً على ذلك، قدَّم HTTP/0.9-1.x ما تم إعداده بالضبط: HTTP هو واحد من أكثر بروتوكولات التطبيق استخدامًا على نطاق واسع على الإنترنت.

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

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

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

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

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

طبقة الإطار الثنائي

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

تشير "الطبقة" إلى اختيار تصميم لتقديم آلية ترميز محسَّنة جديدة بين واجهة المقبس وواجهة برمجة التطبيقات HTTP الأعلى المعروضة لتطبيقاتنا: لا تتأثر دلالات HTTP، مثل الأفعال والأساليب والعناوين، ولكن طريقة ترميزها أثناء النقل مختلفة. على عكس بروتوكول HTTP/1.x بنص عادي محدد بالنص العادي، يتم تقسيم كل اتصالات HTTP/2 إلى رسائل وإطارات أصغر، ويتم ترميز كل منها بتنسيق ثنائي.

نتيجةً لذلك، على كل من العميل والخادم استخدام آلية الترميز الثنائي الجديدة للتعرّف على أحدهما الآخر: لن يفهم عميل HTTP/1.x خادم HTTP/2 فقط، والعكس صحيح. ولحسن الحظ، تظل تطبيقاتنا غير مدركة لجميع هذه التغييرات، حيث ينفِّذ العميل والخادم جميع أعمال الإطارات اللازمة نيابةً عنا.

ساحات المشاركات والرسائل والإطارات

يؤدي طرح آلية جديدة للتأطير الثنائي إلى تغيير كيفية تبادل البيانات بين العميل والخادم. لوصف هذه العملية، دعونا نتعرف على مصطلح HTTP/2:

• البث المباشر: هو تدفق ثنائي الاتجاه لوحدات البايت ضمن اتصال منشأ، وقد يحمل رسالة واحدة أو أكثر.
• الرسالة: هي تسلسل كامل من الإطارات التي يتم ربطها بطلب أو رسالة رد منطقيَين.
• الإطار: أصغر وحدة اتصال في HTTP/2، وتحتوي كل وحدة منها على عنوان إطار، وتحدّد على الأقل البث الذي ينتمي إليه الإطار.

ويمكن تلخيص علاقة هذين المصطلحين على النحو التالي:

• يتم إجراء جميع الاتصالات عبر اتصال TCP واحد الذي يمكنه نقل أي عدد من التدفقات ثنائية الاتجاه.
• لكل مصدر بيانات معرّف فريد ومعلومات أولوية اختيارية تُستخدم لنقل الرسائل ثنائية الاتجاه.
• تكون كل رسالة عبارة عن رسالة HTTP منطقية، مثل طلب أو استجابة تتكون من إطار واحد أو أكثر.
• الإطار هو أصغر وحدة اتصال تحمل نوعًا محددًا من البيانات - على سبيل المثال، عناوين HTTP وحمولة الرسائل وما إلى ذلك. يمكن دمج الإطارات من مجموعات بث مختلفة ثم إعادة تجميعها باستخدام معرّف البث المضمّن في عنوان كل إطار.

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

تعدد إرسال الطلبات والاستجابة

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

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

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

إنّ القدرة على تقسيم رسالة HTTP إلى إطارات مستقلة، وتداخلها، ثم إعادة تجميعها من الطرف الآخر، هي أهم تحسين في بروتوكول HTTP/2. في الواقع، لها تأثير مضاعف من خلال العديد من مزايا الأداء على مستوى الحزمة التي تشمل جميع تقنيات الويب، ما يتيح لنا إجراء ما يلي:

• تداخل طلبات متعددة بشكل متوازٍ بدون حظر أي طلب منها
• يمكنك تداخل ردود متعددة بالتوازي بدون حظر أي منها.
• استخدِم عملية ربط واحدة لتقديم طلبات وردود متعددة بشكل متوازٍ.
• أزل حلول HTTP/1.x غير الضرورية (راجع تحسين HTTP/1.x، مثل الملفات المتسلسلة والأجزاء المدمجة للصور وتقسيم النطاق).
• قلِّل أوقات تحميل الصفحات من خلال الحدّ من وقت الاستجابة غير الضروري وتحسين استخدام سعة الشبكة المتاحة.
• وغير ذلك الكثير...

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

تحديد أولوية البث

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

• يمكن ضبط عدد صحيح لكل مصدر بيانات بين 1 و256.
• وقد يتم منح كل بث تبعية صريحة على مصدر آخر.

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

يتم الإعلان عن اعتمادية مصدر البيانات ضمن HTTP/2 من خلال الإشارة إلى المعرّف الفريد لمصدر بيانات آخر كمصدر أساسي. إذا تم حذف المعرّف، سيُقال إنّ مصدر البيانات يعتمد على "مصدر البيانات الجذر". يشير إعلان تبعية مصدر البيانات إلى أنّه يجب، إن أمكن، تخصيص موارد لمصدر البيانات الرئيسي قبل العناصر التابعة له. بمعنى آخر، "يرجى معالجة وتقديم الردّ "د" قبل الرد "ج".

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

1. مجموع كل معاملات الترجيح: 4 + 12 = 16
2. قسمة كل وزن بث على إجمالي الوزن: A = 12/16, B = 4/16

وبالتالي، يُفترض أن تتلقى البث "أ" ثلاثة أرباع، وأن تحصل مجموعة البث "ب" على ربع الموارد المتاحة، أما بالنسبة إلى البث "ب"، فيجب أن يحصل على ثلث الموارد المخصصة للبث "أ". دعنا نعمل من خلال بعض الأمثلة العملية في الصورة أعلاه. من اليمين إلى اليسار:

1. لا تحدد الدفق A أو B تبعية رئيسية ويقال أنها تعتمد على "تدفق الجذر" الضمني؛ حيث يبلغ الوزن A 12، ووزن B هو 4. وبالتالي، بناءً على الترجيحات النسبية: يجب أن تحصل مجموعة البث "ب" على ثلث الموارد المخصّصة للبث "أ".
2. يعتمد البث D على البث الجذر، بينما تعتمد C على D. بالتالي، ينبغي أن تحصل D على تخصيص كامل للموارد قبل C. الأوزان غير مهمة لأن تبعية C تنقل تفضيلاً أقوى.
3. ينبغي أن تتلقى مجموعة البث "د" تخصيص كامل للموارد قبل "ج"، ويجب أن تتلقى "ج" تخصيصًا كاملاً للموارد قبل "أ" و"ب"، ويجب أن تتلقى الدفق "ب" ثلث الموارد المخصصة للبث "أ".
4. يجب أن تتلقى مجموعة البث "د" توزيعًا كاملاً للموارد قبل "هـ" و"ج"، ويجب أن تتلقى "هـ" و"ج" تخصيصًا متساويًا قبل "أ" و"ب"؛ ويجب أن تحصل "أ" و"ب" على تخصيص نسبي بناءً على ترجيحاتها.

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

عملية اتصال واحدة لكل مصدر

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

بالنسبة إلى كل من SPDY وHTTP/2، تتمثل الميزة القاتلة في تعدد الإرسال العشوائي على قناة واحدة يتم التحكم فيها في تكدس البيانات. إنه يدهشني مدى أهمية ذلك ومدى نجاحه. أحد المقاييس الرائعة التي أستمتع بها هو جزء الاتصالات التي تم إنشاؤها والتي لا تتضمن سوى معاملة HTTP واحدة (وبالتالي تجعل هذه المعاملة تتحمل كل النفقات). بالنسبة إلى HTTP/1، فإنّ 74% من اتصالاتنا النشطة تُجري معاملة واحدة فقط، والاتصالات المستمرة ليست مفيدة كما نريد. ولكن في HTTP/2، ينخفض هذا الرقم إلى 25%. وهذا مكسب كبير لخفض النفقات العامة. (HTTP/2 متاح في Firefox، Patrick McManus)

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

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

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

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

• عنصر التحكّم في التدفق هو اتّجاهي. قد يختار كل مستلم ضبط أي حجم نافذة يرغب في كل بث وكل الاتصال.
• يعتمد التحكم في التدفق على الائتمان. يُعلِن كل مستلم عن الاتصال الأولي ونافذة التحكم في تدفق البث (بالبايت)، ويتم تقليلها كلما أرسل المُرسِل إطار DATA وتتم زيادته عبر إطار WINDOW_UPDATE يرسله المستلِم.
• لا يمكن إيقاف التحكم في التدفق. عند إنشاء اتصال HTTP/2، يتم إنشاء إطارَي SETTINGS لتبادل العميل والخادم، ما يحدد حجم نافذة التحكّم في التدفق في كلا الاتجاهين. يتم ضبط القيمة التلقائية لنافذة التحكم في التدفق على 65,535 بايت، ولكن يمكن للمستلم ضبط حد أقصى كبير لحجم النافذة (2^31-1 بايت) والحفاظ عليه من خلال إرسال إطار WINDOW_UPDATE كلما تم استلام أي بيانات.
• التحكم في التدفق هو خطوة بخطوة، وليس من البداية إلى النهاية. بمعنى أنه يمكن للوسيط استخدامه للتحكم في استخدام الموارد وتنفيذ آليات تخصيص الموارد بناءً على معاييره وأساليبه الإرشادية.

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

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

إرسال المعلومات إلى العميل قبل طلبها من الخادم

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

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

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

• تم التخزين المؤقت من قِبل العميل
• أُعيد استخدامها في صفحات مختلفة
• إرسال متعدد إلى جانب موارد أخرى
• حسب الأولوية بواسطة الخادم
• رفضها العميل

PUSH_PROMISE 101

يتم بدء جميع عمليات إرسال إرسال البيانات من الخادم من خلال إطارات PUSH_PROMISE، ما يشير إلى أنّ الخادم يحتاج إلى إرسال الموارد الموضّحة إلى العميل، وبالتالي يجب إرسالها قبل بيانات الاستجابة التي تطلب الموارد التي تم إرسالها. يُعد طلب التسليم هذا أمرًا بالغ الأهمية: يحتاج العميل إلى معرفة الموارد التي يريد الخادم إرسالها لتجنب إنشاء طلبات مكررة لهذه الموارد. إنّ أبسط استراتيجية لتحقيق هذا الشرط هي إرسال جميع إطارات PUSH_PROMISE التي تحتوي على عناوين HTTP فقط للمورد الواعد قبل استجابة العنصر الرئيسي (أي إطارات DATA).

بعد أن يتلقّى العميل إطار PUSH_PROMISE، يمكنه رفض البث (من خلال إطار RST_STREAM) إذا أراد ذلك. (قد يحدث هذا على سبيل المثال لأن المورد موجود بالفعل في ذاكرة التخزين المؤقت). وهذا تحسين مهم مقارنةً ببروتوكول HTTP/1.x. في المقابل، إنّ استخدام تضمين الموارد، والذي يشكّل "تحسينًا" شائعًا في HTTP/1.x، يعادل "عملية إرسال إجبارية": لا يمكن للعميل إيقاف هذا الخيار أو إلغاؤه أو معالجة المورد المضمَّن بشكل فردي.

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

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

ضغط العنوان

تتضمن كل عملية نقل HTTP مجموعة من الرؤوس التي تصف المورد الذي يتم نقله وخصائصه. أمّا في HTTP/1.x، فيتم إرسال هذه البيانات الوصفية دائمًا كنص عادي، كما تُضيف من 500 إلى 800 بايت من البيانات العامة في كل عملية نقل، وأحيانًا أكثر بمقدار كيلوبايت في حال استخدام ملفات تعريف ارتباط HTTP. (راجِع قياس مقدار النفقات العامة لبروتوكول البروتوكول والتحكم فيه ).

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

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

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

أمان وأداء HPACK

كانت الإصدارات الأولى من HTTP/2 وSPDY تستخدم zlib، مع قاموس مخصص، لضغط جميع عناوين HTTP. وقد أدى ذلك إلى انخفاض في حجم بيانات الرأس المنقولة بنسبة تتراوح بين% 85 و% 88، فضلاً عن تحسّن كبير في وقت استجابة تحميل الصفحة:

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

إلا أنه في صيف 2012، تم نشر هجوم أمني "CRIME" ضد خوارزميات ضغط TLS وSPDY، مما قد يؤدي إلى الاستيلاء على الجلسة. ونتيجة لذلك، تم استبدال خوارزمية ضغط zlib بخوارزمية HPACK التي تم تصميمها خصيصًا لمعالجة المشاكل الأمنية التي تم اكتشافها، والفعالية وسهولة التنفيذ بشكل صحيح، وبالطبع، يمكن الضغط بشكل جيد على البيانات الوصفية لرأس HTTP.

للحصول على التفاصيل الكاملة لخوارزمية ضغط HPACK، يمكنك الاطّلاع على IETF HPACK - ضغط العنوان لـ HTTP/2.

محتوى إضافي للقراءة

• "HTTP/2" – المقالة الكاملة من تأليف "إيليا غريغوريك"
• "إعداد HTTP/2" – كيفية إعداد HTTP/2 في خلفيات مختلفة بواسطة Surma
• "HTTP/2 متوفّر الآن، لنجري التحسين" – عرض تقديمي من قبل إيليا غريغوريك من شركة Velocity في عام 2015
• "Rules of Thumb for HTTP/2 Push": تحليل أجراه "توم بيرغان" و"سيمون بيلشات" و"مايكل بوتنر" حول وقت استخدام ميزة الدفع وكيفية استخدامها.