بروتوكول TCP Early Retransmit RFC 5827: معالجة مهلة RTO في أنفاق VPN

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

في جلسات نقل الملفات الكبيرة التي تتضمن عشرات القطع قيد الإرسال، تعمل خوارزمية Fast Retransmit بفاعلية: إذ تشير ثلاثة إشعارات تأكيد مكررة (Duplicate ACK) متتالية إلى حدوث فقدان فردي معزول، مما يطلق إعادة إرسال فورية للقطعة المفقودة دون تعطيل مسار النقل. إلا أن هذه الفرضية التقليدية تواجه صعوبات مع أنماط حركة المرور التفاعلية الحديثة، حيث ترسل التطبيقات تدفقات بيانات رقيقة (thin streams)، أو نبضات متقطعة، أو تعمل بنوافذ ازدحام صغيرة.

عندما يحتوي اتصال TCP على أقل من أربع حزم قيد النقل في المسار، تصبح إشعارات التأكيد المكررة القادمة عاجزة رياضيا عن بلوغ العتبة الإلزامية البالغة ثلاثة إشعارات. ونتيجة لذلك يتوقف الاتصال تماما في انتظار نفاد مؤقت مهلة إعادة الإرسال Retransmission Timeout (RTO)، مما يفرض عقوبة زمنية تتراوح بين مائتي مللي ثانية وثانية كاملة.

قامت هيئة معايير الإنترنت (IETF) بتوثيق المعيار RFC 5827 تحت اسم Early Retransmit لبروتوكولي TCP وSCTP للتخلص من هذا العائق الزمني. فمن خلال التعديل الديناميكي لعتبة إشعارات التأكيد المكررة عند انخفاض حجم البيانات في المسار، تتيح آلية Early Retransmit استعادة فورية للحزم المفقودة عبر اتصالات VPN والوكيل المشفرة الحساسة لزمن الاستجابة.

[آلية Fast Retransmit القياسية: تتطلب ما لا يقل عن 4 حزم في المسار]
المرسل ──[P1]──[P2]──[P3]──[P4]──> المستقبل (فقدت الحزمة P1 في الطريق)
المرسل <──[Ack 1]──[DupAck 1]──[DupAck 2]──[DupAck 3]── (3 تأكيدات مكررة تطلق إعادة الإرسال)

[جمود النافذة الصغيرة بدون RFC 5827: حزمتان فقط في المسار]
المرسل ──[P1]──[P2]──────────────> المستقبل (فقدت الحزمة P1 في الطريق)
المرسل <──[Ack 1]──[DupAck 1]──── (تأكيد مكرر واحد فقط! تعذر تفعيل Fast Retransmit)
       └─── تجمد الاتصال ─────────> [انتظار مؤقت RTO لمدة 200 إلى 1000 مللي ثانية!]

[آلية RFC 5827 Early Retransmit: خفض ذكي لعتبة الإشعار]
المرسل ──[P1]──[P2]──────────────> المستقبل (فقدت الحزمة P1 في الطريق)
المرسل <──[Ack 1]──[DupAck 1]──── (FlightSize < 4*SMSS -> خفض العتبة تلقائيا إلى 1)
المرسل ──[إعادة إرسال P1 فورا]───> (تعاف فوري ومباشر دون انتظار مهلة RTO)

معضلة النوافذ الصغيرة: تعطل Fast Retransmit في التدفقات التفاعلية

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

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

لماذا يشترط معيار TCP Fast Retransmit ثلاثة إشعارات ACK مكررة

وفقا لضوابط التحكم في الازدحام المحددة في RFC 5681، يرسل المستقبل إشعار ACK مكررا فور تلقيه أي قطعة بيانات تخرق التسلسل الرقمي المتوقع. ويعيد هذا الإشعار تأكيد أعلى رقم تسلسلي تم تسلمه بالترتيب دون ثغرات.

ولكي يتمكن المرسل من جمع ثلاثة إشعارات تأكيد مكررة، يجب أن تصل إلى المستقبل ثلاث قطع بيانات تالية على الأقل بعد القطعة المفقودة:

$$\text{الحد الأدنى للحزم في المسار} = 1\ (\text{القطعة المفقودة}) + 3\ (\text{القطع اللاحقة}) = 4\ \text{حزم}$$

وإذا كانت نافذة الازدحام ($\text{CWND}$) أو إجمالي البايتات غير المؤكدة في المسار ($\text{FlightSize}$) أقل من $4 \times \text{SMSS}$ (الحد الأقصى لحجم قطعة المرسل)، يصبح توليد ثلاثة إشعارات تأكيد مكررة مستحيلا حسابيا. ويكتفي المستقبل بإرسال تأكيد مكرر واحد أو اثنين ثم يتوقف.

الخسائر الزمنية لمهلة إعادة الإرسال RTO مع حركة البيانات المتقطعة

عندما يعجز عدد الإشعارات المكررة عن بلوغ الرقم ثلاثة، يدخل مكدس TCP القياسي في حالة جمود كامل. ويتوقف إرسال البيانات ريثما ينتهي مؤقت إعادة الإرسال $RTO$، المحسوب طبقا لمعادلة RFC 6298:

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

وفي البيئات التشغيلية العملية، يُضبط الحد الأدنى لقيمة $RTO$ عند $200\text{ ms}$ في نواة لينكس، وقد يصل إلى $1000\text{ ms}$ في مكدسات أخرى.

وبالنسبة لحركة المرور التفاعلية المباشرة — مثل طباعة الأوامر عبر SSH، واستدعاءات واجهات برمجة التطبيقات API، وإشارات تحكم WebRTC، واستعلامات بروتوكول DNS المشفر، وحزم الألعاب متعددة اللاعبين — فإن توقفا يمتد من $200\text{ ms}$ إلى $1000\text{ ms}$ يؤدي إلى بطء في التجاوب. ويشعر المستخدم بجمود تام، تليه قفزات مفاجئة في زمن الاستجابة داخل النفق المشفر.

بنية ومبادئ بروتوكول RFC 5827 Early Retransmit

يقدم المعيار RFC 5827 حلا مباشرا لهذه المشكلة بالسماح للمرسل بخفض عتبة إشعارات ACK المكررة ديناميكيا عندما يكتشف أن طاقة المسار غير كافية لإنتاج ثلاثة إشعارات.

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

مع وصول كل إشعار جديد، يقيّم مرسل TCP حجم البيانات غير المؤكدة المتبقية في النقل. فإذا كان الحجم ضمن النطاق المنخفض، تعيد خوارزمية Early Retransmit حساب شرط التفعيل:

1. تقييم حمولة المسار: إذا كان $\text{FlightSize} < 4 \times \text{SMSS}$، يستنتج المرسل تعذر إنتاج ثلاثة إشعارات تأكيد مكررة.
2. التعديل الديناميكي للعتبة: تُضبط عتبة الإشعارات المطلوبة ($ER\text{_threshold}$) مساوية للحد الأقصى من الإشعارات التي يمكن للحزم المتبقية توليدها: $$ER\text{_threshold} = \left\lfloor \frac{\text{FlightSize} - 1}{\text{SMSS}} \right\rfloor$$
   • عندما تكون $\text{FlightSize} = 3 \times \text{SMSS}$، تصبح العتبة $ER\text{_threshold} = 2$.
   • عندما تكون $\text{FlightSize} = 2 \times \text{SMSS}$، تصبح العتبة $ER\text{_threshold} = 1$.
3. شرط خلو الذاكرة المؤقتة من بيانات جديدة: لا تُفعّل آلية Early Retransmit إلا إذا كان المخزن المؤقت للمقبس خاليا من أي بيانات جديدة تنتظر الإرسال. وإذا وفر التطبيق بيانات إضافية، يمنح المرسل الأولوية لإرسال قطع جديدة وفق آلية Limited Transmit (RFC 3042) في محاولة للتعافي بالأسلوب التقليدي.

مقارنة بين تطبيقي Early Retransmit المعتمدين على القطع والبايتات

تحدد مواصفة RFC 5827 نهجين للتنفيذ:

• النمط القائم على القطع (Segment-Based): مخصص لاتصالات TCP التي تفتقر لدعم خيار الإشعارات الانتقائية (SACK). يقوم المرسل بإحصاء عدد الحزم في المسار وإعادة الإرسال فور مطابقة التأكيدات لعدد الحزم.
• النمط القائم على البايتات (Byte-Based): مصمم للمكدسات الحديثة المزودة بدعم SACK (RFC 2018). يعتمد المرسل على نطاقات البايتات الدقيقة الواردة في كتل SACK. وعندما تثبت هذه الكتل أن جميع البايتات التي تلي الفجوة المفقودة قد بلغت وجهتها، يبادر المرسل لإعادة الإرسال فورا وبلا تردد.

وتعتمد أنوية لينكس المعاصرة النمط القائم على البايتات، نظرا لأن خيار SACK بات مفعلا في الغالبية العظمى من اتصالات الإنترنت.

التكامل مع SACK والحماية من عمليات إعادة الإرسال الخاطئة

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

وتتضمن مواصفة RFC 5827 آليات دفاعية للحد من عمليات إعادة الإرسال غير الضرورية.

توظيف الإشعارات الانتقائية لتحديد موقع الحزم المفقودة بدقة

عند تفعيل خيار SACK، يرفق المستقبل نطاقات الأرقام التسلسلية المفصلة للقطع التي وصلت خارج الترتيب. ولنأخذ مثالا لإرسال ثلاث قطع:

يرسل الطرف المرسل: القطعة 1 (Seq 1000-2000)، القطعة 2 (Seq 2000-3000)، القطعة 3 (Seq 3000-4000)
فقدت القطعة 1 أثناء العبور.
يتسلم المستقبل القطعة 2 -> الإشعار: Ack 1000, SACK [2000-3000]
يتسلم المستقبل القطعة 3 -> الإشعار: Ack 1000, SACK [2000-4000]

عند ورود الإشعار المكرر الثاني، يعلم المرسل عبر كتل SACK أن 2000 بايت تلي القطعة المفقودة قد وصلت بنجاح. وبما أن إجمالي حمولة النقل لم يتجاوز 3000 بايت، يتأكد للمرسل عدم وجود أي حزم أخرى في المسار. ومن ثم يصبح انتظار إشعار ثالث غير مجد، فتقوم آلية Early Retransmit بإعادة إرسال القطعة الأولى فورا.

احتواء اضطراب ترتيب الحزم عبر مؤقت التأخير Early Retransmit Delay

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

وعند تحقق عتبة الإشعارات المخفضة، لا ترسل النواة الحزمة في الحال، بل تنتظر فترة قصيرة تستند إلى جزء من وقت الذهاب والإياب الممهد:

$$\text{ER_Delay} = \frac{\text{SRTT}}{4}$$

فإذا وصلت الحزمة المتأخرة وتلقى المرسل إشعارا يسد الفجوة قبل انتهاء $\text{ER_Delay}$، تُلغى عملية إعادة الإرسال. أما إذا انقضت المهلة، فيُعتمد الفقدان نهائيا وتُعاد الحزمة فورا. وتجمع هذه الصيغة بين منع تأخيرات RTO والحفاظ على الاستقرار أمام اضطراب الترتيب.

ديناميكيات زمن الاستجابة والإنتاجية عبر أنفاق الشبكات المشفرة

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

التخلص من ارتفاعات زمن الاستجابة RTO في اتصالات VPN المغلفة

في الشبكات الخلوية المتنقلة، وأثناء التبديل بين شبكات Wi-Fi، يحدث فقدان الحزم عادة على نحو مفاجئ ومتقطع جراء التشويش اللاسلكي أو امتلاء طوابير المحطات.

في الاتصالات العادية التي لا تعتمد إعادة الإرسال المبكر، يؤدي فقدان حزمة في نافذة صغيرة عبر VPN إلى بطء الاتصال. ويعيد مؤقت RTO ضبط نافذة الازدحام إلى قطعة واحدة ($\text{CWND} = 1$)، مما يجبر المسار على العودة لمرحلة البدء البطيء (Slow Start).

ويعمل المعيار RFC 5827 على إبقاء الاتصال في طور التعافي السريع، مكتفيا بتنصيف النافذة بدلا من تصفيرها، مما يضمن استعادة سريعة للإنتاجية.

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

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

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

[حركة المرور التفاعلية للتطبيقات]
   (SSH / HTTPS / API / الألعاب الشبكية)
                    │
                    ▼  (نوافذ صغيرة ونبضات متقطعة)
[طبقة تسريع TCP في محرك RiceGuard]
   ├── تفعيل معيار RFC 5827 Early Retransmit على مستوى البايتات
   ├── مواءمة حزم SACK والتحقق من كتل DSACK المكررة
   ├── مؤقت ديناميكي ER Delay Timer للحماية من اضطراب الترتيب
   └── التنسيق الزمني مع خوارزميات التدفق BBRv3 وCUBIC
                    │
                    ▼  (القضاء على تأخيرات RTO عند فقدان الحزم)
[نفق النقل المشفر للشبكة]
   (WireGuard / IPsec ESP / ChaCha20-Poly1305)

1. التطبيق الإلزامي للمعيار RFC 5827: تطبق بوابات RiceGuard خوارزمية Early Retransmit القائمة على البايتات مع مؤقت التأخير، لمنع انزلاق الجلسات التفاعلية إلى فجوات الانتظار البالغة 200 مللي ثانية.
2. المواءمة الشاملة للإشعارات الانتقائية: يضمن RiceGuard دعم خياري SACK (RFC 2018) وDSACK (RFC 2883) للنفق الخارجي وللبيانات المنقولة داخله، مما يتيح للنواة تمييز الحزم المفقودة عن تلك المكررة بدقة.
3. تنظيم إرسال الحزم وإدارة الطوابير: يسهم دمج آلية Early Retransmit مع خوارزميات إدارة الطوابير النشطة (FQ/CoDel) في تفادي تكدس الحزم عند أبراج الاتصال اللاسلكية، مما يقلل من نسب الفقد أثناء التنقل بين المحطات.

الفحص والتحقق التشخيصي: مراقبة Early Retransmit عبر مقابس الاتصال

يستطيع مهندسو الشبكات ومديرو الأنظمة التحقق من حالة تفعيل معايير RFC 5827 على بوابات لينكس عبر واجهات النواة القياسية.

التحقق من إعدادات sysctl الحالية الخاصة بخوارزمية Early Retransmit:

# فحص القيمة الحالية لمعيار TCP Early Retransmit
sysctl net.ipv4.tcp_early_retrans

# دلالات القيم:
# 0: معطل
# 1: النمط المعتمد على القطع
# 2: النمط المعتمد على البايتات
# 3: النمط المعتمد على البايتات مع مؤقت تأخير (الإعداد الموصى به في لينكس)

ولتفعيل النمط المعتمد على البايتات المزود بمؤقت التأخير الوقائي، يُنفذ الأمر التالي:

# تفعيل RFC 5827 مع مؤقت الوقاية من اضطراب الترتيب
sudo sysctl -w net.ipv4.tcp_early_retrans=3

ولمتابعة الاتصالات النشطة والتأكد من عمل آلية التعافي المبكر، يمكن استخدام أداة ss:

# فحص مقاييس TCP الداخلية وبيانات إعادة الإرسال
ss -ti dst 198.51.100.1

ابحث في النتائج عن العداد early_retrans ونسبة retrans. ويشير تسجيل قيم متزايدة في هذا العداد تزامنا مع بقاء مؤشرات RTO عند الصفر إلى أن مكدس النقل يعوض الحزم المفقودة بمرونة دون إحداث بطء في حركة البيانات التفاعلية.

تحميل VPNRice.