على مدى عقود طويلة، كانت الاستجابة الافتراضية للبنية التحتية لشبكة الإنترنت عند تشبع الروابط هي التخلص الإجباري من حزم البيانات (packet drop). وتحت إدارة قوائم الانتظار التقليدية بأسلوب إسقاط الذيل (Drop-Tail) وخوارزميات التحكم في الازدحام المعتمدة على الفقد مثل TCP Reno وCubic، يعلن الموجه عند نقطة الاختناق عن امتلاء الذاكرة المؤقتة عبر إسقاط الحزم الواردة. يستنتج المرسل حدوث اختناق عند غياب إشعارات الاستلام (ACK)، فيخفض نافذة الازدحام (cwnd) إلى النصف ويعيد الإرسال.

ورغم أن حلقة التغذية الراجعة هذه تحمي الشبكة من الانهيار الشامل، إلا أنها تفرض تكاليف تشغيلية باهظة. في التطبيقات التفاعلية — مثل المكالمات الصوتية المباشرة والمؤتمرات المرئية والألعاب التنافسية عبر الإنترنت والمعاملات المالية — يؤدي فقدان الحزم إلى قفزات مفاجئة في زمن الوصول (latency spikes) وتفاوت التوقيت (jitter). وعندما تمر البيانات عبر أنفاق VPN مشفرة (مثل IPsec أو WireGuard)، تتضاعف مشكلات تضخم الذاكرة المؤقتة (bufferbloat) وفقدان الحزم بسبب التغليف الطبقي المتداخل.

ولفصل إشعار الازدحام عن فقدان الحزم، وضعت هيئة IETF المعيار القياسي لإشعار الازدحام الصريح (ECN - Explicit Congestion Notification) في الوثيقة RFC 3168، ثم حددت آليات نقله عبر الأنفاق بدقة في الوثيقة RFC 6040. واستناداً إلى هذه الأسس، يوفر إطار L4S الحديث (كمون منخفض، فقدان شبه معدوم، إنتاجية قابلة للتوسع - الموثق في RFC 9330 وRFC 9331 وRFC 9332) نظام إدارة قوائم الانتظار المزدوجة المقترنة DualQ Coupled AQM، مما يتيح خفض كمون الانتظار إلى أقل من ميلي ثانية واحدة عبر المسارات المفتوحة وأنفاق VPN المشفرة على حد سواء.

نموذج فقدان الحزم: لماذا تفشل إدارة Drop-Tail في الشبكات الحديثة

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

في حالة bufferbloat، تتراكم ميغابايتات من الحزم المنتظرة في الموجهات الوسيطة أثناء عمليات النقل الكبيرة، وتظل الحزم عالقة لمئات الميلي ثوانٍ بانتظار الخروج على الخط الفيزيائي. وبالنسبة لحزم UDP التفاعلية التي تتشارك نفس المسار، يدمر هذا التأخير استمرارية البيانات الحية. ويرتفع زمن الذهاب والإياب الفعلي ($RTT$) وفق المعادلة:

$$RTT_{\text{actual}} = RTT_{\text{propagation}} + \frac{Q_{\text{bytes}}}{\text{Bandwidth}}$$

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

بنية ECN: حقل IP ذو البتين والتفاوض في مصافحة TCP (RFC 3168)

تلغي الوثيقة RFC 3168 الحاجة إلى إسقاط الحزم عمداً عبر تضمين إشعار الازدحام الصريح داخل ترويسة IP. ويعيد المعيار استخدام البتّين الأقل أهمية في حقل نوع الخدمة (ToS) في بروتوكول IPv4 وحقل فئة المرور في IPv6:

  0   1   2   3   4   5   6   7
+---+---+---+---+---+---+---+---+
|      DSCP (6 bits)    |  ECN  |
+---+---+---+---+---+---+---+---+

يدعم حقل ECN المكون من بتين أربع حالات تشغيلية محددة:

كود البتات الرمز المعنى البروتوكولي
00 Non-ECT نقل لا يدعم ECN (معالجة تقليدية بإسقاط الحزم)
01 ECT(1) نقل يدعم ECN (مخصص لتدفقات L4S القابلة للتوسع)
10 ECT(0) نقل يدعم ECN (تغذية راجعة كلاسيكية وفق RFC 3168)
11 CE تم رصد ازدحام (Congestion Experienced، يضعه الموجه)

وقبل تفعيل ECN عبر اتصال TCP، يتفاوض الطرفان على دعم الميزة أثناء المصافحة الثلاثية (three-way handshake):

  1. حزمة SYN: يضبط العميل كلاً من علامتي ECE (ECN-Echo) وCWR (Congestion Window Reduced) في ترويسة TCP لاقتراح دعم ECN.
  2. حزمة SYN-ACK: إذا كان الخادم يدعم التقنية، فإنه يرد بتفعيل ECE وإلغاء تفعيل CWR.
  3. حزمة ACK: يكمل العميل المصافحة مع إلغاء تفعيل العلامتين، لتبدأ مرحلة نقل البيانات النشطة باستخدام ECN.
العميل                                                  الخادم
  |--- SYN [ECE=1, CWR=1] ------------------------------->| (اقتراح دعم ECN)
  |<-- SYN-ACK [ECE=1, CWR=0] ----------------------------| (قبول دعم ECN)
  |--- ACK [ECE=0, CWR=0] ------------------------------->| (الاتصال جاهز)
  |                                                       |
  |=== حزمة بيانات [IP: ECT(0)] =========================>| (الموجه يضع علامة CE)
  |<== إشعار استلام [TCP: ECE=1] =========================| (إعادة إرسال تحذير الازدحام)
  |--- حزمة بيانات [TCP: CWR=1, IP: ECT(0)] ------------->| (تأكيد خفض النافذة)

أثناء النقل، يقوم الموجه الوسيط عند مواجهة تراكم في الطابور بإعادة كتابة حقل IP من ECT(0) أو ECT(1) إلى CE (11) بدلاً من تدمير الحزمة. وعند استلام حزمة تحمل علامة CE، يضبط المستلم علامة ECE في إشعارات ACK اللاحقة. يستجيب المرسل بتعديل نافذة الإرسال وإرفاق علامة CWR لتأكيد معالجة التنبيه.

معضلة التغليف النفقي: فقدان العلامات وحالات الثقب الأسود

إذا كانت معايير RFC 3168 واضحة للمسارات المباشرة، فقد تركت غموضاً كبيراً فيما يتعلق بالتغليف النفقي (tunneling). والتغليف هو الركيزة الأساسية للشبكات الخاصة الافتراضية، حيث يتم تغليف حزمة IP الداخلية داخل حزمة نقل خارجية (مثل IPsec ESP أو WireGuard UDP أو GRE).

وعندما تمر حزمة مغلفة عبر موجه وسيط يعاني من الازدحام، يضع الموجه علامة CE (11) على ترويسة IP الخارجية. غير أن معالجة الحزمة عند بوابة الخروج عانت تاريخياً من خللين جوهريين:

  1. عمى ECN (فقدان علامة التحذير): كانت بوابة الخروج تزيل ترويسة IP الخارجية وتمرر الحزمة الداخلية بحالتها الأصلية (ECT(0) أو Not-ECT). وكانت علامة CE تختفي تماماً أثناء فك التغليف، مما يجعل الازدحام يتفاقم حتى فيضان الذاكرة وفقدان الحزم فيزياءً.
  2. النسخ غير المنضبط (الثقب الأسود لـ ECN): كان موجه الدخول ينسخ بتات ECN الداخلية إلى الترويسة الخارجية دون التحقق من دعم البروتوكول الداخلي لها. فإذا غُلفت حزمة لا تدعم ECN (00) بترويسة خارجية وُضعت عليها علامة CE، فإن نسخ CE إلى الداخل يؤدي إلى إرباك الأجهزة القديمة وحدوث أخطاء غير متوقعة.

أدت هذه الإخفاقات الهيكلية إلى قيام العديد من مسؤولي الشبكات بتعطيل ECN داخل بيئات VPN المؤسسية في الماضي.

مواصفات RFC 6040: وضع Normal ووضع Compatibility وفك التغليف عند الخروج

حسمت الوثيقة RFC 6040 هذه الإشكالية بوضع قواعد صارمة ومحايدة لنوع البروتوكول المستخدم للتعامل مع ECN عند الدخول (Ingress) والخروج (Egress).

قواعد التغليف عند الدخول: مطابقة ECT الداخلي مع الترويسة الخارجية

عند نقطة الدخول إلى النفق، يحدد جهاز التغليف حالة ترويسة IP الخارجية استناداً إلى الحزمة الداخلية ووضع التشغيل:

  • الوضع العادي (Normal Mode - الافتراضي في RFC 6040): إذا كانت الحزمة الداخلية Not-ECT (00)، يجب ضبط الترويسة الخارجية بصورة حتمية على Not-ECT (00). وهذا يضمن قيام الموجهات اللاحقة بإسقاط الحزمة عند حدوث ازدحام شديد، لأن الطرف النهائي لا يستطيع تفسير إشارة CE. وإذا كانت الحزمة الداخلية تحمل ECT(0) أو ECT(1) أو CE، فإن الترويسة الخارجية تعكس القيمة بدقة.
  • وضع التوافق (Compatibility Mode): يُستخدم عندما يتعذر التحقق من توافق بوابة الخروج مع RFC 6040، حيث تُضبط الترويسة الخارجية على Not-ECT (00) لجميع الحزم، مما يجبر الشبكة على الاعتماد على آليات الإسقاط التقليدية.

جدول فك التغليف عند الخروج: دمج CE الخارجي مع الحالة الداخلية

عند بوابة خروج النفق، يدمج جهاز فك التغليف رموز ECN الخارجية والداخلية قبل تجريد الغلاف الخارجي وفق جدول الحقيقة التالي:

الترويسة الداخلية الترويسة الخارجية ترويسة الإرسال الناتجة الإجراء والتقييم البروتوكولي
Not-ECT (00) Not-ECT (00) Not-ECT (00) توصيل قياسي للحزمة
Not-ECT (00) ECT(0) / ECT(1) Not-ECT (00) حالة خطأ: ترويسة خارجية تحمل ECT بشكل غير سليم
Not-ECT (00) CE (11) إسقاط الحزمة (DROP) إسقاط إلزامي: المسار الخارجي مزدحم والداخلي لا يفهم CE
ECT(0) (10) Not-ECT (00) ECT(0) (10) توصيل قياسي: المسار الخارجي سليم
ECT(0) (10) ECT(0) (10) ECT(0) (10) عبور سليم بدون اختناقات
ECT(0) (10) CE (11) CE (11) تمرير علامة الازدحام إلى البروتوكول الداخلي
ECT(1) (01) CE (11) CE (11) تمرير علامة الازدحام إلى البروتوكول الداخلي
CE (11) Not-ECT (00) CE (11) الاحتفاظ بعلامة الازدحام الداخلية السابقة
CE (11) CE (11) CE (11) الاحتفاظ بعلامة الازدحام

وتكمن أهمية الأمان في RFC 6040 في السطر الثالث: إذا كانت الحزمة الداخلية لا تدعم ECN بينما وصلت الترويسة الخارجية بعلامة CE، فإن بوابة الخروج ملزمة بإسقاط الحزمة فوراً. هذا الإسقاط المتعمد يحفز آليات استشعار الفقد لدى المرسل القديم ويمنع التراكم الصامت للحزم في المخازن المؤقتة.

التطور نحو L4S: كمون منخفض وفقدان ضئيل وإنتاجية قابلة للتوسع (RFC 9330)

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

تتجاوز بنية L4S المعيارية في RFC 9330 هذه المقايضة عبر ثلاثة محاور متكاملة:

  1. التحكم القابل للتوسع في الازدحام (TCP Prague / QUIC L4S): يعدل المرسل معدل البث باستمرار عبر تغذية راجعة نسبية عالية التردد. وبدلاً من تقليص النافذة إلى النصف، يستجيب خوارزمية Prague لعلامات CE بتعديلات طفيفة ($O(1)$)، مما يبقي حجم الطابور قريباً من الصفر.
  2. رمز التعريف المخصص (RFC 9331): يستغل L4S القيمة ECT(1) (01) في ترويسة IP لتمكين الموجهات من فرز تدفقات L4S عن حزم ECT(0) وNot-ECT الكلاسيكية.
  3. إدارة قوائم الانتظار المزدوجة المقترنة DualQ Coupled AQM (RFC 9332): تقسم البوابة حركة المرور إلى طابورين منطقيين متوازيين لعزل الحزم الحساسة للتأخير عن التحميلات الكبيرة مع الحفاظ على التوزيع العادل للنطاق.
تدفق حزم IP الواردة
       |
       v
+-----------------------+
| المصنف (RFC 9331)     |
+-----------------------+
       |               |
       | [ECT(1)]      | [Not-ECT, ECT(0)]
       v               v
+-------------+ +---------------+
| طابور L     | |   طابور C     |
| (طابور ضحل, | | (مخزن عميق,   |
|  تعليم فوري)| |  AQM تقليدي)  |
+-------------+ +---------------+
       \               /
        \             /
         v           v
+-------------------------------+
| المجدول المقترن (RFC 9332)    |
+-------------------------------+
                |
                v  خروج بأقصى سرعة (كمون <1 ميلي ثانية)

نظام DualQ Coupled AQM: عزل التدفقات التقليدية وتدفقات Prague (RFC 9332)

تحدد الوثيقة RFC 9332 خوارزمية DualQ Coupled Active Queue Management، التي تسمح للتطبيقات التفاعلية بمشاركة نفس عنق الزجاجة الفيزيائي مع عمليات النقل الضخمة دون أي تأثير سلبي متبادل.

طابور الانتظار التقليدي الأصلي: تعايش خوارزميات FQ-CoDel وPIE

يتعامل الطابور التقليدي (C-Queue) مع حزم Not-ECT وECT(0)، معتمداً على خوارزميات إدارة قوائم انتظار مثبتة الكفاءة مثل PIE أو FQ-CoDel.

يحافظ الطابور C على كمون مستهدف بين 10 و20 ميلي ثانية. وعند حدوث ازدحام، يقوم بإسقاط حزم Not-ECT أو وضع علامة CE على حزم ECT(0) باحتمالية تتناسب مع الجذر التربيعي لوظيفة الازدحام ($p_C$).

طابور الكمون المنخفض: التعليم التدريجي ومخازن أقل من ميلي ثانية

يعالج طابور الكمون المنخفض (L-Queue) حزم ECT(1) حصراً. ونظراً للاستجابة السريعة لخوارزمية Prague، لا يحتاج هذا الطابور إلى ذاكرة مؤقتة عميقة.

يعتمد هذا الطابور على عتبة تعليم تدريجية (Step Marking): فإذا تجاوز زمن الانتظار حداً ضئيلاً (بين 500 ميكروثانية وميلي ثانية واحدة)، يتم تعليم الحزم اللاحقة فوراً بـ CE، ولا تُسقط أي حزمة ما لم تمتلئ الذاكرة الفيزيائية تماماً.

ولضمان عدالة تقسيم السعة بين الطابورين، تربط RFC 9332 احتمالات التعليم بمعادلة مقترنة:

$$p_L = k \times p_C^2$$

ترتبط احتمالية وضع العلامات في طابور L ($p_L$) ديناميكياً بمربع احتمالية الازدحام في طابور C ($p_C$)، مما يكفل حصول تدفقات L4S وTCP Cubic على حصص متكافئة من النطاق بمرور الوقت.

التأثير العملي على الأداء: الألعاب والمحادثات المرئية وأنفاق VPN المشفرة

يحدث التطبيق المشترك لتغليف ECN المتوافق مع RFC 6040 وبنية L4S DualQ AQM تحولاً نوعياً في أداء التطبيقات التفاعلية.

في الألعاب السحابية والبث التفاعلي والأنظمة المالية، يمثل تذبذب زمن الوصول (الجليتر) ضرراً يفوق قيمة التأخير الثابتة. في الأنفاق التقليدية بأسلوب Drop-Tail، يؤدي بدء رفع ملف بسرعة 500 ميغابت/ثانية إلى قفز زمن الاستجابة في اللعبة من 25 ميلي ثانية إلى أكثر من 200 ميلي ثانية بسبب امتلاء المخازن المؤقتة.

ومع اعتماد RFC 6040 ونظام DualQ AQM:

  • كمون الانتظار: ينخفض من 80–250 ميلي ثانية إلى أقل من ميلي ثانية واحدة.
  • معدل فقدان الحزم: يقترب من 0.00% حتى في أوقات الذروة بفضل إشعارات CE.
  • انسداد مقدمة الصف (Head-of-Line): يتلاشى كلياً، مما يضمن تدفق حزم التحكم الصوتي والتفاعلي دون توقف.

وعلاوة على ذلك، يتكامل تضمين ECN في الشبكات الافتراضية مع تقنيات حماية بروتوكولات النقل، بما في ذلك حلول مشكلات تعطل النواة مع TCP SACK، مما يحفظ استقرار ذاكرة المقابس البرمجية تحت الضغط.

بنية RiceGuard: تغليف ECN المتوافق مع RFC 6040 وتوزيع أعباء DualQ

تدمج شبكة VPNRice معايير RFC 6040 وRFC 9330 مباشرة داخل طبقة معالجة البيانات الخاصة بها والمعروفة باسم RiceGuard.

غالباً ما تتجاهل تطبيقات VPN المعتادة ترويسات IP الخارجية أثناء التشفير. فعندما تغلف نواة لينكس الحزم داخل WireGuard UDP أو IPsec ESP، تفشل الإعدادات الافتراضية غالباً في إعادة توجيه علامة CE الخارجية إلى مقبس العميل عند فك التغليف.

[ مساحة المستخدم لدى العميل: TCP Prague / QUIC ]
       |
       | (ترويسة IP الداخلية: كود الحالة ECT(1))
       v
[ محرك نفق العميل في RiceGuard ]
       |
       | التغليف عند الدخول (RFC 6040 الوضع العادي)
       | نسخ رمز ECT(1) بالكامل إلى ترويسة UDP/IP الخارجية
       v
[ مسار مزود الخدمة العام مع نقطة اختناق DualQ ]
       |
       | رصد الازدحام: الموجه يضع علامة CE (11)
       v
[ بوابة RiceGuard الطرفية (مركز فك التغليف) ]
       |
       | جدول دمج الخروج RFC 6040:
       | خارجي=CE + داخلي=ECT(1) ---> تمرير الحزمة الداخلية بعلامة CE (11)
       v
[ الخادم الهدف / البنية التحتية السحابية ]
       |
       | تعديل دقيق للسرعة: كمون إضافي في المخازن = 0 ميلي ثانية

داخل معمارية RiceGuard الأساسية:

  • معالجة صارمة لبيانات الدخول والخروج وفق RFC 6040: يفحص مسار المعالجة المشفر الترويسات الداخلية والخارجية بسرعة العتاد، وعند رصد علامة CE، يتم تحديث الترويسة الداخلية فوراً قبل التوجيه.
  • توزيع الأحمال عتادياً عبر DualQ: في العقد الطرفية لـ VPNRice، تُفرز البيانات الواردة إلى طوابير DualQ الفيزيائية عبر مرشحات eBPF/XDP، لتسلك حزم UDP التفاعلية والبيانات الموسومة بـ L4S مسارات معالجة مخصصة بعيداً عن تدفقات التحميل الكبيرة.
  • تكامل مع قياس MTU للمسار: يتم إنشاء أغلفة الأنفاق مع ضبط ديناميكي لمعامل MSS لمنع تفتت الحزم وإتلاف علامات ECN.

قائمة المراجعة الهندسية: تهيئة ECN وL4S في أنوية لينكس وبوابات VPN

لنشر والتحقق من دعم RFC 6040 وL4S عبر أنظمة لينكس وبوابات VPN، يُرجى اتباع الخطوات التشغيلية التالية:

  • تفعيل ECN على مستوى النظام: عيّن net.ipv4.tcp_ecn = 1 داخل /etc/sysctl.conf لتمكين التفاوض على ECN للاتصالات الصادرة والواردة.
  • التحقق من دعم نواة لينكس لـ L4S: تأكد من أن إصدار النواة 6.4 أو أحدث لدعم خوارزمية TCP Prague ومجدول DualQ AQM (sch_dualpi2).
  • تهيئة خوارزمية طابور DualQ: أضف مجدول DualQ إلى واجهة الشبكة الفعلية وواجهات الأنفاق:
    tc qdisc add dev eth0 root dualpi2
  • تطبيق قواعد RFC 6040 على واجهات WireGuard/IPsec: تأكد من أن برنامج التغليف لا يحذف بتات ECN (sysctl -w net.ipv4.conf.all.rp_filter=2 وفحص خصائص التوجيه).
  • تدقيق حركة المرور أثناء المصافحة: استخدم أداة tcpdump لمراقبة حزم SYN وSYN-ACK وACK والتأكد من تفاوض الطرفين بنجاح على علامتي ECE وCWR:
    tcpdump -i any 'tcp[13] & 0xc0 != 0' -n -vv
  • التحقق من جدول فك التغليف: أرسل حزم اختبار تحمل علامة CE خارجياً للتأكد من انعكاس العلامة على الترويسة الداخلية عند مغادرة واجهة النفق.
  • مراقبة عدادات العلامات وإسقاط الحزم: راقب إحصائيات الواجهات للتأكد من أن حالات الازدحام تُعالج بوضع علامات CE بدلاً من فقدان الحزم:
    tc -s qdisc show dev eth0