الخلاصة

  • يستطيع أي fragment أن ينشئ سياق reassembly بحسب المصدر والوجهة والبروتوكول وIdentification؛ ليس ضرورياً أن يصل fragment zero أولاً.
  • عند انتهاء timeout يجب التخلص من datagram غير المكتملة. أما ICMP Time Exceeded Code 1 فيصبح واجباً عندما يكون fragment zero قد وصل.
  • لذلك يجمع الصمت أسباباً مختلفة: غياب الجزء الأول، أو منع ICMP، أو ضياعه في طريق العودة، أو اختلاف التنفيذ. ولا يجوز تحويله إلى حكم بالنجاح.

ما الذي كانت الوجهة تعرفه فعلاً؟

تجمع RFC 791 الأجزاء التي تشترك في source وdestination وprotocol وIdentification. يحدد Fragment Offset موضع data. الصفر يعني البداية، وMF بقيمة صفر يعني النهاية. قد تصل النهاية قبل البداية.

إذا وصل جزء في الوسط ولم يوجد buffer مطابق، تُخصص موارد جديدة. توضع bytes في مكانها، وتُسجل الكتل المستلمة. وصول الجزء الأخير يسمح بحساب الطول الكلي. لكن original header يُحفظ في header buffer فقط عندما يكون FO = 0، ولا تُسلم datagram حتى تختفي كل الفجوات من الصفر إلى النهاية.

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

مهلة الانتظار كانت فاتورة ذاكرة

اقترح RFC 791 حداً أولياً قدره 15 ثانية. وكان وصول fragment ذي TTL أكبر يرفع timer إلى القيمة الأكبر. كما ربط النص بوضوح بين data rate وtimer وحجم buffer المطلوب.

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

لهذا طالبت RFC 1122 بمهلة reassembly ثابتة لا تُشتق من TTL المتبقي، وأوصت تاريخياً بـ60 إلى 120 ثانية. هذه توصية معيارية قديمة، وليست قياساً لإعدادات الأنظمة الحالية.

تسجيل الفجوات لا يعيد الجزء الغائب

قدمت RFC 815 طريقة تحفظ holes الباقية. يقلص fragment فجوة أو يقسمها أو يغلقها؛ وحين تختفي القائمة تكتمل datagram. الترتيب لا يهم.

لكن IPv4 options ليست متماثلة بين الأجزاء. بعضها يُنسخ إلى الجميع، وبعضها لا يوجد إلا في الأول. قبل fragment zero قد لا يُعرف الشكل النهائي للـ original header. يمكن للذاكرة أن تترك مساحة أو تنقل data لاحقاً، لكنها لا تستطيع اختراع السياق المفقود.

أضاف RFC 1122 شرطاً دقيقاً: يجب حفظ header الجزء الأول من أجل ICMP محتمل عند timeout. لم يعد هذا header ضرورياً لمسار النجاح فقط؛ صار أيضاً أصلَ الدليل في مسار الفشل.

الرسالة كانت اقتباساً من البداية

عرّفت RFC 792 Time Exceeded Type 11 Code 1. تحمل الرسالة original IP header وأول 64 bit من data كي يربط المصدر الخطأ بالعملية المعنية وفق افتراضات ذلك الزمن.

يحمل fragment اللاحق source address وIP header؛ وإلا تعذر ضمه إلى السياق. لكن data فيه ليست أول data في datagram الأصلية. لذلك قصرت RFC أخطاء ICMP على fragment zero، وقالت إنه إذا لم يكن متاحاً فلا حاجة إلى إرسال Time Exceeded.

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

واجبان، وشرط واحد

صياغة RFC 1122 حاسمة. عندما تنتهي المهلة، يجب حذف datagram الجزئية. ويجب إرسال ICMP Time Exceeded إلى source إذا استُلم fragment zero.

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

RFC 1812 تحدد صاحب هذا الواجب. عندما تعيد router تجميع packet موجهة إليها، تتصرف كـhost وتطبق متطلبات host. المرور العادي لا يجعل كل router في الطريق مالكة لسياق التجميع. كما تمنع RFC خطأ ICMP استجابة لجزء غير أول.

الوقت يحفظ اسماً قديماً أيضاً

يربط RFC 6864 reassembly timeout بالفترة التي يجب أن يبقى فيها Identification غير ملتبس لنفس source وdestination وprotocol. ما دام جزء قديم حياً، يمكن لإعادة استخدام التركيبة أن تخلط أجيالاً.

إطالة timer لا تحتفظ بالـbytes فقط؛ تمدد أيضاً عمر هوية محدودة. هذه نتيجة ثانوية للمهلة، لا إعادة لكتابة تاريخ حقل ID كله.

لماذا يخدعنا العداد الصفري؟

وصول Code 1 يثبت سلسلة محدودة: سياق ناقص عاش حتى expiry، وfragment zero كان موجوداً، ورسالة خرجت ووصلت. لا يحدد أين ضاع الجزء الآخر.

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

أربع مراحل بين الفشل والمشاهدة

المرحلة الأولى هي eligibility: هل وصل fragment zero بحيث تسمح القاعدة برسالة مكتملة المعنى؟ الثانية هي generation داخل host. الثالثة هي الخروج بعد rate limiting والسياسة المحلية. الرابعة هي اجتياز return path والوصول إلى observation عند المصدر. الصفر في المرحلة الرابعة لا يحدد أي مرحلة سابقة كانت صفراً.

لهذا لا يكفي جمع icmp_time_exceeded عند source. يجب مقارنته بعدد contexts التي انتهت، وعدد ما احتوى منها على offset zero، وعدد محاولات الإرسال. فقط عندئذ يمكن فصل صمت متوقع بسبب غياب البداية عن صمت أحدثه filter أو ضغط على control plane.

وصول final fragment لا يحل المسألة. فهو يحدد نهاية data المقصودة، لكنه لا يقدم original beginning. إذا وصل zero وfinal معاً، تستطيع الوجهة تحديد holes داخلية؛ ومع ذلك لا تستطيع الرسالة وحدها تحديد أين ضاعت هذه intervals أو من المسؤول عنها.

ولا يحمل Code 1 قيمة MTU أو اسم link ضيق. أشارت RFC 1122 إلى احتمال أن يفيد مستقبلاً إجراء اكتشاف ما، لكن ذلك لا يجعل الإشارة بمفردها تشخيصاً للـMTU. يلزم packet sent وسياق path وتجارب متكررة قبل الانتقال من expiry إلى سبب.

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

كما ينبغي فصل وصول final fragment عن وصول البداية. الأول يرسم الحد النهائي للـdata ويجعل holes قابلة للقياس، والثاني يوفر original context. جمعهما في حالة واحدة مثل «شبه مكتمل» يمحو الفارق الذي يقرر إمكان الرسالة.

ولا يعني ذلك حفظ كل payload. يكفي في كثير من التحقيقات الاحتفاظ مؤقتاً بالـtuple والـoffsets والعمر وzero flag وسبب الإغلاق. الهدف هو إثبات حالة القرار، لا إنشاء نسخة أخرى من المحتوى.

المصادر وحدودها

تثبت هذه الوثائق القواعد والخوارزميات والمفاضلات المكتوبة. ولا تقيس defaults الحالية أو معدل fragmentation أو وصول ICMP أو filters أو امتثال المنتجات.