الخلاصة
- حصرت RFC 2395 نافذة LZS المنزلقة ذات 2,048 بايت داخل داتاغرام واحد، فأعاد المرسل والمستقبل ضبط التاريخ قبل كل عملية.
- منع التفريغ بقاء مدخلات للرزمة التالية، وفصلت علامة النهاية المجرى المضغوط عن الحشو؛ ولم يكن أي منهما دليلاً على التسليم أو السلامة أو الهوية.
- كان حد التسعين بايت تقريبياً ونسب Calgary Corpus قياسات محدودة، لا ثوابت على السلك ولا وعود أداء.
ذاكرة نافعة قد تتحول إلى سلسلة أعطال
يستبدل LZS السلاسل المتكررة بإزاحة وطول يشيران إلى نافذة حديثة. في مجرى موثوق، تمنح الذاكرة الأطول فرصاً أكثر. أما IP فلا يضمن وصول الداتاغرامات بالترتيب ولا يضمن وصولها كلها.
إذا أشارت الرزمة الثانية إلى قاموس بنته الأولى ثم ضاعت الأولى، تصبح الثانية غير قابلة للفك رغم وصولها كاملة. وقد يمتد الضرر إلى الثالثة. عندها يكون الضغط قد اخترع ضمان ترتيب لم تمنحه الشبكة.
لذلك أوجبت RFC 2395 إعادة ضبط تاريخ الضغط قبل كل payload، وإعادة ضبط تاريخ فك الضغط قبل كل رزمة مضغوطة. يستطيع القاموس الاستفادة من التكرار داخل الرزمة فقط. الخسارة تبقى خسارة رزمة واحدة، والوصول خارج الترتيب لا يشق القاموس إلى نسختين.
هذا يضحي بتكرار بين الرزم، خصوصاً في الرسائل القصيرة. لكنه يشتري نطاق فشل واضحاً. وتبين RFC 1967 وRFC 1974 أن ملفات PPP التي تستخدم عائلة LZS قد تدير تواريخ وتسلسلات وإعادة مزامنة. اسم الخوارزمية وحده لا يحدد عمر الحالة.
التفريغ أغلق الحاضر ولم يثبت الوصول
قد يحتفظ ضاغط المجرى ببعض الخرج انتظاراً لمدخل لاحق. رفضت RFC هذا الدين: يجب تفريغ الضاغط عند إرسال كل داتاغرام مضغوط، بحيث يظهر كل ما دخل في خرج الرزمة نفسها.
لكن هذا إيصال داخل المشفر، لا إيصال عبر الشبكة. لا يثبت التفريغ أن الرزمة وصلت، أو أن المستقبل قبلها، أو أن فكها نجح، أو أن التطبيق أنجز عملاً.
وينتهي مجرى LZS بعلامة محددة. لأن الشفرة قد تتوقف وسط ثمانية بتات، يمكن أن يليها حشو. تخبر العلامة المفكك أين تنتهي التعليمات. إنها حد نحوي وليست تجزئة أو توقيعاً أو توثيقاً. يمكن لمجرى ضار أن تكون نهايته صحيحة أيضاً.
الاتفاق على LZS لا يفرض ضغط كل رزمة
عرّفت RFC 2395 الرمز IPCOMP_LZS للتفاوض عبر ISAKMP وللتهيئة اليدوية. يحدد الاتفاق طريقة الفك، لكنه لا يلغي قرار IPComp لكل رزمة. إذا لم يكن payload المضغوط مع الترويسة أصغر من الأصل، ترسل الصورة الأصلية بلا ترويسة IPComp.
أبقت RFC 3173 هذا المبدأ بعد أن حلت محل RFC 2393. لذلك لا يعني غياب البروتوكول 108 فشل التفاوض، ولا يعني حضوره نجاح فك الضغط. الارتباط والاختيار والصيغة والنتيجة حقائق منفصلة.
ولم تتضمن LZS اختباراً تكيفياً لقابلية الضغط. تستطيع التهيئة المحلية تجنب محاولات غير مجدية، لكن ذلك سياسة تنفيذ لا سلوك مشتركاً للخوارزمية.
التسعون بايت كانت نتيجة تجربة مسماة
أشارت تجارب غير رسمية على Calgary Corpus إلى احتمال التمدد تحت نحو 90 بايت. وأظهر الملحق نسبة 1.18 عند 64 بايت و2.14 عند 16,384 بايت. تمنح الرزمة الأطول النافذة الجديدة مادة أكثر قبل المسح التالي، وتوزع الكلفة الثابتة.
لكن ذلك corpus لم يكن بيانات مشفرة ولا صوراً مضغوطة سلفاً ولا كل حركة الإنترنت. عرّفت RFC 2394 ملف DEFLATE بسياق مختلف، وناقشت RFC 3051 لاحقاً كلفة إعادة ضبط قاموس آخر. وحذرت RFC 3819 من قلة فائدة ضغط طبقة أدنى لبيانات مضغوطة أو مشفرة.
إذن 90 إشارة إلى القياس المحلي وليست ثابت بروتوكول.
شرط التبني لم يكن تقنياً فقط
ذكرت RFC 2395 أن Hi/fn كانت تملك براءات LZS وقت النشر ووصفت خيارات ترخيص. أثّر ذلك في قرار التنفيذ من دون تغيير بت واحد. وهو دليل تاريخي عن 1998، لا إثبات لملكية أو صلاحية أو سعر أو توافر اليوم.
بقي العقد المشترك رفيعاً: إعادة ضبط، تفريغ، ترميز، نهاية. أما العتبة والاقتصاد والتبني فقرارات محلية، تختبرها الرزم الفعلية ونتائج التطبيقات.
النسيان كان احتراماً للخدمة الحقيقية
لم تطلب RFC من IP أن يصبح مجرى موثوقاً من أجل الضاغط؛ بل أجبرت ذاكرة الضاغط على احترام وحدة الداتاغرام. من هنا جاءت المرونة.
يجب حفظ إيصالات مستقلة للخوارزمية المتاحة، والارتباط، وإعادة الضبط، واختيار الرزمة، وإغلاق المجرى، واستعادة البايتات، والنتيجة التطبيقية. لا يستطيع واحد منها أن يشهد نيابة عن الآخر.
المصادر
- RFC 2395 — IP Payload Compression Using LZS
- سجل RFC 2395 لدى RFC Editor
- تاريخ RFC 2395 في IETF Datatracker
- تصويبات RFC 2395
- RFC 2393 — IP Payload Compression Protocol
- RFC 3173 — IP Payload Compression Protocol
- RFC 1967 — PPP LZS-DCP Compression Protocol
- RFC 1974 — PPP Stac LZS Compression Protocol
- RFC 2394 — IP Payload Compression Using DEFLATE
- RFC 2407 — Internet IP Security Domain of Interpretation for ISAKMP
- RFC 3051 — IP Payload Compression Using ITU-T V.44 Packet Method
- RFC 3819 — Advice for Internet Subnetwork Designers
- Heng Lu — Running-Code Primacy
- Heng Lu — Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
- Heng Lu — Reality Layers, Symbolic Power, and Clarity
إحاطة الأعضاء
سياق أعمق للملف الشخصي
سجّل الدخول بمستوى العضوية المناسب لفتح الإحاطة الكاملة وملاحظات المصادر.
للدائرة الاستراتيجية فقط
الدائرة الاستراتيجية
مفتوح لجميع القراء. افتح إحاطات الملف الشخصي بعد الانضمام وتسجيل الدخول.
انضم إلى الدائرة الاستراتيجيةلأعضاء تحالف القيادات فقط
تحالف القيادات
لأصحاب الأصول الفكرية المؤهلين وللإدارة؛ سجّل الدخول للوصول إلى إحاطات التحالف.
انضم إلى تحالف القيادات
