الملخص

  • يطلب مسبار TCP Keep-Alive من النظير الخامل الرد اعتمادًا على حالة التسلسل الموجودة؛ ولا يقيس صحة التطبيق العامة.
  • لا ينقل TCP المقاطع التي تحتوي على ACK فقط بصورة موثوقة، ولذلك لا يثبت غياب الرد على مسبار واحد تعطل الاتصال.

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

لا تحل هذه الآلية محل إعادة الإرسال. فما دامت هناك بيانات مرسلة لم يصل إقرارها، يستخدم TCP بالفعل إعادة الإرسال وUser Timeout لتقرير إمكان استمرار التسليم. ولا يبدأ Keep-Alive إلا بعد أن يصبح الاتصال خاملًا من الجوانب الأخرى.

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

دعم Keep-Alive اختياري. وإذا نُفذ، فيجب أن يستطيع التطبيق تفعيله أو تعطيله لكل اتصال، وأن يكون معطلًا افتراضيًا. ولا يجوز إرسال المسبار إلا عند عدم وجود بيانات مرسلة معلقة، وعدم وصول بيانات أو إقرارات خلال الفترة المحددة. ويجب أن تكون الفترة قابلة للتهيئة، وألا يقل الإعداد الافتراضي المعياري عن ساعتين.

تحافظ RFC 9293 على القيد الأساسي في RFC 1122: لا ينقل TCP المقاطع التي تحتوي على ACK فقط بصورة موثوقة. قد يستقبل النظير المسبار وينشئ الإقرار المتوقع، ثم يضيع الإقرار في الطريق. لذلك لا يمثل عدم الرد على مسبار معين، بمفرده، دليلًا على تعطل الاتصال. كما أن توحيد القواعد لم يحول الآلية إلى خدمة عامة لإثبات التوافر.

المصادر