الخلاصة

  • يسأل TCP keepalive إن كان الطرف الصامت يرد على طبقة النقل؛ لكنه لا يثبت سلامة التطبيق البعيد.
  • ظل اختياريًا وقابلًا للضبط ومعطلًا افتراضيًا لأن صمت الاتصال يحتمل أسبابًا مختلفة.
  • لا يثبت رد مفقود موت الاتصال، كما تمنع ذاكرة الوسطاء ومهلة المستخدم والطاقة اعتماد فاصل عالمي آمن.

الموثوقية لا تراقب شيئًا لم يُرسل

حدد RFC 793 مسؤولية واضحة لـTCP عندما توجد بيانات: تحتل البايتات مواقع في فضاء التسلسل، وتدفع الإقرارات الإرسال إلى الأمام، ويؤدي الفقد إلى إعادة الإرسال. وفي النهاية ينجح التسليم، أو يصل reset، أو تبلغ النقطة سياسة التخلي المحلية.

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

ليست هذه ثغرة في التسليم الموثوق، بل حدّ لما يمكن استنتاجه من تسليم لم يحاول أحد القيام به.

سؤال من خلف حافة التسلسل

سجل RFC 1122 في 1989 أن keepalive آلية خلافية واختيارية. تضع النبضة المعتادة SEG.SEQ = SND.NXT-1، أي عند الموقع السابق مباشرةً للبايت الجديد التالي الممكن إرساله.

هذا الموضع الغريب مقصود. لا ينبغي للمقطع أن يتقدم كبيانات تطبيق جديدة، لكنه يستدعي من TCP البعيد الذي ما زال يحتفظ بالحالة ACK يبيّن ما ينتظره تاليًا. لا تحمل النبضة عادةً بيانات ولا تحرك المجرى. وبقي شكل يحمل بايت «قمامة» قابلًا للضبط فقط للتوافق مع تطبيقات قديمة خاطئة.

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

الاختيارية جزء من نموذج الأمان

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

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

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

سؤال واحد بلا جواب لا يثبت شيئًا

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

الإغلاق فعل وليس ملاحظة. عندما يمحو TCP المحلي الحالة ويعلن الفشل، قد يهجر التطبيق معاملة، أو يحرر قفلًا، أو ينتخب بديلًا، أو يفتح اتصالًا آخر. وقد تعيش نتائج استنتاج سببه فقد عابر أطول من الفقد نفسه.

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

مهلة المستخدم تسأل سؤالًا آخر

احتوى TCP أصلًا على مفهوم user timeout للبيانات المرسلة غير المقرّ بها. ثم عرّف RFC 5482 خيارًا لإبلاغ تفضيل المهلة. سؤاله هو: كم يمكن أن تبقى البيانات المرسلة بلا إقرار؟ وليس: منذ متى لم يتكلم طرف خامل؟

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

اكتسب الوسيط ذاكرة تنتهي صلاحيتها

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

حوّل RFC 5382 افتراض الساعتين إلى حد توافق. فإذا عجز NAT عن تحديد نشاط طرفي اتصال قائم، فلا ينبغي له حذف التعيين قبل ساعتين وأربع دقائق؛ وتسمح الدقائق الإضافية بالحزم التي ما زالت في الطريق.

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

البطارية تعرض الكلفة المعاكسة

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

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

نبض يسمع النواة ولا يسمع التطبيق

قد توحي تسمية keepalive بالنبض بقدرة أوسع مما تملك. تستطيع النواة إرسال ACK بينما عملية الخدمة عالقة. وقد يرد proxy على TCP في حين يفشل النظام خلفه. وقد يكون التطبيق سليمًا لكنه معلّق عمدًا.

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

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

بقي للصمت افتراض البراءة

لم يكن القرار التصميمي الباقي مجرد حيلة SND.NXT-1، بل رفض جعل طبقة النقل تدين الصمت افتراضيًا.

يثبت ACK واصل استجابة TCP حديثة، لا سلامة التطبيق. ويعني ACK الغائب غموضًا، لا موتًا. وقد تبرر سلسلة غياب مضبوطة الإغلاق المحلي لأن التطبيق اختار ميزانية مخاطرة، لا لأن الإنترنت قدم يقينًا.

ظل keepalive اختياريًا لأن من يتحمل نتيجة الخطأ يجب أن يحتفظ بالقرار. قدم TCP طريقة للسؤال، ولم يدّع سلطة معرفة سبب عدم الإجابة.

المصادر وحدود الدليل

يؤسس RFC 793 الاتصال ومهلة المستخدم الأصليين؛ ويسجل RFC 1122 عقد keepalive في 1989؛ ويحدد RFC 5382 أوقات NAT؛ ويفصل RFC 5482 مهلة المستخدم؛ ويوثق RFC 9006 مقايضة الطاقة؛ ويجمع RFC 9293 القواعد الحالية. ولا تثبت هذه المصادر افتراض كل منصة أو عمر كل وسيط أو معنى سلامة كل تطبيق.