الخلاصة

  • تمثل TIME-WAIT حداً زمنياً لحماية سلامة الاتصال؛ فبعد الإغلاق النشط يوجب RFC 9293 الاحتفاظ بالحالة لمدة تساوي ضعفي العمر الأقصى للمقطع، كي تزول رزم الاتصال السابق قبل أن تختلط بالاتصال اللاحق.
  • في السلسلة التي وصفها RFC 1337، يستدعي مقطع قديم غير مقبول رسالة ACK، فيجيب الطرف الذي أغلق اتصاله برسالة RST؛ وإذا قُبلت إعادة الضبط هذه حُذفت TIME-WAIT قبل انقضاء مدة العزل.

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

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

تحافظ TIME-WAIT على الفصل بين التاريخين. فالطرف الذي ينفذ الإغلاق النشط لا يتخلص من كتلة تحكم الإرسال فور اكتمال التبادل الأخير. ويجعل RFC 9293 تكلفة ذلك صريحة: يجب أن يبقى الطرف في TIME-WAIT مدة 2xMSL، أي ضعفي العمر الأقصى للمقطع. ليست هذه مهلة لتنظيف مؤجل، بل فترة تسمح للنسخ القديمة بأن تموت قبل أن تكتسب رباعية الاتصال نفسها معنى جديداً.

تنطلق ملاحظة RFC 1337 المقلقة من أن السلوك الطبيعي الذي يستخدمه TCP للتعامل مع حركة قديمة كان قادراً على هدم هذا العزل نفسه.

استجابة صحيحة تصنع إعادة الضبط الخطأ

تبدأ السلسلة عندما يصل مقطع بيانات أو ACK قديم إلى الطرف A وهو ما يزال في TIME-WAIT. لا يمكن قبول المقطع، ربما لأن رقم تسلسله أو ختمه الزمني يعود إلى جيل آخر. فيرسل A رسالة ACK تحمل القيمتين الحاليتين SND.NXT وRCV.NXT.

أما الطرف B فقد حذف حالة الاتصال. وعندما يتلقى ACK لا يقابله اتصال معروف، يرد برسالة RST. فإذا عامل A رسالة إعادة الضبط سبباً لمغادرة TIME-WAIT، حذف بالضبط الحالة التي كان ينبغي أن تعيش أطول من الرزم القديمة. لم يأمر المقطع القديم A بالإغلاق مباشرة؛ بل جعله يتكلم، ثم دفعت إجابة A الدقيقة طرفاً بلا حالة إلى إصدار إشارة التحكم المدمرة، وأنهت تلك الإشارة الانتظار. سمّى RFC 1337 هذه السلسلة TIME-WAIT Assassination.

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

تذكر المذكرة ثلاث نتائج. في H1 تُقبل بيانات من الاتصال السابق بالخطأ. وفي H2 يفقد الطرفان التزامن؛ ووفق السلوك المحدد آنذاك قد يقر كل طرف بحالة لم يرسلها الآخر، فتستمر حلقة ACK بلا نهاية. وفي H3 يقتل مقطع قديم الاتصال الجديد أثناء الفتح، حتى بعد أن يبدو أن الإنشاء نجح.

توضح هذه الشروط الإضافية لماذا اعتبر RFC 1337 الأخطار H1 وH2 وH3 أقل احتمالاً من واقعة الاغتيال نفسها. فلا يكفي حذف TIME-WAIT مبكراً؛ بل يلزم أيضاً تكرار استخدام الهوية بسرعة، وتداخل مساحتي التسلسل، ووصول النسخة القديمة المناسبة في المجال المناسب. أعادت الوثيقة إنتاج الظواهر الأربع على حزمة TCP في SunOS 4.1.1، لكن ضمن بيئة محاكاة تضاعف المقاطع بكثافة وضُبطت خصيصاً لتوليد المصادفات المطلوبة. إنها برهان على الإمكان، لا تقدير لانتشار معاصر ولا حكماً على منتج حالي بعينه.

ثلاثة علاجات لا توفر الحماية نفسها

الاقتراح الأول في RFC 1337 هو الأبسط: تجاهل رسائل RST أثناء TIME-WAIT. فإذا طُبقت قيمة MSL البالغة دقيقتين التي تفترضها المذكرة، تقول الوثيقة إن هذا الخيار يمنع H1 وH2 وH3. وينبع المنطق من وظيفة الحالة؛ فإذا كان الانتظار موجوداً للسماح بزوال حركة قديمة غير موثقة، فلا ينبغي لتلك الحركة نفسها أن تملك سلطة تقصير المدة.

لكن التوصية تحتفظ بحد مهم. فـRFC 1337 وثيقة Informational، وتطلب اختبار التغيير مدة طويلة في بيئة إنتاجية لكشف أي أثر غير متوقع. وهي لا تثبت أن جميع التطبيقات تبنت القاعدة، ولا أن تجاهل إعادة الضبط في هذه الحالة خالٍ من الكلفة في كل بنية.

يستخدم الاقتراح الثاني أختام TCP الزمنية وآلية PAWS. فإذا صمدت TIME-WAIT حتى تتقدم الساعات، أمكن لـSYN في الاتصال الجديد أن يحمل ختماً أحدث من المقاطع القديمة، وبذلك تُمنع بيانات H1. لكن العلاج جزئي. فقد يستدعي ACK قديم يصل أثناء TIME-WAIT رسالة ACK جديدة تحمل ختماً زمنياً حالياً؛ ويمكن لهذه «النسخة القديمة المجددة» أن تتجاوز PAWS في الاتصال التالي، ولذلك لا يختفي H2 وH3 بالضرورة.

أما الاقتراح الثالث فيوسع أرقام التسلسل إلى 64 بت. تجعل المساحة الأكبر إعادة استخدام المجال نفسه أبطأ بكثير، لكنها لا تمنع RST من حذف TIME-WAIT. لذا يعرض RFC 1337 الفكرة كتغيير كبير في البروتوكول قد يمنع الأخطار اللاحقة إذا اقترن بتعديلات أخرى للمعلمات، لا كإصلاح مستقل للاغتيال.

المواصفة الأساسية الحالية تُبقي التوتر قائماً

يواصل RFC 9293، وهو معيار الإنترنت الأساسي الحالي لـTCP، إلزام الطرف الذي يغلق بنشاط بالبقاء في TIME-WAIT مدة 2xMSL. ويسمح بقبول SYN جديد من الطرف نفسه مباشرة من هذه الحالة، ولكن بشرط أن يكون ISN الجديد أكبر من أكبر رقم استُخدم في الجيل السابق، وأن يعود الطرف إلى TIME-WAIT إذا اتضح أن SYN نسخة قديمة. كما يشير إلى خوارزمية محسنة تعتمد الأختام الزمنية للخوادم ذات معدلات إنشاء الاتصال المرتفعة.

مع ذلك تحتفظ آلة الحالات الأساسية بالمخرج الذي يجعل المشكلة قائمة. فبعد اختبارات القبول، تؤدي معالجة RST في TIME-WAIT إلى CLOSED وحذف كتلة التحكم. وعلى النقيض، يُقر FIN معاد الإرسال من الطرف البعيد ويُعاد تشغيل مؤقت 2xMSL. وهكذا يمكن لإشارتين تحكميتين تصلان إلى الحالة نفسها أن تنهِيا الحد أو تمدداه عبر مسارين مختلفين.

لذلك لا تكفي عبارة «تقليل TIME-WAIT» لوصف قرار هندسي، لأنها لا تقول ما الدليل الذي سيحل محل الزمن في الفصل بين جيلي الاتصال. كما لا تكفي عبارة «الاحتفاظ بمزيد من الحالة»، لأنها لا توضح هل تقاوم تلك الحالة الإشارات القادرة على حذفها. السؤال المعماري الحقيقي هو: ما الدليل القوي بما يكفي لإنهاء عزل صُمم أصلاً ليعيش أطول من حركة قديمة غير موثقة؟

المصدران الوحيدان لهذه الحزمة هما RFC 1337، المنشور بصفة Informational في مايو 1992، وRFC 9293، معيار الإنترنت المنشور في أغسطس 2022. يصفان الآلية وشروطها وقواعد TCP الأساسية، ولا يوثقان معدل الحدوث الحالي أو سلوك منتج مسمى.