الخلاصة

  • يجبر مسبار النافذة الصفرية الطرف المستقبل على إعادة إعلان حالة ربما ضاعت في حزمة ACK بلا بيانات.
  • يحفظ TCP إمكانية استئناف النقل، بينما يبقى قرار التوقف عن الانتظار وتحرير الموارد بيد نظام التشغيل والتطبيق.

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

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

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

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

جاء RFC 1122 سنة 1989 ليجعل القاعدة صريحة: دعم استكشاف النوافذ الصفرية إلزامي. شرح المستند العطل الذي يمنعه هذا السلوك. فحزم ACK التي لا تحمل بيانات لا ينقلها TCP على نحو موثوق بذاتها؛ وإذا ضاع الإقرار الذي يعيد فتح النافذة ولم توجد مجسات، فقد يبقى الاتصال معلقًا إلى الأبد. وأوصى بإرسال المسبار الأول بعد مرور مهلة إعادة إرسال واحدة، ثم زيادة الفاصل بين المجسات اللاحقة أُسّيًا.

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

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

تُعرف الحالة التي يدخلها المرسل هنا عادة باسم persist condition، أو حالة الاستمرار. عاد RFC 6429 إلى هذه المسألة سنة 2011 لأن صبر البروتوكول له كلفة لا يستطيع TCP تقييمها وحده. يستطيع طرف أن يعلن نافذة صفرية ويواصل الإقرار بكل مسبار، فيما تظل بيانات التطبيق عالقة في طابور الإرسال وتبقى معها الذاكرة وحالة الاتصال. وإذا تكرر ذلك عبر عدد كبير من الاتصالات، فقد تُستنزف موارد يحتاج إليها مستخدمون شرعيون.

لم يصنف RFC 6429 كل نافذة صفرية هجومًا، ولم يستبدل آلية المجسات بموعد إغلاق موحد. بل أوضح توزيع المسؤولية. لا ينبغي لـTCP أن يغلق الاتصال لمجرد بقائه في حالة الاستمرار، لكن ذلك لا يمنع نظام التشغيل أو التطبيق من إنهائه واستعادة موارده وفق سياسة عادية. إبقاء حالة البروتوكول قابلة للاستعادة لا يلزم مالك الموارد بتحمل كلفة بلا حدود.

يحافظ RFC 9293، وهو المواصفة الجامعة الحالية لـTCP، على هذه البنية. يظل دعم مجسات النافذة الصفرية إلزاميًا. ويرد المستقبل بنافذته الحالية ورقم التسلسل التالي المتوقع. وينبغي أن يبدأ المرسل بعد فاصل RTO واحد وأن يزيد الفواصل اللاحقة أُسّيًا. كما تبقى اعتبارات إدارة الموارد حاضرة. فالضمان ليس انتظار كل اتصال إلى الأبد، بل إمكان إعادة تعلم حالة النافذة ما دام النظام قد قرر الاحتفاظ بالاتصال.

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