الخلاصة

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

الانتظار ذاكرة لا فراغ

بعد الإغلاق النشط، تحتفظ TCP عادةً بكتلة التحكم مدة 2×MSL. تمنح هذه المدة التكرارات القديمة وقتاً كي تختفي قبل إعادة استخدام العناوين والمنافذ نفسها. TIME-WAIT ليست مؤقت إعادة إرسال ولا مهلة لتسليم التطبيق؛ إنها حد فاصل بين تاريخي اتصال.

كيف تحدث السلسلة

في مثال RFC 1337 تكون A في TIME-WAIT، بينما عادت B إلى CLOSED. يصل إلى A مقطع بيانات أو ACK قديم غير مقبول، فترد A بـACK يحمل توقعاتها الحالية. لا تملك B اتصالاً مطابقاً، ولذلك ترد على ذلك الـACK بـRST. تعالج A الـRST وتحذف كتلة التحكم، فتغادر TIME-WAIT قبل الموعد.

قد تبدو كل استجابة سليمة محلياً، لكن تركيبها يهدم الغرض من الحالة. الـRST هو الذي يمحو الذاكرة؛ أما الخطر اللاحق فقد ينتج عن تكرار قديم آخر ظل في الشبكة.

الفرق بين الإصلاح وإثبات الأمان

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

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

المصادر