الخلاصة

  • كرر RFC 3545 قيم السياق المتغيرة في N+1 حزمة كي تتاح للمفككة فرصة إعادة التزامن ما دام اندفاع الفقد ضمن الحد المفترض للرابط.
  • أتاح HDRCKSUM الاختياري فحص الرؤوس المعاد بناؤها حين يكون checksum لـUDP في IPv4 صفراً، لكنه لم يشمل Identification؛ وبعد فقد أكثر من N حزم متجاورة كان الأأمن إبطال السياق وطلب حالته.

كان للفحص موضع لا يراه. سمح RFC 3545 للضاغط بأن يستبدل checksum صفرياً لـUDP في IPv4 بـchecksum للرأس من 16 بت، بحيث تستطيع المفككة فحص إعادة البناء. لكن Identification في IPv4 لم يكن ضمن الحقول التي يفحصها ذلك checksum. في رابط قليل الفقد قد يظل هذا الاستثناء كامناً داخل آلية استعادة أوسع. أما بعد ضياع حزم متجاورة كثيرة، فيغيّر ما يمكن أن تعنيه كلمة «استعادة» بثقة.

يضغط CRTP، المحدد في RFC 2508، رؤوس IP وUDP وRTP مع إبقاء سياق مشترك لدى الطرفين. ينشئ رأس كامل الحالة أولاً، ثم تنقل الحزم اللاحقة التغييرات أو القيم التفاضلية. إذا ضاعت حزمة تحمل تحديثاً، يتقدم الضاغط بينما تبقى المفككة على الحالة السابقة. وقد لا يظهر الاختلاف إلا عند وصول الحزمة المضغوطة التالية. وعلى رابط ذي تأخير طويل، يتطلب طلب إصلاح السياق زمناً لا يقل عن رحلة ذهاب وإياب، وقد تُسقط حزم أخرى أثناء الانتظار.

أجاب RFC 3545 بالتكرار مع حد معلن. يمثّل N خصائص الفقد في الرابط، على أساس أن احتمال فقد أكثر من N حزم متجاورة صغير. فإذا ظهر التحديث في N+1 حزمة متتالية، ينبغي أن تصل نسخة واحدة على الأقل إذا لم يتجاوز الاندفاع N. ويمكن للمفككة استخدام خوارزمية «twice» لإعادة بناء فجوة محدودة، ثم فحص النتيجة باستخدام checksum لـUDP أو HDRCKSUM عند انطباقه. يزيد البروتوكول تحمل الفقد؛ لكنه لا يضمن أن يطابق كل اندفاع نموذج الرابط.

رقم تسلسل الرابط مكوّن من أربعة بتات ويلتف كل 16 حزمة. لذلك لا يكفي الفرق المرصود دائماً للتمييز بين فقد حزم كثيرة ووصول حزمة لاحقة قبل الأسبق بسبب إعادة الترتيب. وإذا احتمل تفسير معقول فقد أقل من N+1، يمكن للمفككة تجربة إعادة البناء المقابلة والتحقق منها. أما إذا تجاوز الفقد المحتمل N في IPv4، فالقاعدة أوضح: لا تواصل التخمين بخوارزمية «twice»، بل أبطِل السياق وأرسل CONTEXT_STATE كي يعيد الضاغط الحالة المشتركة.

هنا تهم تغطية checksum. يمكن استخدام HDRCKSUM حين تكون قيمة checksum الأصلية لـUDP في IPv4 صفراً؛ يدرجه الضاغط للفحص ثم تزيله المفككة. ولا يستخدم في IPv6 لأن checksum صفرياً لـUDP غير مسموح به هناك. ومع ذلك لا يتحقق checksum الرأس من Identification في IPv4. وبعد فقد أكثر من N حزم لا يسد اجتياز الفحص هذا النقص؛ بل يوجه RFC 3545 إلى إبطال السياق غير المؤكد. أما IPv6، الذي لا يحتوي حقل IPv4 ID، فله قاعدة استعادة مختلفة.

ولدفعة التحديث حماية أخرى لهويتها. إذا تغير حقل ثابت في السياق أثناء إرسال N+1 حزمة FULL_HEADER، يبدأ الضاغط دفعة جديدة ويغير رقم الجيل. وإلا فقد تخلط المفككة بين دفعتين متداخلتين وبين هامش أكبر للفقد، ولا تلاحظ عدم التزامن. وينبغي تكرار رسائل CONTEXT_STATE أيضاً. هذه آليات بروتوكولية، وليست دليلاً على أن جهازاً بعينه فعّل الامتداد أو أن تطبيق RTP شغّل الحمولة.

النقطة التاريخية محدودة لكنها مهمة للتشغيل: لا يثبت checksum إلا الحقول التي يغطيها؛ وإعادة البناء ضمن حد ليست تسليماً؛ وإصلاح السياق ليس إقراراً باستلام الوسائط. قد ينجح الفحص المحلي ويبقى IPv4 ID بلا تحقق. وعندما يتجاوز نمط الفقد الحد المفترض، لا يكون إبطال السياق تخلياً عن الاستعادة، بل رفضاً لتحويل تسلسل ملتبس إلى يقين زائف.

المصادر