يواجه مهندسو الشبكات والتقنيون تحدياً معقداً يتمثل في ظاهرة الهبوط المفاجئ لمعدل نقل البيانات عبر المسارات الدولية الطويلة. يمتلك المستخدم اتصال ألياف ضوئية متماثل بسرعة ١ غيغابت في الثانية، ويتصل بنفق مشفر يربط بين طوكيو وفرانكفورت بزمن انتقال ذهاباً وإياباً Round-Trip Time (RTT) يبلغ ٢٢٠ مللي ثانية. على الرغم من أن الحمل على المعالج CPU لا يتجاوز ٥٪ وسعة النطاق المادي متوفرة بالكامل، إلا أن سرعة تنزيل الملفات عبر جلسة أحادية التدفق Single-Stream تنهار من مئات الميغابت لتصل إلى ما بين ١٢ و١٨ ميغابت في الثانية فقط.

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

لعقود طويلة، اعتمدت البنية التحتية لشبكة الإنترنت على آليات التحكم في الازدحام القائمة على فقدان الحزم (Loss-based Congestion Control). ومع ذلك، داخل أنفاق VPN المشفرة ذات حاصل ضرب سعة النطاق في زمن التأخير Bandwidth-Delay Product (BDP) المرتفع، تنهار هذه الآليات بالكامل. أحدث ظهور خوارزمية TCP BBR (Bottleneck Bandwidth and Round-trip propagation time)، التي طورها فان جاكوبسون ونيل كاردويل وفريق أبحاث الشبكات في Google، ثورة حقيقية عبر استبدال رصد فقدان الحزم بنمذجة دقيقة للخصائص الفيزيائية للمسار.

[ديناميكية خوارزمية CUBIC التقليدية القائمة على فقدان الحزم]
نمو نافذة cwnd ──> امتلاء ذاكرة الموجه ──> فيضان الذاكرة (Tail Drop) ──> فقدان حزمة ──> خفض النافذة (-30%)
                       ▲                                                                        │
                       └───────────────── استعادة بطيئة عبر معادلة تكعيبية ──────────────────────┘
                               النتيجة: تضخم شديد في الذاكرة (Bufferbloat)، تذبذب كبير، وانهيار السرعة

─────────────────────────────────────────────────────────────────────────────────────────────────────────────

[ديناميكية خوارزمية TCP BBR الحديثة القائمة على الخصائص الفيزيائية]
قياس مستمر: سعة النطاق لنقطة الاختناق (BtlBw) وأدنى زمن انتقال فيزيائي (RTprop)
تنظيم تدفق الحزم (Kernel Pacing) وفق السرعة الحقيقية ──> طوابير الموجهات فارغة ──> لا بيانات فائضة
                               النتيجة: استغلال أقصى سعة للمسار، إزالة Bufferbloat، واستقرار زمن الاستجابة

القصور الرياضي في التحكم القائم على الفقد: CUBIC (معيار RFC 9438)

لفهم أسباب تراجع الأداء في الاتصالات بعيدة المدى، يجب تفكيك المنطق الحسابي لخوارزمية TCP CUBIC (المعتمدة في RFC 9438).

وفق قاعدة الزيادة الخطية والإنقاص المضاعف (AIMD)، تفترض CUBIC أن فقدان الحزم هو المؤشر الحصري لحدوث ازدحام في الشبكة. تعمل الخوارزمية على توسيع نافذة الازدحام ($cwnd$) باستمرار لاختبار سعة القناة، حتى تمتلئ ذاكرة التخزين المؤقت للموجهات الوسيطة وتبدأ في إسقاط الحزم (Tail Drop).

عند رصد حزمة مفقودة عبر إشعارات التأكيد المكررة الثلاثية (Triple-Duplicate ACK) أو التأكيد الانتقائي (SACK)، تفرض CUBIC عقوبة تخفيض قاسية:

$$W_{\max} = \text{حجم البيانات أثناء الإرسال (Flight Size)}$$ $$cwnd_{\text{الجديدة}} = W_{\max} \times \beta \quad (\text{حيث } \beta = 0.7)$$

تتقلص نافذة الإرسال فوراً بنسبة ٣٠٪، دون تمييز ما إذا كان الفقد ناجماً عن ازدحام فعلي أو مجرد تشويش لاسلكي عابر عبر شبكات Wi-Fi أو شبكات الجوال.

في عام ١٩٩٧، صاغ ماثيو ماثيس الحد الرياضي النظري لسرعة نقل بيانات TCP القائمة على الفقد في معادلة ماثيس (Mathis Formula):

$$\text{Throughput} \le \frac{\text{MSS}}{\text{RTT}} \times \frac{C}{\sqrt{p}}$$

حيث تمثل $\text{MSS}$ الحجم الأقصى للقطعة Maximum Segment Size، و$\text{RTT}$ زمن الذهاب والإياب، و$p$ احتمال فقدان الحزم، والثابت $C \approx 1.22$.

بالنظر إلى واقع نفق VPN دولي:

  • $\text{RTT} = 160\text{ ms } (0.160\text{ s})$
  • $\text{MSS} = 1380\text{ bytes } (11,040\text{ bits})$
  • معدل الفقد العشوائي الطبيعي عبر شبكات الترانزيت العامة $p = 1% \ (0.01)$:

$$\text{Throughput} \le \frac{11,040}{0.160} \times \frac{1.22}{\sqrt{0.01}} = 69,000 \times 12.2 \approx 841,800\text{ bps} \approx 6.7\text{ Mbps}$$

على الرغم من العمل عبر رابط ألياف ضوئية بسعة ١ غيغابت، فإن فقداناً عشوائياً بنسبة ١٪ فقط يجبر CUBIC على كبح السرعة إلى أقل من ٧ ميغابت في الثانية. ونظراً لأن CUBIC تحتاج إلى دورات عديدة من RTT لاستعادة منحناها التكعيبي، فإن زمن الاستجابة الطويل يحول دون استعادة السرعة قبل وقوع فقدان جديد.

أضرار ظاهرة تضخم الذاكرة الوسيطة (Bufferbloat)

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

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

ينتج عن ذلك تأخير مصطنع ضخم: ١. أثناء نقل ملفات كبيرة في الخلفية، تملأ CUBIC ذاكرة الموجه بنسبة ١٠٠٪. ٢. الحزم الحساسة للتأخير—مثل إشارات الحفاظ على الاتصال WireGuard Keepalive، وجلسات SSH، واستعلامات نظام أسماء النطاقات (DNS)، ومكالمات الصوت عبر الإنترنت (VoIP)—تظل عالقة خلف آلاف الحزم الضخمة. ٣. يرتفع زمن الاستجابة RTT من ٢٥ مللي ثانية إلى أكثر من ٤٠٠ مللي ثانية. ٤. يعاني المستخدم من تذبذب حاد في الاتصال (Packet Jitter) وتقطع في الصوت والصورة.

بنية BBR: التشغيل عند نقطة كلاينروك المثالية

في عام ٢٠١٦، قدم فان جاكوبسون ونيل كاردويل خوارزمية BBR للقضاء على هذا التراجع الهيكلي.

تتخلى BBR تماماً عن اتخاذ فقدان الحزم كإشارة على الازدحام. وبدلاً من ذلك، تتعامل مع الازدحام كحالة فيزيائية تتحدد بمتغيرين مستقلين: ١. سعة نطاق نقطة الاختناق ($\text{BtlBw}$): أقصى سرعة تسليم فعلية لأضعف حلقة في المسار. ٢. أدنى زمن انتقال فيزيائي ($\text{RTprop}$): زمن انتقال الإشارة الضوئية في الألياف دون احتساب وقت الانتظار في الطوابير.

أثبت البروفيسور ليونارد كلاينروك في عام ١٩٧٩ أن نقطة التشغيل المثالية لأي شبكة بيانات تتحقق عندما يتطابق حجم البيانات المتدفقة في المسار (Inflight Data) تماماً مع حاصل ضرب سعة النطاق في زمن التأخير Bandwidth-Delay Product (BDP):

$$\text{BDP} = \text{BtlBw} \times \text{RTprop}$$

التأخير / سعة النطاق
       │                       نقطة كلاينروك المثالية للتشغيل
       │                                     ▼
السرعة ─────────────────────────────┐────────────────────────── (تشبع المسار عند BtlBw)
       │                           ╱│
       │                          ╱ │
       │                         ╱  │
RTT    │                        ╱   │  بدء تراكم الطوابير ────────> (ظهور Bufferbloat!)
       │                       ╱    │  ┌───────────────────────
RTprop الأساسي ───────────────┴─────┴──┴───────────────────────
       └───────────────────────────────────────────────────────
                                 حجم البيانات قيد الإرسال (Inflight)

عند نقطة كلاينروك المثالية:

  • تصل سرعة النقل إلى الحد الأقصى المتاح ($\text{Throughput} = \text{BtlBw}$).
  • يبقى زمن الاستجابة عند أدنى حد فيزيائي ($\text{RTT} = \text{RTprop}$).
  • يكون طول طابور الانتظار في الموجهات صفراً، مما يلغي ظاهرة Bufferbloat تماماً.

تحافظ BBR على هذا التوازن عبر آلة حالات مستمرة:

  • STARTUP: تسارع أسي بمعدل ٢.٨٩ ضعف لاكتشاف أقصى سعة للقناة.
  • DRAIN: خفض مؤقت لمعدل الإرسال لتفريغ أي طوابير تشكلت في مرحلة الانطلاق.
  • PROBE_BW: ضبط دوري لمعدل الإرسال (زيادة بمعدل ١.٢٥ ضعف خلال دورة RTT واحدة لاختبار السعة، ثم ٠.٧٥ ضعف لتفريغ الطابور، ثم تثبيت عند ١.٠ ضعف لست دورات).
  • PROBE_RTT: تقليص البيانات قيد الإرسال إلى ٤ حزم كل ١٠ ثوانٍ لمدة ٢٠٠ مللي ثانية لقياس أدنى زمن انتقال فيزيائي خالص $\text{RTprop}$.

من خلال جدولة تدفق الحزم عبر النواة Kernel Pacing بواسطة خوارزمية Fair Queueing بدلاً من إرسال دفعات عشوائية، تضمن BBR انسياب البيانات بسلاسة.

مسار التطور: من BBRv1 إلى إصدار BBRv3

أظهرت التطبيقات الميدانية للإصدار الأول BBRv1 جانبين استدعيا التطوير: ١. التنافس مع CUBIC: في الذواكر العميقة، تحتل تدفقات CUBIC كامل الطابور، مما حرم BBRv1 أحياناً من حصتها العادلة. ٢. الذواكر الضحلة: عند حدوث فقدان عشوائي مرتفع (أكثر من ١٥٪ إلى ٢٠٪)، حافظت BBRv1 أحياناً على حجم بيانات قيد الإرسال أعلى من المطلوب.

عالجت مجموعة هندسة الإنترنت (IETF) وفريق Google هذه النقاط في BBRv2 والإصدار الحديث BBRv3:

  • دعم إشعار الازدحام الصريح (ECN): تقرأ BBRv3 علامات CE وفق RFC 3168 لتهدئة الإرسال قبل سقوط الحزم.
  • سقف ديناميكي للبيانات قيد الإرسال: خفض معدل التدفق بمرونة بناءً على الفقد الفعلي لضمان مشاركة عادلة (Fair-Share) مع CUBIC.
  • فترات فحص سريعة لـ RTT: تقليص زمن مرحلة PROBE_RTT لتفادي أي انخفاض ملحوظ في السرعة.
المعيار الفني TCP Reno (RFC 5681) TCP CUBIC (RFC 9438) TCP BBRv1 TCP BBRv3
إشارة التحكم فقدان الحزم فقدان الحزم نموذج السرعة والتأخير السرعة، التأخير، الفقد و ECN
آلية الإرسال دفعات متقطعة (Bursts) دفعات متقطعة (Bursts) تنظيم انسيابي (fq) تنظيم انسيابي (fq)
ظاهرة Bufferbloat حادة جداً حادة جداً ضئيلة للغاية منعدمة تماماً
تحمل ١٪ فقدان حزم انهيار (< ٥٪ من السرعة) هبوط (< ١٠٪ من السرعة) ممتاز (+٩٥٪ من السرعة) أقصى كفاءة (+٩٨٪)
استغلال سعة BDP بطيء جداً متوسط فوري فوري ومتكيف
المشاركة العادلة قياسي قياسي قد يتفوق على CUBIC توزيع متوازن (Fair-Share)

تطبيق وضبط BBR في بيئة لينكس

يعد التحكم في الازدحام قراراً يخص الطرفية المرسلة (Endpoint Decision). في شبكات الطبقة الثالثة مثل WireGuard أو RiceGuard، يتم تغليف حزم TCP داخل حزم UDP. ويتحكم تفعيل BBR على الخادم أو البوابة مباشرة في وتيرة إدخال البيانات إلى النفق المشفر.

إعدادات نواة لينكس

لتفعيل BBR، يتم دمج الوحدة مع خوارزمية الجدولة العادلة Fair Queueing (fq):

# استعراض وحدات التحكم في الازدحام المتاحة
sysctl net.ipv4.tcp_available_congestion_control

# تفعيل الجدولة العادلة وتعيين BBR
sudo sysctl -w "net.core.default_qdisc = fq"
sudo sysctl -w "net.ipv4.tcp_congestion_control = bbr"

# ضبط حد البيانات غير المرسلة في المقبس لتفادي التراكم الداخلي
sudo sysctl -w "net.ipv4.tcp_notsent_lowat = 16384"

ولحفظ هذه الإعدادات بشكل دائم، تُضاف إلى ملف /etc/sysctl.d/99-bbr-optimization.conf:

net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr
net.ipv4.tcp_notsent_lowat = 16384
net.ipv4.tcp_rmem = 4096 87380 33554432
net.ipv4.tcp_wmem = 4096 65536 33554432

المعامل tcp_notsent_lowat = 16384 يحدد سقف البيانات المحتجزة داخل المقبس المحلي بـ ١٦ كيلوبايت، مما يمنع نشوء تضخم الذاكرة الداخلي قبل وصول الحزم لبطاقة الشبكة.

مراقبة أداء الاتصال عبر أداة Socket Statistics

يمكن التحقق من مؤشرات عمل BBR اللحظية عبر أداة ss:

# فحص المقاييس الحية لجلسات TCP النشطة
ss -tin '( dport = :443 or sport = :443 )'

يوضح الناتج القياسات المباشرة:

ESTAB 0 0 10.0.0.2:48392 198.51.100.1:443
  bbr:(bw:182.4Mbps,mrtt:158.21,pacing_rate:228.0Mbps,cwnd:240)
  cubic:(...)

تُظهر البيانات المقاسة سعة نقطة الاختناق bw:182.4Mbps، وأدنى زمن استجابة mrtt:158.21 مللي ثانية، وسرعة التنظيم المحسوبة.

تكامل BBR مع بنية VPNRice وبروتوكول RiceGuard

تتطلب الشبكات المشفرة عالية الكفاءة إدارة دقيقة لحركة المرور لمعالجة عيوب الإنترنت العامة. تدمج VPNRice تقنية تنظيم التدفق BBR داخل بروتوكول RiceGuard:

  • تنظيم التدفق عند بوابات Anycast: تشغل عقد Anycast التابعة لـ VPNRice خوارزميات BBR المحدثة على واجهات التوجيه، مما يضمن تدفق البيانات بسلاسة وتفادي تحميل الموجهات الوسيطة فوق طاقتها.
  • الحفاظ على السرعة أثناء الفقدان العشوائي: عند الاتصال عبر شبكات الجوال 4G/5G أو شبكات Wi-Fi المزدحمة، يحافظ RiceGuard على استقرار السرعة ويمنع هبوط الأداء بنسبة ٧٠٪ المعتاد في CUBIC.
  • استقرار زمن الاستجابة في التطبيقات التفاعلية: تفريغ الطوابير بانتظام عند نقطة كلاينروك يمنح تجربة سلسة خالية من التذبذب في ألعاب الفيديو والمحادثات الصوتية والمرئية.