بروتوكول TCP PRR RFC 6937: تعافي الفقد وتنظيم FlightSize واستقرار زمن VPN

تعتمد مسارات النقل المشفرة عالية السرعة والشبكات الافتراضية الخاصة للمؤسسات اعتماداً أساسياً على بروتوكول TCP لنقل البيانات بأمان وموثوقية. وعندما تعبر الحزم عبر مسارات إنترنت متعددة القفزات أو عبر شبكات الاتصال الخلوي أو شبكات Wi-Fi المعرضة للتداخل، يصبح فقدان الحزم أمراً حتمياً. وتحدد الطريقة التي تستجيب بها طبقة النقل لهذا الفقد ما إذا كان التطبيق سيتعرض لتوقف وجيز غير ملحوظ أو سيواجه تجميداً تاماً للتدفق مصحوباً بارتفاع حاد في زمن الاستجابة ناتج عن تضخم طوابير الانتظار (bufferbloat).

على مدار عقدين تقريباً، اعتمد التحكم القياسي في الازدحام على آليات التعافي السريع التقليدية (Fast Recovery) المحددة في معايير RFC 3517 و RFC 5681. وعانت هذه الآليات من خلل بنيوي واضح: فعند اكتشاف فقدان الحزم، كانت تفرض صمتاً تاماً عن الإرسال يعقبه تدفق مفاجئ للبيانات، مما يتسبب في فجوات تدفق معطلة للمسار. وضع معيار RFC 6937 الصادر عن هيئة IETF خوارزمية خفض المعدل التناسبي (Proportional Rate Reduction أو PRR)، والتي تعيد صياغة تعافي الفقد عبر تنظيم وتيرة إرسال الحزم بتناسق مستمر، مما يزيل التوقفات المفاجئة ويحقق استقراراً فائقاً في الأداء.

معضلة الفجوة الهوائية في مسار النقل: كيف يجمد التعافي السريع التقليدي تدفق TCP

في النموذج التقليدي للتحكم في ازدحام TCP، يشير استقبال ثلاثة إشعارات وصول مكررة (Duplicate ACK) إلى أن المسار الشبكي لم يعد قادراً على استيعاب نافذة الازدحام الحالية (CWND). يستجيب البروتوكول بخفض قيمة النافذة إلى النصف لتعيين عتبة بدء بطيء جديدة (ssthresh). ورغم أن تقليل معدل الإرسال ضروري لتخفيف الضغط على طوابير التوجيه، إلا أن طريقة التنفيذ في المعايير القديمة أحدثت آثاراً جانبية بالغة الضرر.

وفقاً لمعيار RFC 3517، يتتبع المرسل حجم البيانات العالقة في مسار النقل دون إشعار وصول (FlightSize). وعند وقوع فقد للحزم، يتجاوز حجم البيانات العالقة العتبة الجديدة المخفضة ssthresh بشكل كبير:

اكتشاف حالة فقدان الحزم:
  الحالة الابتدائية : CWND = 40 حزمة، FlightSize = 40 حزمة
  الحالة المستهدفة  : ssthresh = 20 حزمة

استجابة التعافي التقليدي:
  توقف تام عن إرسال أي حزم جديدة حتى يهبط FlightSize من 40 إلى 20.
  مدة الصمت عن النقل: نحو نصف زمن الذهاب والعودة (0.5 * RTT).

يؤدي هذا التوقف الإجباري إلى نشوء ما يسمى «الفجوة الهوائية في مسار النقل» (pipeline bubble). فطوال نصف دورة زمن الاستجابة، لا يرسل المصدر أي حزمة على الإطلاق، فتفرغ طوابير الانتظار في العقد الوسيطة بالكامل. وعندما ينخفض FlightSize أخيراً إلى عتبة ssthresh، يستأنف المرسل تدفق البيانات فجأة عبر ضخ دفعة كثيفة من الحزم المتتالية في المسار الذي فرغ لتوه. يتسبب هذا التدفق في إعادة ملء طوابير الانتظار وتجاوز سعتها، مما يؤدي إلى موجة فقد ثانوية وانهيار الاتصال نحو مهلة إعادة الإرسال (RTO). وفي أنفاق VPN المشفرة، يؤدي هذا إلى تجميد مكالمات الفيديو وحدوث قفزات مفاجئة في زمن استجابة الألعاب بمئات الأجزاء من الثانية.

التشريح الرياضي لمعيار RFC 6937: آليات خفض المعدل التناسبي

يستبدل معيار RFC 6937 فترات التوقف التام بآلية توزيع متناسقة ومستمرة للحزم. وبدلاً من الانتظار السلبي حتى يتلاشى حجم FlightSize، تتيح خوارزمية PRR إرسال حزم جديدة مع كل إشعار وصول اختياري (SACK) وارد، مما يجعل وتيرة الإرسال تتقارب تدريجياً وبسلاسة نحو ssthresh طوال فترة التعافي.

تعتمد الخوارزمية على متغيرين أساسيين للحالة:

• prr_delivered: إجمالي البيانات المستلمة بنجاح والتي تم تأكيدها عبر كتل SACK منذ بدء التعافي.
• prr_out: إجمالي البيانات الجديدة أو المعاد إرسالها التي تم ضخها في الشبكة منذ اكتشاف الفقد.

تحسب خوارزمية PRR حجم البيانات المسموح بإرسالها عند وصول كل إشعار وفق معادلة تناسبية محددة:

Target_Ratio = ssthresh / RecoverFS
sndcnt = ceil(prr_delivered * Target_Ratio) - prr_out

حيث تمثل RecoverFS حجم البيانات العالقة في اللحظة التي تم فيها رصد فقدان الحزم. وإذا كانت ssthresh تساوي نصف RecoverFS، فإن النسبة المستهدفة تكون Target_Ratio = 0.5. ويعني هذا أنه مقابل كل بايتين يتم تأكيد وصولهما، يرسل المصدر بافتاً واحداً من البيانات فوراً. وبذلك لا يتوقف التدفق أبداً، وتفرغ طوابير الانتظار بوتيرة متوقعة وثابتة مع الحفاظ على مسار النقل ممتلئاً بانتظام.

ديناميكيات الحدود التشغيلية: مقارنة بين وضعي التشغيل PRR-CRB و PRR-SSRB

على الرغم من أن الصيغة التناسبية تعمل بكفاءة عالية في الظروف المعتادة، إلا أن بيئات التشغيل الواقعية تشهد تفاوتاً في وصول إشعارات ACK، وفقداناً للحزم المعاد إرسالها، واختلالاً في ترتيب الحزم. ولضمان الاستقرار، يحدد معيار RFC 6937 نمطين حديين متكاملين: نمط الحد المحافظ (CRB) ونمط حد البدء البطيء (SSRB).

+-------------------------------------------------------------+
|                 معالجة إشعار ACK في مكدس الشبكة             |
+-------------------------------------------------------------+
                               |
                               v
             [هل حجم البيانات العالقة أكبر من ssthresh؟]
                /                                              نعم                               لا
              /                                                v                                     v
+---------------------------+  +------------------------------+
|     نمط PRR أو CRB        |  |          نمط PRR-SSRB        |
| sndcnt = min(PRR, Deliv)  |  | sndcnt = min(Deliv+1, Target)|
+---------------------------+  +------------------------------+

الحد الأدنى المحافظ للمعدل (CRB) لسيناريوهات الفقدان الحاد واختلال الترتيب

عندما تتفاقم معدلات الفقد أو تتأخر إشعارات التأكيد، قد يظل FlightSize أعلى بكثير من عتبة ssthresh. وفي هذه الحالة، فإن الإرسال السريع قد يفاقم الاختناق. يعمل نمط PRR-CRB كصمام أمان وقائي:

sndcnt = min(sndcnt, Delivered_Data)

يضمن نمط PRR-CRB عدم تجاوز حجم البيانات المرسلة لحجم البيانات المؤكد تسليمها في إشعار ACK الحالي. ومن خلال مواءمة وتيرة الإرسال مع معدل مغادرة البيانات الفعلي للمسار، يمنع نمط CRB تراكم الطوابير ويحمي الاتصال من اضطرابات اختلال الترتيب.

حد خفض البدء البطيء (SSRB) لحركات المرور التفاعلية الحساسة لزمن الاستجابة

على العكس من حالات الفقد الواسع، قد تؤدي بعض حالات الفقد المؤقتة إلى هبوط FlightSize إلى ما دون عتبة ssthresh (كما هو الحال عند سقوط حزم متزامنة أو أثناء الانتقال بين أبراج الاتصال الخلوي). في بروتوكول TCP الكلاسيكي، كان انخفاض النافذة المفرط يفرض فحصاً بطيئاً بحزمة واحدة، مما يطيل وقت التعافي.

يتعرف نمط PRR-SSRB على حالة FlightSize < ssthresh ويتيح تسارعاً تدريجياً خاضعاً للرقابة:

sndcnt = min(prr_delivered - prr_out + ssthresh - FlightSize, Max_Burst)

يسمح نمط SSRB بإرسال ما يصل إلى حزمتين مقابل كل حزمة مؤكدة، مما يسهم في إعادة بناء حجم البيانات العالقة حتى يبلغ ssthresh دون إحداث تدفقات عشوائية. وتثبت هذه الآلية فاعليتها القصوى لجلسات SSH والاتصال المرئي والألعاب التفاعلية عبر VPN.

تزامن حجم البيانات العالقة وحجم نافذة الازدحام: إزالة التدفقات المفاجئة والفقد الطرفي

كانت النماذج القديمة للتعافي السريع تعدل قيمة CWND مباشرة أثناء معالجة الفقد، مما يتسبب في تدفقات عشوائية للحزم عند الخروج من حالة التعافي. يفصل معيار RFC 6937 حساب حصة الإرسال sndcnt عن التعديل المباشر لقيمة CWND:

بفضل المزامنة الدقيقة لـ FlightSize، يتطابق حجم البيانات العالقة تماماً مع ssthresh عند نهاية دورة التعافي. ويعود الاتصال إلى مرحلة تجنب الازدحام بسلاسة بالغة، مما يقضي على الفقد الطرفي نهائياً.

التكامل المشترك بين SACK و FACK و PRR في مكدسات شبكات لينكس الحديثة

في نواة لينكس، تعمل خوارزمية PRR كمحرك تعافٍ أساسي تستند إليه كافة خوارزميات التحكم في الازدحام. ويعتمد معيار RFC 6937 على إشعارات الوصول الاختيارية (SACK, RFC 2018 / RFC 6675) لحساب حجم البيانات التي غادرت المسار بدقة متناهية.

وعند دمج آلية FACK (Forward Acknowledgment) مع SACK، ترسم النواة خريطة واضحة للفجوات في أرقام التسلسل، مما يساعد PRR في التمييز بين الفقد الموضعي والانهيار الواسع في النقل. تحسب الخوارزمية متغير prr_delivered بالاعتماد على كتل SACK، وتزود مجدول الطوابير العادلة (sch_fq) بتعليمات توقيت دقيقة للغاية.

مصائد التغليف: سلوك بروتوكول PRR داخل أنفاق WireGuard و IPsec

يثير تطبيق PRR داخل بيئات VPN تفاعلات مهمة بين حركة مرور البيانات الداخلية وغلاف النفق الخارجي المشفر. فعندما تنقل التطبيقات بياناتها عبر WireGuard أو IPsec أو OpenVPN، تُغلّف حزم TCP الأصلية داخل حزم UDP أو ترويسات ESP.

تجزئة MTU الخارجي وتضخيم الفقدان العابر للحزم

إذا تعطلت آلية اكتشاف حجم الحزمة الأقصى (PMTUD) أو كانت الشبكات الوسيطة تقيد MTU دون 1500 بايت، فقد تؤدي حزم TCP الداخلية إلى تجزئة حزم IP الخارجية. ويتسبب فقدان جزء خارجي واحد في تلف حزمة TCP الداخلية بأكملها:

• قد يؤدي فقدان 2% من الأجزاء الخارجية إلى فقدان مضاعف يتراوح بين 4% و 8% في حزم TCP.
• تتدهور الأنظمة القديمة في هذه البيئات لتسقط في سلسلة من مهلات إعادة الإرسال RTO.
• تخفف PRR من هذه المشكلة بالحفاظ على وتيرة إرسال منتظمة تمنع تراكم الطوابير في بوابات VPN وتحد من التجزئة.

التفاعل المشترك مع محركات التحكم في الازدحام BBR و CUBIC و Reno

تعمل PRR كطبقة تنفيذية متناغمة أسفل خوارزميات التحكم في الازدحام:

• CUBIC: تعتمد نواة لينكس خوارزمية CUBIC مدمجة افتراضياً مع PRR. فعندما تخفض CUBIC نافذتها بنسبة 30% ($eta = 0.7$)، تضبط PRR وتيرة الإرسال بنسبة Target_Ratio = 0.7 لتأمين استعادة انسيابية.
• BBR: مع أن BBR تبني نموذجاً مباشراً لسعة القناة، إلا أن إصداراتها تطبق مبادئ التوزيع التناسبي المأخوذة من PRR أثناء تفريغ الطوابير للحد من الضغط الزائد.
• Reno: عند استخدام خوارزمية Reno التقليدية، تتيح PRR خفض المعدل إلى النصف دون التعرض لحالات التجمد الشائعة في الأنظمة القديمة.

مؤشرات القياس المعيارية: توزيع زمن الاستجابة وكفاءة تفريغ طوابير الانتظار

تظهر الاختبارات المعيارية في البيئات التشغيلية تفوقاً حاسماً لخوارزمية PRR على آليات التعافي الكلاسيكية:

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

بنية ضبط التوزيع في RiceGuard: نقل متعدد المسارات بانحراف تأخير منخفض

تدمج خدمة VPNRice مبادئ PRR مباشرة ضمن البنية التحتية المتطورة RiceGuard. وتتعامل بوابات RiceGuard مع آلاف الاتصالات المتزامنة عبر عقد Anycast الموزعة عالمياً.

ولضمان أداء مستقر في الألعاب التفاعلية والبث المباشر والعمل عن بُعد، تطور RiceGuard آليات التعافي على مستويات متعددة:

1. ضبط وتيرة PRR على مستوى النواة: تعمل خوادم RiceGuard بنواة لينكس متقدمة تدمج خوارزمية PRR ومجدول الطوابير العادلة (fq)، لضمان عدم توقف المسار بسبب فقدان الحزم لدى المشترك.
2. ضبط السعة وتقييد MSS: تحسب المنظومة تقييد MSS تلقائياً عند حدود الأنفاق، مما يمنع التجزئة الخارجية التي تشوه حسابات الحزم المسلمة.
3. توقيت مستمر لإشعارات الوصول: بالحفاظ على وتيرة إرسال متناسبة عند حدوث الفقد، تتجنب RiceGuard حالات التجميد اللحظي الشائعة في خدمات VPN التقليدية.

تضمن هذه البنية عدم تأثر جودة الاتصال بالتقلبات العارضة على شبكات الجيل الرابع والخامس أو شبكات Wi-Fi العامة.

دليل الضبط في بيئة التشغيل: معلمات النواة وتحسين سعة طوابير الأنفاق

يمكن لمهندسي الشبكات التحقق من كفاءة بروتوكول PRR وضبطه على خوادم لينكس عبر المعلمات المعيارية:

• التحقق من دعم النواة لـ PRR: التأكد من تفعيل PRR في النواة (مفعل افتراضياً في لينكس 3.2 فما فوق). مراجعة ملف /proc/sys/net/ipv4/tcp_congestion_control والتحقق من عمل SACK (net.ipv4.tcp_sack = 1).
• تفعيل جدولة الطوابير العادلة: تشغيل مجدول FQ لفرض التوزيع على مستوى العتاد: sysctl -w net.core.default_qdisc = fq.
• ضبط MTU وتقييد MSS: تفعيل تقييد MSS على واجهات الأنفاق (iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu) لمنع التجزئة الخارجية.
• مراقبة عدادات التعافي: فحص عدادات تعافي TCP في الوقت الفعلي عبر الأمرين nstat -az TcpPrr* و ss -tie لتتبع سلوك prr_delivered و prr_out.
• الحد من تضخم الطوابير: ضبط الحجم الأقصى لذاكرة كتابة المقابس (net.ipv4.tcp_wmem) لتفادي التراكم الزائد للبيانات قبل حدوث حالات الفقد.