الخلاصة

  • اقترح Mark Nottingham اسم «HTTP/3» ليظهر أن المقصود هو ربط دلالات HTTP بوسيلة نقل QUIC، لا نقل QUIC نفسه.
  • جمع اقتراحه بين الاسم وتقسيم العمل: بعد النشر، ينبغي أن يتولى فريق HTTP صيانة HTTP/3 وQPACK. وتوثق مواثيق IETF اللاحقة هذا الترتيب.
  • أوضح الحدّ الفاصل من يقرر ومن يصون كل جزء، لكنه لا يضمن توافق التنفيذ أو النشر، ولا يجعل اقتراح Nottingham قراراً فردياً.

في أواخر 2018، كان اسم «QUIC» يشير أحياناً إلى بروتوكول النقل، وأحياناً إلى ربط HTTP الذي يعمل فوقه. وبدأ من لم يتابعوا النقاش يخلطون بين الأمرين. لم تكن المشكلة مجرد صياغة: عندما يبدو النقل وبروتوكول التطبيق كأنهما منتج واحد، يصبح تحديد الجهة التي تقرر التغييرات المستقبلية أصعب أيضاً.

في 28 أكتوبر، كتب Mark Nottingham إلى قائمة فريق عمل QUIC. اقترح تسمية وثيقة HTTP «HTTP/3» واستخدام h3 معرّفاً نهائياً في ALPN. فبحسب حجته، يوضح الاسم أن الوثيقة تربط دلالات HTTP ببروتوكول على السلك، كما فعل HTTP/2، ويفصل هذا العمل عن QUIC بوصفه وسيلة نقل. وتتيح الرسالة الأصلية قراءة مبرراته مباشرة.

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

فصل الاجتماع بين التأييد وحق القرار

في اجتماع IETF 103، ناقش فريق QUIC الاسم. وتظهر المحاضر قراءات متباينة: رأى بعض المشاركين في HTTP/3 خلفاً لـ HTTP/2، وخشي آخرون أن يوحي الاسم بفرع منفصل. أشار Nottingham إلى أن HTTP/2 لم يلغِ HTTP/1.1 ولم يستبدله. والأهم، كما قال، هو الفصل بين دلالات HTTP والبروتوكول الذي يحملها على السلك.

لا تصف المحاضر اقتراعاً رسمياً. بل تسجل تعبيراً غير رسمي عن التأييد: نحو 70 إلى 30 لصالح تغيير الاسم، مقابل شبه إجماع على أن يترك القرار لفريق HTTPbis. وتكشف الإشارة الثانية موضع السلطة المقصود. فقد نشأ العمل في مجموعة QUIC، لكن تسمية بروتوكول HTTP ينبغي أن تقررها جماعة HTTP. وقال Nottingham صراحة إن تسمية HTTP يجب أن تبقى في مجتمع HTTP.

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

يصبح الاسم دقيقاً حين تبقى الطبقات ظاهرة

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

ولا يساوي معرّف ALPN h3 الاسم العام HTTP/3. فالأول معرّف يستخدم على السلك أثناء التفاوض على البروتوكول؛ أما الاسم فيساعد الناس على تصنيف الوثيقة والعمل. وكتب Nottingham أن الاسم لن يصبح رسمياً ولن يستخدم على السلك قبل نشر RFC، ما أبقى مجالاً لمراجعة المقترح قبل أن يؤثر المعرّف في التوافق بين التنفيذات.

كما دخل نقل الصيانة في وثائق الحوكمة. نص ميثاق HTTPbis لعام 2018 على أن يتولى HTTPbis صيانة HTTP/3 وتطوير امتداداته عند الحاجة بعد أن ينشر فريق QUIC العمل، بما في ذلك QPACK. ويضع ميثاق HTTP الحالي HTTP/3 وQPACK ضمن المواصفات الأساسية لـ HTTP. كما يذكر ميثاق QUIC الحالي أن ذلك الفريق أنشأ الربط وQPACK، لكنهما يُصانان الآن في فريق HTTP.

هذا الحدّ ليس جداراً. فما زال فريق QUIC يدرج عملاً على أحداث qlog الخاصة بـ HTTP/3، وهي منطقة تلتقي فيها مراقبة النقل والتطبيق. والأدق أن المسؤولية الأساسية موزعة بحسب الطبقة: يصون فريق HTTP ربط HTTP وتوسعاته، بينما يستمر فريق QUIC في تناول الآليات الخاصة بالنقل. وتظل المحاذاة بين الفريقين ضرورية لأن الطبقتين تلتقيان في الأنظمة العاملة.

النشر لا يساوي التشغيل

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

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

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

المصادر