الخلاصة

  • تفصل RFC 9369 عمداً بين اسم «QUIC version 2» وقيمة 0x6b3343cf في الرأس الطويل. مشاهدة القيمة واقعة تخص حزمة محددة، لا إحصاء للنشر.
  • على الطرف الذي يدعم v2 أن يرسل ويعالج ويتحقق من معلومات إصدار موثقة. وبعد ربطها بسجل المصافحة لا تصف إلا اختيار إصدار في اتصال واحد، ولا تثبت نشر أسطول أو نجاح تطبيق أو التزام شبكة أخرى.

تغري أسماء الإصدارات بحكاية سريعة: v1 قديم، وv2 منشور، إذن العالم انتقل. ترفض RFC 9369 أن تحل هذه الحكاية محل الأدلة. يسمي Martin Duke «version 2» اسماً غير رسمي لثاني إصدار QUIC منشور على مسار Standards Track، ثم يضع 0x6b3343cf في حقل Version للرأس الطويل. ليست القيمة هي الرقم اثنين، بل مشتقة من hash. الغرض ليس الغموض؛ بل منع الصناديق الوسيطة من تحويل نمط v1 المألوف إلى افتراض دائم.

هناك ثلاث طبقات من الوقائع. تقول RFC ما هي القاعدة المشتركة. يسجل IANA القيمة المخصصة. ويسجل الالتقاط أن قيمة شوهدت في حزمة على مسار وزمن معلومين. كل واحدة نافعة ويمكن فحصها، لكن أياً منها لا يحصي الأطراف المفعلة، ولا يثبت أن النظير الأخير يدعم v2، ولا يثبت اكتمال TLS، ولا أن تطبيقاً أعاد نتيجة. اختزال أي طبقة إلى عبارة «تم نشر v2» يحذف الحلقات اللازمة بين التسمية والواقع.

فرق v2 عن v1 محدود عمداً. ترث الوثيقة معظم سلوك v1، وتغير أنواع حزم الرأس الطويل وInitial salt وتسميات HKDF ومواد سلامة Retry. يكفي ذلك لاختبار تفاوض الإصدار وكشف الافتراضات المتصلبة حول v1. لكنه لا يمنح المراقب خريطة لقدرات تنفيذ كامل. تذكر RFC 8999 أن افتراض أن حزمة بقيمة Version معينة تعني أن ذلك الإصدار مستخدم هو افتراض خاطئ. الحقل معرف مقدم أو مستلم؛ ومعناه التشغيلي تحدده نقطة النهاية وبقية التبادل.

لا يجوز القفز عند جانب الخادم. قد يصل Initial يبدو v2 إلى موازن حمل، ومكوّن Retry بلا حالة، وطبقة تمرير، وخادم تطبيق، ولا يلزم أن تتطابق معرفتها بالإصدارات. أثر الحافة ليس إثباتاً لإعداد المعالج الأخير. وحزمة Version Negotiation لا تحسم المسألة؛ فهي بلا حماية سلامة أو سرية وفق RFC 8999. تعطي connection IDs المنسوخة مؤشراً محدوداً إلى أن المرسل رأى المرور، لكن RFC 9368 تلزم الطرف بتوثيق المضمون الدلالي قبل التصرف بناءً على إصدار آخر. الدليل الأقوى هو حالة مصافحة موثقة ومرتبطة بهذه المحاولة، لا قائمة وصلت إلى الحافة.

ولا تهدف v2 إلى إلغاء v1. فإعلان Alt-Svc بـ h3 لا يفرق بين إصدارات QUIC؛ لذا ينبغي للأصل الذي يعلنه أن يبقي v1 كي لا يفرض عدم توافق أو رجوعاً إلى TCP على عملاء أقدم. v1 وv2 متوافقان، وعلى الطرف الذي يدعم الاثنين أن يدعم التفاوض المتوافق لتفادي رحلة إضافية. هذا وصف لشروط التشغيل البيني، لا أمر بإزالة v1 أو بتشغيل v2 أو بإعلان شبكة تحتفظ بمجموعة توافق أخرى غير صالحة.

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

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

وينبغي ضبط دور Martin Duke بالمقدار نفسه. يثبت ملفه في IETF وRFC 9369 تأليف مواصفة Standards Track؛ ولا يجعلان منه مالك QUIC أو صاحب القرار في نشر HTTP/3 أو ممثل مستخدمي جميع الأطراف. قيمة الوثيقة أنها تجعل تغيراً مستقبلياً قابلاً للفحص من غير ادعاء أن النشر الورقي يحول الشفرة المحلية إلى حقيقة عالمية.

تساعد فكرة Heng Lu عن المواصفة الأولية الدنيا على قراءة هذا التصميم دون تحميل QUIC نظرية حكم. تضع الطبقة المشتركة قواعد حتمية للتشغيل البيني والأمن، أما التنفيذ وتوقيته والتبني فيبقى لمن يشغل النظام. القيمة غير الحرفية والتوافق الصريح والتفاوض الموثق أمثلة تقنية على هذا التواضع.

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

المصادر