الخلاصة

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

الرقم كان يحكم الاتجاه المعاكس

عرّف RFC 793 Maximum Segment Size بوصفه خيار TCP من النوع 2 وطول 4. تحمل خانته ذات الستة عشر بتاً أكبر مقطع استقبال لدى TCP الذي أرسل المقطع الحامل لـSYN. وجود الرقم داخل المصافحة جعله يبدو كعرض تفاوضي، لكن اتجاهه يكشف وظيفته.

قيمة 1460 التي يرسلها العميل تحد ما يرسله الخادم إلى العميل. وقيمة 1200 التي يرسلها الخادم تحد ما يرسله العميل إلى الخادم. اختلاف الواجهات والذاكرة والسياسات يجعل الرقمين المختلفين صحيحين في الوقت نفسه.

سمّى RFC 879 العملية سنة 1983 إعلاناً، وقال إنها تسمى تفاوضاً على نحو خاطئ في كثير من الأحيان. فالتفاوض ينتج عادة اختياراً مشتركاً. أما هنا فلا يقارن TCP الرقمين ولا ينتخب أحدهما؛ كل مستقبل يتكلم عن قدرته وحدها.

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

من أين جاءت 536؟

كان خط الأساس التاريخي لـIPv4 رزمة بطول 576 ثمانية يجب أن يستطيع المضيف استقبالها وإعادة تجميعها. بعد طرح 20 ثمانية لترويسة IPv4 الثابتة و20 لترويسة TCP الثابتة، تبقى 536 ثمانية من بيانات TCP. وأوضح RFC 879 أن MSS يعد البيانات لا الترويسات.

يستهلك SYN وFIN موضعاً في فضاء التسلسل، لكنهما لا يصيران بيانات ضمن MSS. طول الحمولة وتقدم رقم التسلسل حسابان مختلفان.

ألزم RFC 1122 بدعم إرسال الخيار واستقباله. وإذا غاب عند إنشاء الاتصال، يفترض المرسل 536. ويحافظ RFC 9293 الحالي على 536 لـIPv4 ويحدد 1220 لـIPv6: 1280 ناقص 40 لترويسة IPv6 و20 لـTCP.

غياب الخيار ليس إذناً بالحجم غير المحدود؛ إنه يستدعي قيمة افتراضية محافظة. كما أن 536 و1220 ليستا قياساً للمسار الحالي ولا هدفاً لأداء كل اتصال.

إعلان المستقبل لم يكن كافياً للإرسال

يميز RFC 1122 وRFC 9293 بين SendMSS الوارد وMSS الإرسال الفعلي. على المرسل أن يأخذ الحد الأصغر بين قدرة الطرف البعيد على الاستقبال والحجم الذي تسمح طبقة IP بإرساله، ثم يحسب الترويسات الحالية.

قد يقبل المستقبل 9000 ثمانية بينما يعجز نفق وسيط عن حمل الرزمة. وقد يتسع المسار لحجم كبير من دون أن يمنح المرسل حق تجاوز 1200 التي أعلنها المستقبل. قدرة النهاية وسعة المسار دليلان مختلفان.

تدرس Path MTU Discovery كيف يراجع المرسل تقدير المسار برسائل الأخطاء واختبارات التسليم. أما MSS فيضيف حد المستقبل الاتجاهي. يلتقيان في الحساب، ولا يشهد أحدهما بصحة الآخر.

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

من يعرف كلفة الخيارات المتغيرة؟

تتغير أطوال ترويسات IP وTCP من حزمة إلى أخرى. وحسم RFC 6691 السؤال عمن يخصم الخيارات المحتملة.

عند حساب MSS المعلن، يطرح الطرف الترويسات الثابتة فقط من MTU الفعلي. وعند بناء حزمة بعينها، يخفض المرسل بيانات TCP بمقدار خيارات IP وTCP الموجودة فعلاً. فالمستقبل في لحظة SYN لا يعرف التركيبات المستقبلية، ولا يستطيع رقم ثابت تمثيلها كلها.

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

صحح RFC 6691 أيضاً مبدأ مثال قديم في RFC 879 كان يطرح خيار IP Security من الإعلان نفسه. صحح erratum موثق حساب المحاذاة في المثال، لكن القاعدة اللاحقة بينت أن موضع الطرح ذاته خطأ. ويجمع RFC 9293 القاعدة الحالية.

واقترح Erratum 6381 لـRFC 1122 حذف ما عده طرحاً مزدوجاً لخيارات IP، لكنه رُفض. فرّقت ملاحظات المراجع بين مساحة تحجزها IP وخيارات يمررها TCP. حالة التصحيح جزء من الدليل.

الحد الصغير يفرض سياسة أيضاً

يحذر RFC 6691 من أن MSS صغيراً قد يمنع PMTUD من استغلال مسار أكبر. قد يستمر الاتصال، لكن بعدد رزم أكبر وكلفة ترويسات أعلى، بينما تختفي السعة غير المستخدمة.

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

في jumbograms الخاصة بـIPv6 تعامل 65535 كقيمة لا نهائية ويحدد PMTUD الحد الحقيقي. هذا هروب من سعة الحقل، لا شهادة بمسار لا نهائي.

السجل يحفظ القواعد لا المرور

يحتفظ سجل IANA لمعاملات TCP بالنوع 2 والطول 4 باسم Maximum Segment Size ويحيل إلى RFC 9293. يثبت ذلك استمرار اللغة المشتركة، ولا يثبت القيم الحالية أو إعادة الكتابة أو سعة المسار.

حل RFC 9293 محل RFC 793 و879 و6691 ومتطلبات TCP في RFC 1122. وبقي التقسيم: يعلن المستقبل ما يعرفه عن نفسه؛ يجمع المرسل ذلك مع IP؛ ويخصم منشئ الحزمة الكلفة المتغيرة.

MSS حد له صاحب واتجاه. سجل موثوق يحتاج رقمين وحسابين فعليين، لا رقماً واحداً يسمى اتفاقاً.

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

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