ما هو HTTP/2 و ما الجديد
لا يرغب أحد منا بتصفح موقع بطيء! سرعة تحميل صفحات الويب عامل مهم جدًا في تحسين تجربة المستخدم User Experience وتقييم محركات البحث. كما تعرف فلا أحد يحب الانتظار ولن يتردد المستخدمون عادةً في الانتفال إلى موقع أسرع في حال كان موقعك يستغرق الكثير من الوقت في تحميل صفحاته. نحن نتحدث عن أرقام دقيقة، كل ملي ثانية تًحسب وتؤثر سلبًا او إيجاباً في رضى المستخدمين عن أداء موقعك، ونتيجة لهذا فلطالما حاول مطوري صفحات الويب تحسين سرعة تحميل الصفحات عبر التخزين المؤقت، ضغط المحتويات وتقليل عدد العناصر…الخ
ولكن الأمر ليس بهذه البساطة، فتقنيات الويب التي تم تصميمها في العقد الماضي لم تكن مثالية للويب 2.0 واستيعاب التضخم الهائل في عدد المستخدمين وازدياد نهمهم في معرفة المزيد من المعلومات! ولهذا ابتكر مطوري الويب حلولاً بديلة لمواجهة المشاكل الموجودة في البنية الأساسية للويب، مثل الـ Spriting، Inlining، Concatenation، Sharding وغيرها.
ولكن ألن يكون من الأفضل تطوير البنية الأساسية للويب بدلاً من تطبيق كل تلك الحلول البديلة التي تعقد عملية تصميم وتطوير صفحات الويب؟!
نعم، فلا يخفى علي أحد التطويرات الجديدة في معايير لغات الويب، مثل الـ HTML5 وECMAScript 6 وCSS3. ولكن الأمر لا يتوقف عند هذا الحد فنحن اليوم أمام نقطة تحول التي تتمثل في التطوير الجديد لمعيار بروتوكول الـ HTTP.
لقد قضى الباحثون سنوات في تطوير النسخة الجديدة من البروتوكول، فمنذ وقت إنشاء مجموعة العمل HTTPbis بواسطة منظمة الـ IETF في صيف عام 2007 حتى بدأت النقاشات هنا وهناك تتساءل وتطرح الاقتراحات حول ما يجب أن يكون عليه التحديث الجديد للبروتوكول الأكثر أهمية في الويب.
بروتوكول SPDY من شركة Google تم إنشاؤه كبروتوكول متطور ومنفصل عن الـ HTTP في بادئ الأمر. تم الإعلان عنه في منتصف عام 2009 وكما كان متوقعًا فقد حاز على إعجاب الكثير وبدأت نسبة لا بأس بها من الشركات والمطورين في دعمه واستخدامه في تطبيقاتهم ومشاريعهم.
مضت الأيام وعند بدأ مجموعة العمل HTTPbis باستقبال المقترحات في عام 2012 تمت الكثير من النقاشات حينها وفي نهاية الأمر تم الاتفاق على الاعتماد على بروتوكول SPDY كنقطة بداية في العمل على بروتوكول HTTP/2.
مفاهيم وخطوط عريضة قامت مجموعة العمل HTTPbis بالالتزام بها أثناء تصميم بروتوكول الـ HTTP/2:
- يجب عليه الحفاظ على نفس نموذج عمل الـ HTTP، بحيث يبقى بروتوكولاً مبنيًا على فكرة التخاطب بين Client وServer.
- يجب ألا يحتوي على أي تغيير في نظام تسمية الروابط التشعبية URLs، ويحتفظ بنفس اسم البروتوكول http:// وhttps://.
- يجب أن يكون هناك توافق بين الـ HTTP/2 وHTTP/1 بحيث تكون الأجهزة التي تعمل وفق بروتوكول HTTP/1 قادرة على التواصل مع الأجهزة التي تعمل على بروتوكول HTTP/2 والعكس صحيح.
- يجب أن يتم تقليل أو حذف الأجزاء الاختيارية، بحيث يصبح دعم كل أجزاء البروتوكول إلزاميًا على من يريدون تطبيقه.
- لا مزيد من الإصدارات الثانوية، إن كان هناك حاجة لتعديل أو توسيع شيء ما في الـ HTTP/2 فسيتم إصدار الـ HTTP/3، لن توجد إصدارات ثانوية مثل: HTTP/2.1 وغيرها.
هذا يكفي حول الخلفية، التاريخ والمفاهيم العامة، دعونا نستعرض بعض اللمحات حول التغييرات الجديدة.
بروتوكول ثنائي
لم يعد بروتوكول الـ HTTP في نسخته الجديدة HTTP/2 بروتوكولاً نصيًا text-based بل أصبح بروتوكولاً ثنائيًا binary-based لجعل عملية التأطير framing أكثر سهولة مما مضى. مما يجعله غير قابل للقراءة من قبل البشر non-human-readable وبالتالي تعقيد عملية تنقيح محتويات البيانات المتبادلة ولكن الأمر مازال ممكنًا عبر بعض الأدوات مثل Wireshark وcURL.
التيارات المتعددة
اتصال HTTP/2 واحد من الممكن أن يحتوي على أكثر من تيار ثنائي الاتجاه bi-directional stream مفتوح في نفس الوقت، وكل frame يرفق مع stream معين. مما يسمح لعدة طلبات وردود بتشارك نفس عرض النطاق (Bandwidth) بدون الحاجة إلى إنشاء أو تأسيس اتصال منفصل لكل طلب و رد على حدة.
الأولويات والتبعيات
كل تيار stream يحمل بارامتر لتحديد أولويته priority بحيث يستخدم في الإخبار عن أي من التيارات هو أكثر أهمية من غيره. بالإضافة إلى وجود بارامتر لتحديد التبعية dependency والذي يستخدم في منع عملية معالجة تيار ما حتي يتم الانتهاء من معالجة التيار المعتمد عليه.
ضغط الترويسة
بروتوكول الـ HTTP عديم الحالة state-less يعامل كل طلب معاملة مستقلة بحيث لا يكون للطلب علاقة بالطلبات السابقة. لا يتطلب هذا النوع من البروتوكولات أن يحتفظ الخادم بمعلومات كثيرة حول الطلبات السابقة، مما يعني أن كل طلب يجب أن يتضمن كل المعلومات التفصيلية التي يحتاجها الخادم لتفسير الطلب.
عندما يقوم العميل بطلب العديد من الموارد من نفس الخادم، ستكون هناك سلسلة كبيرة من الطلبات التي تبدو متشابهة. وهذا ما يستدعي وجود فكرة ضغط الترويسة Header Compression.
تقنية الضغط المستخدمة في الـ HTTP/2 المسماة HPACK تم نشرها كمسودة منفصلة ولن يكفي هذا المقال لشرحها بشكل كافي، لذا سنؤجل حديثنا عنها إلى وقت لاحق.
مبادرة الخادم
ميزة الـ Server Push هي إحدى الخصائص الجديدة المضافة إلى البروتوكول، فكرتها هي في حال طلب العميل المورد X والخادم يعرف بأن العميل من المرجح أن يحتاج أيضًا إلى المورد Z، فسيقوم الخادم بالمبادرة وإرسال المورد Z بدون أن يطلب منه العميل ذلك. العميل يجب أن يسمح للخادم بشكل صريح باستخدام هذه الميزة، وفي حالة أن الخادم أرسل مورداً لا يرغب العميل باستقباله بإمكانه إيقاف الخادم عبر إرسال أمر التحكم RST_STREAM.
بالتأكيد، هذا ليس كل شيء! إن أردت معرفة المزيد بإمكانك الاطلاع على المعلومات التفصيلية في مسودة الـ HTTP/2 الرسمية،يجب أن ننوه إلى أن دعم وتطبيق النسخة الجديدة من البروتوكول بشكل كامل سيستغرق الكثير من الوقت على الرغم من أن عدد من المتصفحات الشعبية مثل: الجوجل كروم وفايرفوكس وبعض تطبيقات إدارة خوادم الويب مثل: Nginx بدأت فعلاً بدعمه. ونحن نأمل بأن يصبح الويب أسرع وأكثر موثوقية بوجود الـ HTTP/2 في المستقبل القريب لينعم المستخدمين والمطورين بالسعادة والهناء!
المصدر مدونة نشوان الدعقان.
أشكرك على الموضوع الرائع ، والمعلومات القيّمة ، المرتبة والمفيدة .
أشكر مرورك صديقي
جميل اخي الكريم معلومات حقاً قيمة تسلم 🙂