المضيف الذي كان عليه أن ينتظر قبل أن يتكلم: زمن صمت TCP بعد إعادة التشغيل

الخلاصة

• ينطبق الصمت عند فقدان ذاكرة أرقام التسلسل، وليس بعد كل إعادة تشغيل.
• فرضت RFC 793 صمتًا بمقدار MSL واحد كي تغادر التكرارات القديمة الشبكة.
• أبقت RFC 9293 على الحماية، لكنها ترى أن الشروط الخطرة نادرًا ما تجتمع اليوم.
• الاحتفاظ بالحالة وPAWS وسيلتان مختلفتان للدفاع.

عندما ينسى المضيف ولا تنسى الشبكة

قد يمحو العطل حالة TCP المتطايرة بينما تبقى المقاطع المرسلة في الطوابير أو المسارات أو المستقبلات. وإذا أعيد استخدام العناوين والمنافذ نفسها، فقد يبدو مقطع قديم كأنه بيانات جديدة. فالبيانات وSYN وFIN تشغل مساحة تسلسل محدودة يمكن أن تتداخل مع اتصال لاحق.

الصمت بديلًا عن الذاكرة

طلبت RFC 793 من TCP الذي فقد أرقام التسلسل المستخدمة في الاتصالات النشطة ألا يرسل طوال المدة القصوى لبقاء المقطع في الشبكة (MSL). وكانت دقيقتان اختيارًا هندسيًا، لا قياسًا عالميًا. لا يقيس الانتظار زمن الذهاب والإياب ولا يضبط إعادة الإرسال؛ بل يمنح المقاطع القديمة وقتًا لمغادرة الشبكة.

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

ما الذي أبقته المواصفة الحالية

تحتفظ RFC 9293 بوجوب الانتظار مدة MSL واحدة على الأقل بعد فقدان ذاكرة التسلسل. لكنها تشرح أيضًا أن الخطر غالبًا مهمل عمليًا: إذ يجري اختيار أرقام التسلسل الابتدائية والمنافذ المؤقتة عشوائيًا، وتراجعت مدة MSL الفعلية مع زيادة سرعة الشبكات، وغالبًا ما تستغرق إعادة التشغيل أكثر من مدة MSL.

لا يعني ذلك إلغاء المنطق الوقائي. فالعشوائية تقلل احتمال التصادم لكنها ليست ذاكرة للتاريخ. وعند السرعات العالية توفر طوابع TCP الزمنية وPAWS دفاعًا مختلفًا، يراه المستقبل، ضد التكرارات القديمة عندما تدور مساحة 32 بت سريعًا.

المصادر

• RFC 793 — Transmission Control Protocol
• RFC 9293 — Transmission Control Protocol