مهلة مستخدم TCP في RFC 5482: كشف انقطاع الاتصال واستقرار أنفاق VPN

عندما تنقطع واجهة شبكة نشطة بصورة مفاجئة—مثل إغلاق غطاء حاسوب محمول، أو انتقال هاتف ذكي بين أبراج التغطية الخلوية، أو تعطل مسار نقل وسيط—تعتمد التطبيقات كلياً على مؤقتات طبقة النقل لإدراك فقدان الاتصال بالطرف الآخر. وفي الأنظمة الموزعة ومجمعات اتصالات قواعد البيانات والأنفاق المشفرة لشبكات VPN، يؤدي الاعتماد على قيم المهلة الافتراضية لنظام التشغيل إلى تجمد المقابس لمدد تتراوح بين 15 و30 دقيقة.

يدير نظام التشغيل استمرارية الاتصال عبر آليتين منفصلتين: حزم الاستكشاف الدورية TCP Keepalive أثناء سكون القناة، والعد التنازلي التراجعي لإعادة الإرسال (Retransmission Timeout - RTO) عند وجود بيانات مرسلة لم تتلق إشعار استلام ACK. وبسبب الفصل التاريخي في مواصفات بروتوكول TCP الأصلية، تعمل هاتان الآليتان بمعزل عن بعضهما البعض، مما يولد ثغرة تشغيلية تظل فيها الاتصالات المنقطعة عالقة بلا حل. ولمعالجة هذا القصور، وضعت منظمة IETF المعيار RFC 5482 لتحديد خيار مهلة المستخدم (TCP_USER_TIMEOUT).

الخلل البنيوي: عجز TCP Keepalive أثناء تدفق البيانات

من المفاهيم الخاطئة الشائعة بين مهندسي النظم الاعتقاد بأن تفعيل خيار SO_KEEPALIVE يكفي لضمان الاكتشاف الفوري لتعطل المسار. في الواقع، ووفقاً للوثيقة RFC 1122، يخضع Keepalive لقيد صارم: لا تُرسل حزم الاستكشاف إلا عندما يكون المقبس ساكناً تماماً، أي أن كافة البيانات المرسلة قد جرى تأكيد استلامها مسبقاً (snd_una == snd_nxt).

                ┌─────────────────────────────────┐
                │          مقبس TCP نشط           │
                └────────────────┬────────────────┘
                                 │
                   هل توجد بيانات قيد الإرسال؟
                                 │
                 ┌───────────────┴───────────────┐
                 │ نعم                           │ لا
                 ▼                               ▼
    [ تنشيط مؤقت إعادة الإرسال RTO ]    [ تنشيط مؤقت Keepalive ]
    - يتجاهل خيار SO_KEEPALIVE          - يرسل حزم استكشاف ACK فارغة
    - عدد المحاولات: 15 (tcp_retries2)  - مهلة السكون: 7200 ثانية
    - زمن التعليق: 13 إلى 30 دقيقة      - الاستكشاف: 9 حزم × 75 ثانية
    - تجميد مسارات معالجة البرامج       - الزمن الإجمالي: ساعتان و11 دقيقة

عندما يرسل تطبيق بيانات عبر مقبس ويتعرض المسار الفيزيائي أو نفق VPN لانقطاع مفاجئ، تظل الحزم محتجزة في طابور الإرسال. وبسبب وجود بيانات بانتظار التأكيد، تعطل نواة النظام مؤقت Keepalive وتفعل مؤقت إعادة الإرسال فوراً.

وبحسب إعدادات نواة لينكس الافتراضية (net.ipv4.tcp_retries2 = 15)، يتبع النظام متوالية تأخير أسي تبدأ من قرابة 200 ميلي ثانية وتتضاعف تدريجياً:

$$\text{RTO}{i} = \min\left(\text{RTO}{i-1} \times 2, 120\text{ s}\right)$$

وعلى مدار 15 محاولة إعادة إرسال، يتراكم هذا التأخير ليصل إلى نحو 924 ثانية—أي ما يزيد عن 15 دقيقة—قبل أن تعلن النواة موت الاتصال نهائياً وتصدر خطأ ETIMEDOUT. وخلال هذا الوقت:

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

آليات عمل RFC 5482 وخيار TCP_USER_TIMEOUT

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

في نواة لينكس (بدءاً من الإصدار 2.6.37)، يتوفر هذا الإجراء عبر خيار المقبس TCP_USER_TIMEOUT المعرف في <netinet/tcp.h>.

التنفيذ في نواة لينكس: inet_csk(sk)->icsk_user_timeout

عندما يقوم التطبيق بضبط TCP_USER_TIMEOUT، تخزن النواة القيمة المحددة (بالميلي ثانية) داخل هيكل التحكم في المقبس:

#include <sys/socket.h>
#include <netinet/in.h>
#include <netinet/tcp.h>

int set_tcp_user_timeout(int sockfd, unsigned int timeout_ms)
{
    return setsockopt(sockfd, IPPROTO_TCP, TCP_USER_TIMEOUT, 
                      &timeout_ms, sizeof(timeout_ms));
}

وداخلياً، يراجع روتين مؤقت الكتابة في لينكس (tcp_write_timer()) هذا المؤشر عند كل محاولة لإعادة الإرسال عبر استدعاء دالة retransmits_timed_out():

static bool retransmits_timed_out(struct sock *sk, unsigned int boundary, 
                                  unsigned int timeout)
{
    unsigned int linear_backoff_thresh, start_ts;
    
    if (!inet_csk(sk)->icsk_user_timeout)
        return false;
        
    start_ts = tcp_sk(sk)->retrans_stamp;
    if (tcp_time_stamp(tcp_sk(sk)) - start_ts >= inet_csk(sk)->icsk_user_timeout)
        return true; /* إنهاء الاتصال فوراً */
        
    return false;
}

وعند تفعيل icsk_user_timeout، تتجاوز النواة حسابات عدد المحاولات التقليدية. وبمجرد أن يتعدى الزمن المنقضي منذ إرسال أول مقطع لم يؤكد الحد المقرر، توقف النواة كافة المحاولات غير المجدية وتغلق المقبس لترسل رمز الخطأ ETIMEDOUT إلى التطبيق.

دمج TCP_USER_TIMEOUT مع استكشاف Keepalive

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

يعمل هذا الدمج بتناغم مزدوج:

1. انقطاع القناة أثناء السكون: يطلق مؤقت Keepalive حزمة استكشاف بعد فترة هدوء قصيرة (مثل 10 ثوانٍ). وبمجرد خروج هذه الحزمة عبر الكابل، يتحول المقبس من حالة السكون إلى حالة انتظار إشعار الاستلام.
2. تولي مهلة المستخدم زمام القيادة: نظراً لأن الحزمة أصبحت في مسار الإرسال، يتولى TCP_USER_TIMEOUT المراقبة. فإذا لم يصل رد التأكيد ضمن النافذة المحددة (مثل 5 ثوانٍ)، تقطع النواة الاتصال في الحال.

يوضح جدول المقارنة أن اعتماد TCP_USER_TIMEOUT يقلص زمن التعرف على انقطاع المسار من نصف ساعة إلى 9 ثوانٍ فقط، سواء كان الاتصال يضخ بيانات كثيفة أو يمر بفترة سكون.

الأثر على شبكات الأنفاق المشفرة VPN وواجهات TUN

يمثل تعليق المقابس خطورة بالغة على الشبكات الافتراضية الخاصة VPN. ففي الأنظمة المعتمدة على الواجهات الافتراضية (tun0 أو wg0)، ينشئ التغليف المشفر ارتباطاً ثنائي الطبقات بين تدفقات البيانات الداخلية ونفق النقل الخارجي.

[ مقبس تطبيق HTTP / RPC ] ──── (تدفق TCP الداخلي)
             │
             ▼
[ الواجهة الافتراضية: tun0 ] ── (التغليف والتشفير)
             │
             ▼
[ نفق UDP الخارجي الحامل ] ───── (الواجهة الفيزيائية Wi-Fi / LTE)

معضلة الفجوة الرقمية عند السفر

عندما يتنقل المستخدم بين الشبكات المختلفة:

1. يفقد نفق النقل الخارجي إشارة الاتصال أو يفشل في اختبارات رصد الأطراف المتعطلة (DPD).
2. ومع ذلك، تظل مقابس TCP الداخلية التابعة للتطبيقات معزولة عن معرفة سقوط الرابط الفيزيائي ما لم تصدر إشارات توجيه داخلية فورية.
3. وإذا بادر التطبيق بضخ بيانات في tun0، سيستمر مكدس TCP الداخلي في إعادة المحاولة بلا جدوى طوال 15 دقيقة.

كيف يضمن بروتوكول RiceGuard استجابة فورية

في بنية RiceGuard الحديثة، تستأصل الأنظمة تلك الحالات المعلقة عن طريق مواءمة دورة حياة المقابس الداخلية مع الجلسة التشفيرية للنفق.

وبدمج قواعد التوجيه المتقدمة Core L3 VPN مع الضبط الدقيق لخيارات المقابس، يفرض RiceGuard حداً زمنياً صارماً على مستوى العميل والخادم. وعند انهيار مسار الشبكة:

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

الإعداد العملي ومراقبة القياسات في بيئة الإنتاج

يستطيع مهندسو الشبكات تفعيل TCP_USER_TIMEOUT ومتابعة قياساته عبر واجهات البرمجة وأدوات لينكس القياسية.

ضبط المهلة في شيفرة التطبيقات البرمجية

في لغة Go، يمكن تفعيل TCP_USER_TIMEOUT بسهولة عبر خطاف التحكم في net.Dialer:

package main

import (
    "net"
    "syscall"
    "golang.org/x/sys/unix"
)

func createResilientDialer(timeoutMs int) *net.Dialer {
    return &net.Dialer{
        Control: func(network, address string, c syscall.RawConn) error {
            return c.Control(func(fd uintptr) {
                // تفعيل TCP_USER_TIMEOUT
                _ = unix.SetsockoptInt(int(fd), unix.IPPROTO_TCP, 
                                       unix.TCP_USER_TIMEOUT, timeoutMs)
                // تفعيل SO_KEEPALIVE
                _ = unix.SetsockoptInt(int(fd), unix.SOL_SOCKET, 
                                       unix.SO_KEEPALIVE, 1)
            })
        },
    }
}

المراقبة الحية باستخدام أداة ss

يتيح أمر ss في بيئة لينكس فحص مؤقتات المقابس الداخلية المسجلة في النواة:

# فحص المقاييس الداخلية لمقابس TCP العاملة على المنفذ 443
ss -tin '( sport = :443 or dport = :443 )'

حقول المخرجات البارزة للمتابعة:

• timer:(retrans,...): مؤقت إعادة الإرسال النشط والوقت المنقضي.
• timeout:<ms>: مهلة TCP_USER_TIMEOUT المفعلة على المقبس بالميلي ثانية.
• rto:<ms>: مؤقت إعادة الإرسال الحالي المحسوب وفق خوارزمية RTT.

ويضمن ظهور حقل timeout التزام النواة بقطع الاتصال بمجرد تجاوز المهلة المقررة، بغض النظر عن قيمة tcp_retries2.

الخلاصة: ركيزة أساسية لتصميم شبكات عالية المرونة

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

وفي بيئات شبكات VPN المشفرة والأجهزة المتنقلة، يحول استخدام TCP_USER_TIMEOUT الاتصالات الهشة إلى قنوات متماسكة تملك القدرة على التعافي اللحظي، مما يضمن ثبات الخدمات الرقمية في أصعب ظروف الشبكات.