الخلاصة

  • سمح IPv4 في بدايته للبوابة بتجزئة مخطط بيانات أكبر من الوصلة التالية، ثم أعاد الطرف المستقبل تجميع الأجزاء. أخفى ذلك اختلاف الشبكات، لكن ضياع جزء واحد كان يعطل الأصل كله.
  • جعل PMTUD التقليدي المصدر يضع DF ويصغّر الرزم بعد وصول ICMP يقول إن التجزئة مطلوبة. وإذا اختفت الرسالة، نجحت الرزم الصغيرة وسقطت الكبيرة في ثقب أسود.
  • أتاح PLPMTUD لطبقة تشكيل الرزم أن تبدأ بحجم عامل وتختبر أحجاماً أكبر قابلة للتأكيد. يقدم المسار دليلاً محدوداً، بينما يحتفظ المرسل بالتقدير والتحقق وحق المراجعة.

رزمة لا تسعها الشبكة التالية

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

أتاحت حقول Identification وFragment Offset وMore Fragments للوجهة إعادة الأجزاء إلى مواضعها. لم تعد الطبقات العليا مضطرة إلى معرفة كل وسيط. لكن الكلفة بقيت: رزم أكثر عند موضع الاختناق، وعمل إضافي في الموجّه، وحالة لإعادة التجميع، وفشل الكل إن غاب جزء.

وفر Don't Fragment اختياراً آخر. يجب إسقاط الرزمة ذات DF إذا لم تمر كاملة. بذلك يستطيع المصدر رفض التجزئة الوسيطة، لكنه لا يتكيف ما لم يعرف أن الحجم هو سبب الفقد، لا الازدحام أو عطل آخر.

MTU المسار هو أصغر MTU بين وصلات الطريق الحالي. ليس صفة دائمة للوجهة. تغيير التوجيه، أو إضافة ترويسات نفق، أو المرور بفرع آخر متعدد المسارات يغيّر الحد المتاح.

خيار يحتاج إلى قلم كل بوابة

اقترح RFC 1063 في يوليو 1988 أن يكتب الطريق حده الأدنى داخل الرزمة. يبدأ Probe MTU بقيمة الوصلة الأولى، وتقارن كل بوابة القيمة بواجهتي الدخول والخروج وتخفضها، ثم يعيد Reply MTU النتيجة إلى المصدر.

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

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

لا يتكلم إلا الرابط الذي يرفض

خفف RFC 1191، الصادر في نوفمبر 1990، العبء على قلب الشبكة. يبدأ المصدر بحد القفزة الأولى ويرسل مع DF. الموجّه الذي لا يستطيع تمرير الرزمة كاملة يسقطها ويرسل ICMP Destination Unreachable برمز «التجزئة مطلوبة وDF مضبوط». يخفض المصدر تقديره.

حمل حقل ICMP كان غير مستخدم MTU القفزة التالية التي سببت الرفض. لم يعد الموجّه يعدل كل رزمة، بل يقدم دليلاً عند الفشل فقط. واستمرار DF يكشف طريقاً يصبح أضيق لاحقاً.

كانت الموجّهات القديمة تعيد صفراً في الحقل الجديد. عندئذ يبحث المضيف نزولاً عبر «مصاطب» MTU المحتملة. كان النقص ببضعة في المئة أفضل من الزيادة ببايت واحد. ولم تكن القائمة سجلاً أبدياً، بل نصيحة تنفيذية لزمنها.

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

المصافحة تمر والبيانات تختفي

يعتمد PMTUD التقليدي على عودة ICMP. وثّق RFC 2923 عام 2000 الثقب الأسود الناتج عندما لا ينشئ الموجّه الرسالة أو يحجب الجدار الناري ICMP كله. يكرر المرسل الرزمة الكبيرة ذات DF من دون أن يتعلم تصغيرها.

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

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

يصف RFC 8201، وهو مواصفة IPv6 الحالية، المصافحة الناجحة نفسها التي يليها توقف عند حجب Packet Too Big. لا تجزّئ موجّهات IPv6 الرزم العابرة؛ المصدر هو الذي يختار الحجم ويصنع الأجزاء عند الحاجة.

إثبات النجاح من الطرف

لم ينتظر RFC 4821 عام 2007 تفسير الفشل وحده. يبدأ Packetization Layer PMTUD بحجم ينجح ويرسل مجسات أكبر تدريجياً. يرفع الوصول المؤكد الحد الأدنى، ويخفض الفشل الحاسم لمسبار منفرد الحد الأعلى.

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

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

يستفيد PLPMTUD من ICMP أو يعمل من دونه. لا يلغي معرفة الموجّه، بل يمنع قناة رد واحدة غائبة من امتلاك حق إيقاف الاتصال إلى الأبد. في المقابل يتحمل الطرف تأكيد التسليم والبحث وحساب الترويسات والتنسيق مع الازدحام.

مخططات البيانات تحتاج إلى تأكيدها الخاص

لم يلغ IPv6 الاكتشاف. البقاء عند الحد الأدنى يضيّع كفاءة الطرق الأوسع، والإرسال فوقه يحتاج إلى تحمل غياب PTB.

عرّف RFC 8899 عام 2020 DPLPMTUD لنواقل وتطبيقات مخططات البيانات، ومنها بروتوكولات فوق UDP وSCTP وQUIC. إذا لم يوفر الناقل تأكيداً، فعلى التطبيق أن يوفر وسيلة لمعرفة وصول المسبار.

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

لم تكن الحركة التاريخية طرداً مفاجئاً لوظائف القلب. أخفت التجزئة التنوع وضخمت ثمن الفقد. جمع خيار 1988 علماً محلياً دقيقاً وطلب الجميع. تكلم ICMP عند الفشل فقط لكنه اعتمد على طريق العودة. أضاف مسبار الطرف واقع التسليم وحدّ ذلك الاعتماد.

الحجم قرار له مدة صلاحية

من السهل اختزال MTU في 1500 أو 1280. أما الدرس فهو سطح التحكم: يحدد المشغل الحد المحلي، وينفذه الموجّه وقد يبلغ عنه، ويمكن للجدار الناري محو البلاغ، ويحتفظ المضيف بحالة الطريق، ويشكل الناقل الرزمة التالية. لا أحد يملك المسار كله.

ينبغي أن تظل القاعدة المشتركة ضيقة: إظهار القيد حيث يمكن، وترك المصدر يقارن الرسالة بالتسليم والازدحام، وإنهاء صلاحية النتيجة. لم تصبح الرزمة ذكية؛ وضعت البنية القرار حيث يمكن رؤية الدليل والنتيجة معاً.

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

يوثق RFC 791 تجزئة IPv4 وDF؛ ويعرض RFC 1063 خيارات البوابات؛ ويحدد RFC 1191 PMTUD التقليدي وMTU القفزة التالية والمصاطب وشيخوخة الحالة. يصف RFC 2923 ثقب TCP الأسود. ويقدم RFC 4821 مجسات طبقة التشكيل، وRFC 8201 نموذج IPv6، وRFC 8899 مخططات البيانات.

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