الخلاصة

  • تجعل RFC 9218 أولوية HTTP اقتراحاً ومدخلاً واحداً للجدولة، ولا تضمن ترتيب المعالجة أو الإرسال أو الاكتمال.
  • يجب أن يربط سجل يمكن الدفاع عنه الإشارة في كل قفزة بسياسة الدمج وحالة المجدول وتوزيع البايتات والتوقيت والنتيجة الظاهرة للمستخدم.

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

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

تعرّف RFC 9218 مخططاً قابلاً للتوسعة لترتيب استجابات HTTP. يحمل حقل Priority إشارة من طرف إلى طرف. أما أطر PRIORITY_UPDATE في HTTP/2 وHTTP/3 فتحمل الأولوية الابتدائية أو المعدلة في قفزة واحدة. لذلك لا يثبت التقاط الحقل عند المتصفح القيمة التي دخلت إلى المجدول الأخير.

المعاملات الأساسية بسيطة عن قصد. تتراوح درجة الاستعجال u من 0 إلى 7؛ الرقم الأصغر يعني أسبقية أعلى، والقيمة الافتراضية 3. ويشير المعامل التزايدي i إلى إمكان إنتاج فائدة من أجزاء الاستجابة عند وصولها، وقيمته الافتراضية غير مفعّلة. هذه لغة لتوصيف رأي الطرف، وليست خوارزمية عامة للطابور أو السعة أو ترتيب الاكتمال.

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

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

يمكن أن تتغير الأولوية بعد إرسال الطلب. فقد يبدأ المتصفح جلب ملف مسبقاً في الخلفية ثم يرفعه إلى أولوية عاجلة عند التنقل. يحمل PRIORITY_UPDATE المجموعة الحالية الكاملة من المعاملات وقد يتسابق مع فتح المسار المقصود. لذا يجب أن يحتفظ الدليل بترتيب حقول الطلب والاستجابة، وأطر التحديث، وأوقات وصولها، ولقطة المجدول التي تعاملت معها.

تضيف الوسائط حداً آخر. يمكنها دمج أولوية طلب العميل مع أولوية استجابة الخادم الأصلي، وتترك RFC 9218 طريقة الدمج للتنفيذ. وعندما تجمع الوسيطة طلبات عدة عملاء في اتصال خلفي واحد، قد يؤدي الالتزام المطلق بكل u=0 معلنة ذاتياً إلى تأخير الآخرين. تستطيع سياسة إنصاف محلية تقييد الأفضلية بصورة مشروعة، حتى لو خالفت توقعاً بسيطاً مبنياً على الحقل الأول.

توضح RFC 9113 أن آلية الأولوية السابقة في RFC 7540 لم تُنفذ بصورة موحدة وأصبحت مهجورة في HTTP/2 الحالي. وعندما تكون إشارات الأولوية مهمة، يوصى ببديل مثل RFC 9218. لذلك يجب أن يحدد السجل الذي يقول «أولوية HTTP/2» المخطط والإعدادات المتفاوض عليها وسلوك التنفيذ.

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

وهكذا يبقى R066 منفصلاً عن الموضوعات المجاورة. يسأل BGP Add-Path عما إذا كانت المسارات المعلنة تمثل نطاقات عطل مستقلة. وتتناول RFC 8097 مصدر حالة التحقق من منشأ المسار. وتناول R065 الصلاحية المدعومة بالشهادة لكل أصل على اتصال واحد. أما هنا فالسؤال هو: هل أنتج اقتراح جدولة HTTP سلوك التسليم المنسوب إليه فعلاً؟

المصادر