العرض الذي لم يكن تفاوضًا: كيف حدّد MSS في TCP كل اتجاه

الخلاصة

• خيار MSS من النوع 2 وطوله 4، ويُرسل في SYN ليحدد أكبر كمية من بيانات TCP يستطيع مرسل الخيار استقبالها في مقطع واحد.
• لكل اتجاه حد مستقل. تستبعد القيمة رؤوس IP وTCP؛ وعلى المرسل أن يراعي الرؤوس الفعلية وقيود المسار عند بناء الحزمة.

رسالتا SYN وحدّا استقبال

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

الصيغة محددة: Kind 2، وLength 4، ثم قيمة MSS من 16 بت. يضع RFC 9293 خيار MSS ضمن مجموعة الخيارات التي يجب على تنفيذ TCP دعمها، ويعرّف القيمة بأنها أقصى حجم مقطع مستعد المرسل لاستقباله. ويمكن أن تظهر في طلب الاتصال الأول ذي الراية SYN، ولا ينبغي أن تظهر في المقاطع اللاحقة. إنها قيد يُثبت عند فتح الاتصال، وليست تقريرًا مستمرًا عن السعة.

تحسب MSS ثمانيات بيانات TCP وتستبعد رؤوس IP وTCP. وليست حجم رزمة IP أو MTU واجهة أو حجم عملية كتابة التطبيق. يستخدم المرسل إعلان الطرف الآخر مع معلوماته عن المسار والرؤوس التي سيضعها فعليًا.

أوضح RFC 879 منذ عام 1983 أن تسمية MSS بالتفاوض شائعة لكنها خاطئة. المستقبل يعلن ما يستطيع قبوله، والمرسل يقرر كيفية بناء الحزمة.

لماذا كان 536 قيمة افتراضية

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

كان ذلك حساب توافق، لا قياسًا للمسار. ولم يثبت أن MTU كل مسار تساوي 576 أو أن تقنية وصل معينة تفرض رقمًا عالميًا.

كما أن MSS ليست اكتشافًا لـMTU المسار. تحاول PMTUD معرفة خاصية في الطريق قد تتغير، بينما تُتبادل MSS عند فتح الاتصال وتصف قدرة طرف نهائي على الاستقبال.

التصحيح المتعلق بالخيارات

كانت بعض التطبيقات تخفض MSS المعلنة لحجز مساحة لترويسات IP أو TCP قد تظهر لاحقًا. صحح RFC 6691 هذه الممارسة: على المستقبل إعلان أكبر حمولة TCP يستطيع إعادة تجميعها، من دون خصم مساحة افتراضية للترويسات.

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

ما الذي يمكن لوسيط تغييره

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

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

الدرس التاريخي هو فصل الصلاحيات: المستقبل يعلن حده، والمرسل يبني الحزمة، والمسار يظل قيدًا خارجيًا.

المصادر

• RFC 879 — The TCP Maximum Segment Size and Related Topics
• RFC 6691 — TCP Options and Maximum Segment Size
• RFC 9293 — Transmission Control Protocol