مقدمة عن 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. على وجه التحديد، تم تحديد أهداف المشروع المحددة على النحو التالي:

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

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

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

انتقلنا سريعًا إلى عام 2012 وتم اعتماد البروتوكول التجريبي الجديد في Chrome وFirefox وOpera. وهناك عدد متزايد بشكل سريع من المواقع الكبيرة (على سبيل المثال Google وTwitter وFacebook) والصغيرة، نشرت SPDY ضمن بنيتها التحتية. في الواقع، كان 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: تم نشر الإصدار 2 من بروتوكول HTTP/2 ومسودة الإصدار 12 من بروتوكول HPACK.
  • آب (أغسطس) 2014: الاتصال الأخير لمجموعة العمل لبروتوكول HTTP/2
  • شباط (فبراير) 2015: وافق IESG على مسودات HTTP/2 وHPACK
  • أيار (مايو) 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. ويتيح ذلك أيضًا تحديد أولويات الطلبات والسماح بإكمال المزيد من الطلبات المهمة بسرعة أكبر، ما يؤدي إلى تحسين الأداء بشكل أكبر.

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

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

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

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

طبقة إطارات HTTP/2 الثنائية

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

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

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

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

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

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

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

مجموعات البث والرسائل والإطارات HTTP/2

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

مضاعفة الطلبات والاستجابة لها

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

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

مضاعفة طلبات الاستجابة وطلبات HTTP/2 ضمن اتصال مشترك

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

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

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

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

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

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

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

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

التبعيات والترجيحات لتدفق HTTP/2

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

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

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

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

  1. لا يحدد البث A أو B التبعية الأصلية ويُقال إنّه يعتمدان على "التدفق الجذر" الضمني؛ ويبلغ وزن A 12، بينما يبلغ وزن B 4. وبالتالي، بناءً على القيم التقديرية التناسبية: يجب أن يتلقى البث "ب" ثلث الموارد المخصصة للبث "أ".
  2. يعتمد الدفق "د" على البث الجذري، فيما تعتمد "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 فقط إلى تقليل وقت استجابة الشبكة، بل سيساعد أيضًا في تحسين سرعة معالجة البيانات وخفض تكاليف التشغيل.

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

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

هل تذكرك المتطلبات المذكورة أعلاه بالتحكم في تدفق بروتوكول التحكم بالنقل؟ يجب إجراء ذلك، لأنّ المشكلة متطابقة بشكل فعّال (راجِع التحكّم في التدفق). ومع ذلك، لأنّ ساحات مشاركات 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. (راجع قياس النفقات العامة للبروتوكول والتحكم فيها .) لتقليل هذه النفقات العامة وتحسين الأداء، يضغط بروتوكول HTTP/2 البيانات الوصفية للطلب والاستجابة باستخدام تنسيق ضغط HPACK الذي يستخدم أسلوبين بسيطين وفعالين في الوقت نفسه:

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

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

HPACK: ضغط العنوان لبروتوكول HTTP/2

كإجراء إضافي التحسين، يتألف سياق ضغط 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.

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