بروتوكول TCP RACK-TLP RFC 8985: رصد فقدان الحزم زمنيا ومسبار الذيل في شبكات VPN

على مدى أكثر من ثلاثة عقود، اعتمد بروتوكول التحكم في النقل Transmission Control Protocol (TCP) على أسلوب عد تجريبي لرصد فقدان الحزم: فعندما يتلقى الطرف المرسل ثلاثة إشعارات تأكيد مكررة (Duplicate ACK، وتختصر DupACK)، يفترض النظام أن حزمة وسيطة قد فُقدت في المسار ولم يكن الأمر مجرد اضطراب عابر في ترتيب الوصول. وقد صيغت هذه القاعدة في معيار RFC 5681 استنادا إلى فرضية قديمة تفترض تماثل مسارات التوجيه في الإنترنت، وتجانس سرعات الروابط، وندرة حدوث انعكاسات في تسلسل الحزم.

وفي بيئات الشبكات الحالية، يتعثر هذا النموذج القديم بصورة متكررة. فالأنفاق المشفرة، وبطاقات واجهة الشبكة متعددة الطوابير (multi-queue NIC)، وإعادة الإرسال على طبقة وصلة Wi-Fi، وتجميع الموجات الحاملة في الشبكات الخلوية، والشبكات المعرفة برمجيا (SD-WAN) تؤدي جميعها بانتظام إلى حدوث إعادة ترتيب حميدة للحزم. ويكفي انعكاس ترتيب حزمتين متتاليتين لإطلاق آلية إعادة الإرسال السريع Fast Retransmit عن طريق الخطأ، مما يخفض نافذة الازدحام إلى النصف ويهوي بمعدل نقل البيانات. وعلى العكس من ذلك، عندما يحدث الفقدان في نهاية دفعة البيانات المرسلة (فقدان الذيل أو tail drop)، لا توجد حزم لاحقة في المسار لتوليد ثلاثة إشعارات تأكيد مكررة، مما يُدخل الاتصال في حالة جمود وانتظار لمؤقت مهلة إعادة الإرسال Retransmission Timeout (RTO) تتراوح بين مائتي مللي ثانية وثانية كاملة.

ولتحديث آليات التعافي في طبقة النقل، قامت هيئة معايير الإنترنت (IETF) بتوثيق المعيار RFC 8985: خوارزمية رصد فقدان الحزم RACK-TLP لبروتوكول TCP. ومن خلال استبدال العد التسلسلي بالاستنتاج الزمني الفيزيائي (Recent ACKnowledgment، أو RACK) وتدعيمه بمسبار استباقي لفقدان الذيل (Tail Loss Probe، أو TLP)، يمنح المعيار RFC 8985 اتصالات VPN المعرضة للتقلبات قدرة تعاف عالية وحصانة متقدمة.

[النهج التقليدي: عتبة صلبة من 3 إشعارات مكررة]
المرسل ──[P1]──[P2]──[P3]──[P4]──> المستقبل (وصلت P2 قبل P1 بسبب اضطراب الترتيب)
المرسل <──[Ack 0]──[DupAck 0]──[DupAck 0]──[DupAck 0] (تفعيل خاطئ لآلية Fast Retransmit!)
المرسل يخفض نافذة CWND إلى النصف دون داع -> انهيار فوري لمعدل تدفق البيانات.

[معيار RFC 8985 RACK: استنتاج زمني عبر نافذة إعادة الترتيب]
المرسل ──[P1]──[P2]──────────────> المستقبل (سُلمت P2 في T1، ووصلت P1 بعدها بمللي ثانتين)
المرسل يتلقى إشعار P2 -> يحسب: الوقت المنقضي < نافذة إعادة الترتيب لـ RACK.
المرسل يعلق إعادة الإرسال -> يتلقى إشعار P1 -> تظل نافذة CWND سليمة تماما.

[معيار RFC 8985 TLP: سبر استباقي لحالات فقدان الذيل]
المرسل ──[P1]──[P2]──────────────> المستقبل (فقدت P2؛ ولا توجد حزم لاحقة في المسار)
بروتوكول TCP التقليدي: يتجمد تماما لمدة 200 إلى 1000 مللي ثانية بانتظار مهلة RTO.
معيار RFC 8985 TLP:   يطلق مؤقت PTO (حوالي ضعف SRTT) -> يرسل حزمة مسبار واحدة.
المستقبل يرد بإشعار مكرر -> RACK يطلق Fast Recovery فورا -> تقليص التأخير بنسبة 85%+.

حدود عد الحزم: لماذا تفشل إشعارات التأكيد المكررة التقليدية في الشبكات الحديثة

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

أما إنترنت اليوم فيعتمد على جدولة الحزم عبر معالجات متعددة الأنوية، وتوزيع الأحمال عبر مسارات متكافئة التكلفة (ECMP)، والتغليف الديناميكي للأنفاق، مما يولد فوارق زمنية طفيفة بين أنوية المعالجة المتوازية.

ضعف عتبة الإشعارات الثلاثة التقليدية أمام اضطرابات الترتيب الدقيقة

يفرض اشتراط ثلاثة إشعارات تأكيد مكررة لتأكيد فقدان الحزمة تسوية تقنية ذات أثر سلبي:

• عتبة منخفضة (إشعار أو إشعاران): يؤدي أي اضطراب طفيف في ترتيب الحزم عبر روابط Wi-Fi أو LTE إلى عمليات إعادة إرسال خاطئة. ويدخل المرسل في طور Fast Recovery قبل الأوان، مما يقلص عتبة البدء البطيء (ssthresh) ويهدر سعة القناة.
• عتبة مرتفعة (3 إشعارات): تعجز الاتصالات ذات التدفقات الرقيقة — مثل أوامر SSH التفاعلية، ومراحل مصافحة TLS، واستدعاءات واجهات برمجة التطبيقات RPC — عن إنتاج ثلاثة إشعارات مكررة عند سقوط حزمة، مما يترك الاتصال معلقا بانتظار RTO.

وعندما تعبر الحزم أنفاق الحماية المشفرة مثل WireGuard أو IPsec ESP أو OpenVPN، تؤدي المعالجة التشفيرية الموزعة على خيوط معالجة متعددة إلى انعكاسات موضعية في الترتيب. ويعجز العداد الثابت عن التمييز بين هذا التبديل المؤقت غير الضار والفقدان الحقيقي.

قصور آلية SACK عند فقدان حزم الذيل وعلى المسارات غير المتماثلة

قدم خيار الإشعار الانتقائي Selective Acknowledgment (RFC 2018) ميزة مهمة بإبلاغ المرسل بكتل البيانات المستلمة خارج الترتيب. ومع ذلك، تظل آلية SACK بطبيعتها استجابة تفاعلية سالبة: فهي لا تبلغ إلا عن الأرقام التسلسلية التي تسلمها المستقبل بالفعل.

فإذا حدث الفقدان في الحزمة الأخيرة من الدفعة — مثل إطار HTTP/2 الأخير في استجابة ويب أو ضغطة زر منفردة عبر الطرفية — فلن تتبعها حزم أخرى تدفع المستقبل لإصدار كتلة SACK جديدة. وفي هذا الموقف، تصبح آلية SACK معطلة تماما، تاركة الاتصال تحت وطأة مؤقت RFC 6298:

$$RTO = \text{SRTT} + \max(G, 4 \times \text{RTTVAR})$$

ومع ضبط أنظمة التشغيل الحد الأدنى لمؤشر $RTO$ عند $200\text{ ms}$، يؤدي فقدان الذيل إلى تجميد ملحوظ في استجابة الجلسات الآمنة.

البنية الجوهرية لمعيار RFC 8985: آلية Recent ACKnowledgment (RACK)

يفصل المعيار RFC 8985 عملية رصد فقدان الحزم عن إزاحة الأرقام التسلسلية، مستندا بصورة حصرية إلى الطوابع الزمنية الفيزيائية للإرسال والتأكيد.

استنتاج فقدان الحزم بناء على الطوابع الزمنية بدلا من عد إزاحة الأرقام

تعتمد آلية Recent ACKnowledgment (RACK) على منطق هندسي مباشر: إذا تأكد تسليم حزمة أُرسلت في اللحظة $T_1$، فإن أي حزمة غير مؤكدة أُرسلت قبل $T_1$ وتجاوزت مدة زمنية كافية تُعد في حكم المفقودة.

وبدلا من إحصاء الحزم التي وصلت بعد الحزمة الغائبة، يتابع RACK الجدول الزمني لعمليات التسليم:

1. RACK.xmit_ts: تُوسم كل حزمة بيانات جديدة أو معاد إرسالها بطابع زمني تصاعدي عالي الدقة يوثق لحظة مغادرتها مكدس الشبكة.
2. RACK.end_seq: يسجل أعلى رقم تسلسلي جرى إرساله حتى اللحظة.
3. RACK.rtt: يحتفظ بأحدث قيمة مقاسة لزمن الذهاب والإياب RTT مستخلصة من إشعار وارد (سواء عبر ACK التراكمي أو كتلة SACK).
4. معيار الفقدان: يُعلن فقدان الحزمة غير المؤكدة $S$ عند تحقق الشرط التالي: $$S.\text{xmit_ts} + \text{RACK.rtt} + \text{RACK.rwin} \le \text{Current_Time}$$ حيث تمثل $\text{RACK.rwin}$ نافذة إعادة الترتيب المتكيفة ديناميكيا.

وبفضل الاعتماد على البعد الزمني الحقيقي، يعمل RACK بنفس الكفاءة سواء كان هناك عشرات الحزم في المسار أو حزمة وحيدة متبقية.

التكيف الديناميكي لنافذة إعادة الترتيب وتتبع تباين زمن الذهاب والإياب

لمنع التحذيرات الخاطئة الناتجة عن اضطرابات الترتيب العابرة، يوظف RACK نافذة تكيفية ($\text{RACK.rwin}$). فإذا استشعر المرسل وجود اضطراب متكرر في الترتيب عبر المسار، يقوم تلقائيا بتوسيع هذه النافذة لمنح الحزم المتأخرة فرصة الوصول قبل تقرير إعادة إرسالها.

وتُحسب النافذة الأساسية وفق المعادلة التالية:

$$\text{RACK.rwin} = \max\left(\frac{\text{SRTT}}{4}, \text{Min_RTT_Window}\right)$$

وحينما تؤكد كتلة DSACK (RFC 2883) أن الحزمة التي تمت إعادة إرسالها سابقا قد وصلت بالفعل في وقت سابق، يدرك RACK حدوث إعادة إرسال خاطئة ناتجة عن خلل في الترتيب. واستجابة لذلك، يرفع RACK قيمة $\text{RACK.rwin}$ لتحصين الحزم التالية ضد الإنذارات الزائفة؛ وحين يستقر المسار، تتراجع النافذة تدريجيا إلى مستواها المرجعي.

[مخطط اتخاذ القرار في خوارزمية RACK]
     ┌────────────────────────────────────────────────────────┐
     │             استلام إشعار ACK جديد أو كتلة SACK        │
     └───────────────────────────┬────────────────────────────┘
                                 │
                                 ▼
     ┌────────────────────────────────────────────────────────┐
     │       تحديث RACK.rtt والطابع الزمني لأحدث تسليم        │
     └───────────────────────────┬────────────────────────────┘
                                 │
                                 ▼
               هل يتحقق الشرط S.xmit_ts + RACK.rtt + RACK.rwin
                         <= Current_Time ؟
                                ╱ ╲
                              ╱     ╲
                             نعم     لا
                            ╱         ╲
                           ▼           ▼
             ┌───────────────────┐   ┌───────────────────────┐
             │ إعلان فقدان الحزمة│   │ تفعيل مؤقت تأخير RACK │
             │ إعادة الإرسال فورا│   │ انتظار وصول الحزمة    │
             └───────────────────┘   └───────────────────────┘

القضاء على فترات توقف إعادة الإرسال عبر مسبار فقدان الذيل (TLP)

بينما ينجح RACK في تشخيص الفقدان بكفاءة عند توفر إشعارات لاحقة، فإنه يحتاج لمعالجة حالة خاصة عند سقوط الحزمة الأخيرة تماما من التدفق. ولحل معضلة فقدان الذيل دون الخضوع لانتظار مؤقت RTO، يدمج المعيار RFC 8985 خوارزمية مسبار فقدان الذيل Tail Loss Probe (TLP).

السبر الاستباقي للذيل: تحويل مهلات RTO المعطلة إلى تعاف سريع Fast Recovery

تقدم تقنية Tail Loss Probe مؤقتا قصير الأجل يُعرف باسم Probe Timeout (PTO). فعندما يتوقف الاتصال عن إرسال بيانات جديدة مع بقاء حزم معلقة في المسار، ينقضي مؤقت PTO قبل فترة طويلة من وصول مؤقت RTO الثقيل إلى نهايته.

وعند انقضاء PTO، لا يعيد المرسل ضبط نافذة الازدحام ولا يفترض انقطاع المسار؛ بل يبادر بإرسال حزمة مسبار مفردة — إما بيانات جديدة لم تُرسل بعد من المخزن المؤقت، أو إعادة إرسال للحزمة ذات الرقم التسلسلي الأعلى.

وبمجرد استلام هذه الحزمة المسبار، يضطر الطرف المستقبل للرد بإشعار مكرر أو كتلة SACK. وتوفر هذه الاستجابة الحية لآلية RACK طابعا زمنيا جديدا يمكنها من اكتشاف الحزمة المفقودة سابقا فورا، والدخول في مرحلة Fast Recovery دون هبوط في سرعة التدفق.

الحسابات الرياضية لمؤقت السبر PTO وسياسات اختيار حزمة المسبار

يُحسب النطاق الزمني لمؤقت Probe Timeout ليتدخل مباشرة بعد التوقيت المتوقع لوصول إشعار عادي، مع هامش أمان لتغطية تقلبات الشبكة:

$$\text{PTO} = \begin{cases} \max(2 \times \text{SRTT}, 10\text{ ms}) & \text{إذا كان عدد الحزم في المسار } = 1 \ \max(2 \times \text{SRTT}, 1.5 \times \text{SRTT} + \text{Wdelay}) & \text{إذا كان عدد الحزم في المسار } > 1 \end{cases}$$

ويعبر المتغير $\text{Wdelay}$ عن زمن تأخير الإشعار المسموح به لدى المستقبل (المضبوط عادة عند $200\text{ ms}$ أو الصفر عند توفر استجابة فورية عبر SACK).

ومن خلال استدراج رد فوري من الطرف الآخر، يحول TLP كوارث مهلة RTO الطويلة إلى عمليات تعاف رشيقة وسلسة.

ديناميكيات طبقة النقل عبر أنفاق شبكات VPN المشفرة

تضيف عملية تغليف البيانات داخل أنفاق الشبكات الآمنة ترويسات بروتوكولية إضافية (IP وUDP وESP وWireGuard)، مما يقلص الحجم الأقصى للقطعة (MSS) ويزيد من احتمالات تجزئة الحزم. يضاف إلى ذلك أن المسار عبر الشبكات العامة يخضع لتقلبات في زمن الوصول.

تخفيف اضطرابات الشبكات الخلوية وعكس ترتيب الحزم أثناء تجوال Wi-Fi

في الهواتف والأجهزة المحمولة، يؤدي التبديل بين محطات Wi-Fi وأبراج التغطية الخلوية إلى تأخيرات طارئة في الطوابير، مما يجعل الحزم القديمة تصل بعد الحزم المنطلقة من الواجهة الجديدة.

وفي ظل مكدس TCP الكلاسيكي:

1. يؤدي تبديل الواجهة لعكس ترتيب حزمتين متتاليتين.
2. يصدر المستقبل إشعارين مكررين DupACK.
3. وإذا فُقدت حزمة وسيطة، يتجمد الاتصال لعدم وجود حزمة ثالثة تولد إشعار DupACK المطلوب.
4. يتوقف التطبيق لنحو 300 مللي ثانية حتى تنتهي مهلة RTO.

أما تحت إشراف معيار RFC 8985:

1. يقارن RACK التوقيت بنافذة $\text{RACK.rwin}$ المتكيفة، فيتجاهل الإنذار الخاطئ الناتج عن التنقل بين الشبكات.
2. وإذا كانت الحزمة الأخيرة قد فُقدت حقا، يتدخل TLP بمسبار بعد زمن $2 \times \text{SRTT}$، ليعيد RACK تصحيح المسار خلال مللي ثوان معدودة.

بنية نواة النظام المتقدمة: تحسين مكدس النقل عبر محرك RiceGuard

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

وتعتمد بنية شبكة VPNRice على محرك RiceGuard المتطور لضبط معلمات طبقة النقل على خوادم البوابات وأجهزة العملاء:

[حركة المرور التفاعلية للتطبيقات]
   (SSH / HTTP/2 / WebRTC / الألعاب الشبكية)
                     │
                     ▼  (تدفقات خفيفة ومتقطعة)
[طبقة تسريع النقل في RiceGuard]
   ├── محرك RFC 8985 RACK-TLP (رصد الفقدان المستند إلى الوقت)
   ├── المعايرة التكيفية لنافذة إعادة الترتيب (الحماية من التكرار)
   ├── الجدولة الذكية لمؤقت PTO (إنقاذ حزم الذيل المفقودة)
   └── مواءمة التدفق مع خوارزميات BBRv3 وCUBIC Pacing
                     │
                     ▼  (إلغاء فترات جمود مؤقت RTO)
[نفق النقل المشفر للشبكة]
   (WireGuard / IPsec ESP / ChaCha20-Poly1305)

1. الاعتماد الكلي لمعيار RACK-TLP: يضمن RiceGuard عمل جميع المقابس على الخوادم وفق آلية التقييم الزمني، ملغيا الاعتماد على قاعدة الإشعارات الثلاثة المكررة.
2. مناعة الأنفاق ضد اضطراب الترتيب: تسهم مواءمة مؤشرات RACK للبيانات الداخلية مع وسائط UDP الخارجية في منع تراجع سرعة النقل بسبب التوجيه متعدد المسارات لدى المزودين.
3. تنظيم وتيرة الإرسال وتفادي طفح الطوابير: تُدار حزم السبر التابعة لـ TLP عبر آليات الجدولة النشطة (FQ/CoDel)، مما يمنع سقوطها بسبب امتلاء الذاكرة المؤقتة المحلية.

الفحص والتحقق التشخيصي: مراقبة المقابس الداعمة لآليتي RACK وTLP

يستطيع مهندسو الشبكات ومديرو الأنظمة التحقق من حالة تفعيل معايير RFC 8985 RACK-TLP على خوادم لينكس عبر واجهات النواة وأدوات الفحص المدمجة.

الاطلاع على إعدادات استعادة TCP الحالية في النظام:

# فحص إعدادات استعادة فقدان الحزم لبروتوكول TCP
sysctl net.ipv4.tcp_recovery

# دلالة قناع البتات في نواة لينكس:
# 0x1: تفعيل رصد الفقدان عبر RACK
# 0x2: تفعيل آلية مسبار فقدان الذيل (TLP)
# 0x4: تفعيل نافذة إعادة الترتيب التكيفية
# القيمة الموصى بها: 0x7 (تفعيل الميزات بالكامل، وهو الخيار الافتراضي منذ لينكس 4.15)

وللتأكد من تشغيل حزمة RACK-TLP الكاملة، يُنفذ الأمر التالي:

# تفعيل كامل ميزات RFC 8985 RACK-TLP في النواة
sudo sysctl -w net.ipv4.tcp_recovery=7

ولفحص الاتصالات النشطة والتحقق من اعتمادها على الاستنتاج الزمني، يمكن استخدام أداة ss:

# استعراض مؤشرات TCP التفصيلية لاتصال نشط
ss -ti dst 198.51.100.1

ابحث في المخرجات عن كلمة rack بين خصائص الاتصال، إلى جانب مؤشر reord، وعدادات tlp وrto. وتحافظ الاتصالات التي تعمل بموجب RFC 8985 على تدفق مستقر، وتسجل ما يقارب الصفر من مهلات RTO أثناء الانتقال عبر الشبكات اللاسلكية.

تحميل VPNRice.