حذف المستقبل الترويسة القديمة. لكنه لم يحتفظ بدليل يشرح سبب الحذف

الخلاصة

• يطلب RFC 5372 من المستقبل الاحتفاظ بآخر ترويسة رئيسية كاملة فقط مع mh_id ورقم تسلسل RTP. وصول ترويسة كاملة بمعرّف مختلف ليس مجرد كتابة فوق ذاكرة؛ إنه حدث إبطال واستبدال يجب أن يبقى قابلاً للمراجعة.
• يملك mh_id سبع قيم فعالة فقط. بعد ستة تغييرات متتالية غير مرئية يمكن أن يعود الرقم إلى قيمة قديمة، فتنجح مقارنة المعرّف مع أن الترويسة المحفوظة صارت قديمة.
• إثبات التعويض الموثوق يتطلب سجل التفاوض، وبصمة الترويسة الكاملة، وتسلسل الانتقالات، وقرار الحذف، ومحاولة التعويض، ونتيجة مفكك الترميز، ونتيجة العرض. لا ينوب أي رابط عن الآخر.

آخر ترويسة كاملة هي حالة تشغيلية، لا حقيقة أبدية

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

لكن الوفرة تعتمد على حالة محلية. المرسل لا يضع نسخة مشفرة من الترويسة داخل mh_id؛ يضع إشارة قصيرة إلى استمرارية مجموعة محددة من المعلمات. المستقبل هو الذي يملك البايتات المحفوظة، وهو الذي يقرر إن كانت صالحة للمحاولة الحالية. لذلك لا تكفي عبارة «cache hit». ينبغي أن نعرف أي كائن دخل الذاكرة، ومن أي SSRC وجلسة، وعند أي تسلسل، وبأي بصمة، وما الذي حدث منذ ذلك الوقت.

يحدد RFC 5372 أن المستقبل يحفظ الترويسة الرئيسية الكاملة ورقم تسلسل RTP ومعرّفها. كما يحدد أنه عندما يستقبل ترويسة كاملة بمعرّف يختلف عن المعرّف المحفوظ، يحذف الترويسة القديمة ويخزن الجديدة. كلمة «يحذف» هنا ترسم حد صلاحية. الترويسة السابقة لم تعد مرجعاً صالحاً للتعويض لمجرد أنها كانت صالحة قبل لحظة.

إذا سجّل النظام الحالة النهائية فقط، فسيرى المحقق mh_id=4 وبصمة واحدة. لن يعرف إن كان الرقم أربعة وصل مع ترويسة كاملة، أم نُسخ من رزمة بلا ترويسة، أم أعيد بعد دورة، أم بقي عبر إعادة تشغيل، أم جاء من مصدر مزامنة آخر. سجل الانتقال أهم من لقطة الذاكرة لأنه يشرح لماذا نُقلت السلطة من كائن إلى كائن.

الاكتمال شرط الدخول إلى الذاكرة

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

لهذا ينبغي أن يتضمن إيصال الإدخال نطاقات البايتات الملاحظة، ومواضع الأجزاء، واستمرارية التسلسل، وهوية الجلسة والمصدر، وبصمة البايتات بعد التجميع. إذا كانت الترويسة غير كاملة فلا يجوز ترقيتها إلى «آخر ترويسة كاملة» حتى لو حملت معرّفاً جديداً. الرقم يصف حالة المرسل؛ لا يملأ الفراغ المحلي.

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

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

سبع قيم لا تمنح سبعة عصور دائمة

يستخدم mh_id ثلاثة بتات، لكن القيمة صفر لها معنى خاص: تعطيل حفظ الترويسة الرئيسية والتعويض عنها. تبقى القيم من واحد إلى سبعة لحالة التعويض النشطة. عندما تتغير معلمات الترميز المعنية، يزيد المرسل القيمة، وبعد سبعة يعود إلى واحد.

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

يفرض ذلك قيداً دقيقاً على لغة التشغيل. يمكن القول إن المعرّف الوارد يساوي المعرّف المحفوظ. لا يمكن القفز إلى القول إن الترويسة المحفوظة هي الترويسة التي قصدها المرسل للإطار الحالي. تصبح القفزة معقولة فقط عندما تحفظ المراقبة ما يكفي من استمرارية الانتقالات وتستبعد دورة غير مرئية.

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

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

الصفر يسحب التفويض بدلاً من تسمية ترويسة

القيمة صفر ليست «الترويسة رقم صفر». يطلب RFC 5372 من المرسل استخدامها عندما لا يُستخدم التعويض، ومن المستقبل ألا يحفظ ترويسة رئيسية لغرض التعويض وألا يعوض عند استقبالها. إنها امتناع صريح عن اختصار الحالة.

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

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

التفاوض يفتح الإمكانية ولا يملأ الذاكرة

تقدم آلية العرض والجواب في SDP المعلمة mhc للإشارة إلى دعم تعويض الترويسة الرئيسية. قبول الطرفين للقيمة المناسبة يثبت اتفاقاً على استخدام الآلية. لكنه لا يثبت أن أي ترويسة كاملة وصلت بعد بدء الوسائط، ولا يحدد بصمتها، ولا يقول إن cache بقيت حديثة.

ينبغي فصل إيصال control plane عن إيصال media plane. الأول يقول إن الطرفين يفهمان العقد. الثاني يقول إن رزمًا بعينها وصلت، وأن التجميع اكتمل، وأن حالة محلية أُنشئت. إذا أظهر سجل SDP نجاح mhc=1 بينما لا توجد بصمة ترويسة كاملة، فالنظام يملك قدرة متفاوضاً عليها ولا يملك أساساً مثبتاً للتعويض.

يظهر الفرق بوضوح في multicast. قد يرسل مصدر واحد حقول الامتداد، بينما يستقبل بعض المشاركين بالامتداد وبعضهم بدونه. يستطيع المستقبل غير الداعم تجاهل الحقول وفق قواعد التوافق ولا ينتج بالضرورة نفس telemetry. غياب حدث cache لديه لا يعني فقداً على الشبكة؛ قد يعني أنه لا يطبق هذا العقد أصلاً.

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

الأولوية صفر تعني أهمية المحتوى، لا حجز النقل

يربط RFC 5372 نمط أولوية بمكونات payload JPEG 2000. تكون الترويسة الرئيسية ذات الأولوية الأعلى، ويمكن أن تحمل أجزاء أخرى قيماً تعكس progression order أو الطبقة أو الدقة أو المكوّن. في هذا السياق تشير أولوية الصفر إلى مادة شديدة الأهمية لفك الترميز.

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

هذا مهم لحوكمة cache لأن فقد الترويسات الانتقالية هو ما يسمح للمعرّف المحدود بالدوران نحو حالة قديمة. لا يجوز لإدارة أن تقول إن الخطر أُغلق لأن الترويسة حملت أولوية صفر. التصنيف نية؛ القياس هو الدليل على تنفيذها. وإذا لم تتدخل الشبكة في الحقل، يجب أن يبقى ذلك ظاهراً بدلاً من ملء إيصال غير موجود.

سلامة الرزم لا توثق الأحداث الغائبة

يمكن لـ SRTP أو آليات حماية مناسبة أن تحمي سرية الرزم وسلامتها وهوية مصدرها ضمن حدود عقدها. ويستطيع IPsec أن يقدم حماية على طبقة أخرى. هذه خصائص حقيقية ومهمة، لكنها تخص المادة التي وصلت وخضعت للتحقق.

لا تستطيع المصادقة أن تثبت أن ست ترويسات انتقالية لم تُرسل أو لم تُحجب، ولا تستطيع إنشاء سجل للتغيرات التي لم يرها المستقبل. يمكن أن تكون كل رزمة موجودة موثقة تماماً، بينما تكون سلسلة الإبطال ناقصة. لذلك ينبغي عدم تفسير «جميع الرزم المستلمة authenticated» على أنه «cache freshness authenticated».

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

اكتشاف مفكك الترميز يأتي بعد اختيار الحالة

يوصي RFC 5372 بأن يمسح المستقبل المعرّف والترويسة المحفوظين عندما يكتشف مفكك الترميز عدم اتساق. هذه آلية احتواء مفيدة. لكنها تعمل بعد أن اختار النظام الترويسة وحاول استخدامها.

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

كما ينبغي تسجيل الحذف الناتج عن inconsistency بشكل مختلف عن الاستبدال الطبيعي بترويسة كاملة جديدة. الأول يقول إن الثقة سُحبت بسبب فشل؛ الثاني يقول إن سلطة جديدة دخلت عبر مسار صحيح. دمجهما في metric واحدة باسم cache miss يخفي السبب ويمنع تحسين السياسة.

نموذج إيصال لانتقال الترويسة

يمكن تمثيل كل انتقال في سجل صغير لكنه غني:

• هوية جلسة RTP وSSRC ووصف payload المتفاوض عليه؛
• دعم mhc ونمط الأولوية وإصدار المرسل والمستقبل؛
• mh_id الوارد ورقم تسلسل أول وآخر رزمة في الترويسة؛
• نطاقات fragment offset واختبار اكتمال main header؛
• بصمة ثابتة للبايتات الكاملة وملخص معلمات SIZ وCOD وCOC وRGN وQCD وQCC وPOC؛
• الحالة السابقة وسبب بقائها أو استبدالها أو حذفها؛
• الفجوات التي قد تخفي تغيرات وعدد دورات المعرّف غير القابل للحسم؛
• قرار التعويض، ونسخة مفكك الترميز، ونتيجته؛
• إنتاج الإطار وتسليمه إلى طبقة العرض ونتيجة العرض إن كانت قابلة للرصد.

لا يعني هذا إرسال كل البايتات إلى لوحة مركزية. يمكن حفظ البصمة والحد الأدنى اللازم محلياً مع سياسة احتفاظ مناسبة. المقصود هو ألا تصبح القيمة القصيرة بديلاً عن أصل الكائن وفترة صلاحيته.

يجب أن يكون لكل حذف سبب محدد: استبدال كامل، اكتشاف عدم اتساق، تغير جلسة، إعادة تفاوض، انتهاء محلي، إعادة تشغيل، أو قرار مشغل. «cache cleared» بلا سبب يخفي من امتلك القرار ويجعل المقارنة اللاحقة مستحيلة.