‏BBR ولماذا يعتبر مهماً لتحسين أداء خوادم VPN وVPS على Proxmox

1. مقدمة: لماذا لا تعني «1 جيجابت» أنك ستحصل على جيجابت؟

من أكثر ما نسمعه في الدعم الفني: «الباقة تقول 1Gbps لكن الاختبار يعطيني أقل بكثير». والسبب أن سعة المنفذ رقم واحد فقط في معادلة طويلة. ما يصل فعلاً إلى المستخدم يتأثر بـ:

• زمن الوصول (Latency) — كلما بعُدت المسافة احتاج بروتوكول TCP وقتاً أطول ليملأ الأنبوب.
• فقد الحزم (Packet Loss) — حتى نسبة ضئيلة تُسقِط الأداء بشكل حاد مع بعض الخوارزميات.
• التوجيه (Routing) والتبادل (Peering) — مسار طويل أو مزدحم يضيف زمناً وفقداً.
• خوارزمية التحكم بالازدحام (TCP Congestion Control) — وهي موضوع هذا المقال.
• ضغط المعالج والشبكة على المضيف أو الجهاز الافتراضي نفسه.

‏BBR يعالج البند الرابع فقط. ولهذا فهم ما يفعله — وما لا يفعله — يوفّر عليك ساعات من البحث في المكان الخطأ.

2. ما هو TCP Congestion Control؟

‏TCP لا يعرف سعة الطريق مسبقاً، فيجتهد في تقديرها. وخوارزمية التحكم بالازدحام هي القواعد التي تقرر كم بايتاً يُرسَل قبل انتظار الإشعار، ومتى يُسرَّع ومتى يُبطَّأ.

‏CUBIC هو الافتراضي في معظم توزيعات لينكس. منطقه قائم على الفقد: يرفع معدّل الإرسال تدريجياً حتى تضيع حزمة، فيعتبرها إشارة ازدحام ويخفض النافذة بحدّة.

هذا المنطق كان ممتازاً في شبكات التسعينيات حيث الفقد يعني ازدحاماً فعلاً. لكنه يصبح مشكلة على المسارات الطويلة الحديثة، حيث قد تضيع حزمة لأسباب لا علاقة لها بالازدحام — فيعاقب CUBIC نفسه بلا سبب.

3. ما هو Google BBR؟

‏BBR اختصار لـBottleneck Bandwidth and Round-trip propagation time، أي «سعة عنق الزجاجة وزمن الانتشار ذهاباً وإياباً». طوّرته جوجل واندمج في نواة لينكس منذ الإصدار 4.9.

الفكرة أنه لا ينتظر ضياع حزمة ليتعلّم، بل يقيس باستمرار أمرين:

• السعة الفعلية لأضيق نقطة في المسار.
• أقل زمن ذهاب وعودة مُشاهَد — وهو تقدير للمسار بلا طوابير.

ثم يضبط معدّل الإرسال ليطابق السعة المقيسة دون إغراق الطوابير. النتيجة أن فقد حزمة عابر لا يجعله ينهار، لأنه لا يعتبر الفقد وحده دليل ازدحام.

4. لماذا BBR مهم لخدمات VPN وVPS؟

لأن هذه الخدمات تعمل غالباً على مسارات طويلة، وهناك يظهر الفرق:

• استقرار أكبر لجلسات TCP بدل تذبذب حاد بين السرعة والبطء.
• استفادة أفضل من الباندويث المتاح على المسارات ذات الزمن المرتفع.
• تقليل أثر الفقد البسيط — وهذا أوضح مكسب كما سنرى بالأرقام.
• تقليل امتلاء الطوابير (Bufferbloat) في بعض الحالات، خصوصاً مع fq.
• تحسّن ملموس في الرفع والتنزيل حين يكون المسار غير نظيف.
• تجربة أفضل لجلسات SSH وSFTP وHTTP وHTTPS لأنها كلها فوق TCP.

وهذا يخصّ مباشرة من يخدم مستخدمين في الشرق الأوسط من سيرفرات في بريطانيا وأوروبا، حيث زمن الوصول المعتاد بين 70 و100 ملّي ثانية.

5. مثال عملي: شركة استضافة في بريطانيا وزبائن في العراق

لنفترض Proxmox في بريطانيا، وزبائن في العراق وسوريا والأردن، وأحدهم على VPS محدود بسرعة 320 ميجابت.

‏BBR لن يجعل هذا العميل يتجاوز 320 ميجابت. الحدّ الذي يضعه مدير السيرفر يبقى حدّاً. ما قد يتغيّر هو مدى ثبات وصوله إلى ذلك السقف: بدل منحنى متذبذب يصعد وينهار مع كل حزمة ضائعة، يصبح المنحنى أقرب إلى خط مستقرّ.

وهذا الفرق يظهر في تجربة الاستخدام قبل أن يظهر في رقم الاختبار: تحميل ملف لا يتوقف في المنتصف، وجلسة SSH لا تتجمّد، ونقل قاعدة بيانات ينتهي في وقت متوقَّع.

6. القياس الحقيقي: متى يفيد BBR ومتى لا يفيد؟

بدل الاكتفاء بالنظرية، أجرينا قياساً في مختبر معزول: زمن ذهاب وعودة 90 ملّي ثانية (قريب من مسار العراق إلى بريطانيا)، سعة 1 جيجابت، جدول واحد، مع حقن نسب فقد متدرجة.

الخلاصة التي نخرج بها: ‏BBR تأمين ضد الفقد لا زيادة في السقف. على مسار نظيف غير مزدحم قد يعطي أقل من CUBIC بنحو 5%. وكلما ظهر فقد ولو بنسبة عُشر بالمئة، انقلبت المعادلة لصالحه.

وأجرينا اختباراً ثانياً من سيرفر إنتاج إلى شبكة عراقية عبر أداة قياس تجارية، فكانت النتيجة صفر فرق بين الخوارزميتين — لأن المسار كان مشبعاً عند سقف المنفذ وبلا فقد تقريباً. أي أن الأداة كانت تملأ المنفذ بأي خوارزمية.

هذان القياسان معاً يرسمان القاعدة العملية: ابحث عن الفقد أولاً. إن لم يكن في مسارك فقد، فلا تتوقع من BBR معجزة.

7. ‏VPN وUDP: تفريق ضروري

هذه النقطة يُساء فهمها كثيراً، فلنكن دقيقين:

‏BBR هو خوارزمية تحكم بازدحام TCP. وبالتالي فهو لا يسرّع بروتوكولات UDP مباشرة، ومنها:

• WireGuard
• QUIC وHTTP/3
• OpenVPN في وضع UDP

فمن يقول إن «‏BBR يسرّع WireGuard» يخلط بين طبقتين مختلفتين. WireGuard يحمل حزمه فوق UDP، ولا يمرّ بستاك TCP الذي يعمل عليه BBR.

8. أين تُفعِّل BBR في بيئة Proxmox؟

لنأخذ المسار المعتاد:

Internet
   ↓
Proxmox Server
   ↓
Linux VM
   ↓
Customer Traffic

• على Proxmox Server: يفيد ترافيك المضيف نفسه — SSH، النسخ الاحتياطي، التحديثات، الترحيل.
• لكن إذا كان المضيف يعمل هايبرفايزر وجسر (Linux Bridge) فقط، فهو يمرّر إطارات الطبقة الثانية ولا ينهي جلسات الضيوف ⇒ ‏BBR عليه لا يتحكم تلقائياً بترافيك الأجهزة الافتراضية.
• المكان الأهم هو داخل الـLinux VM التي تستضيف الخدمة وتنتهي عليها الجلسات: خادم الويب، الوكيل، خدمة الـVPN.
• الاستثناء: إذا كان Proxmox نفسه يقدّم وكيلاً أو VPN على TCP أو خدمات TCP مباشرة، فتفعيله عليه مفيد أيضاً.

9. ‏BBR وحده لا يكفي: تحسين شبكة Proxmox

الخوارزمية عنصر في منظومة. وهذه العناصر تكمّل بعضها:

• ‏VirtIO — كرت شبكة شبه مُحاكى يقلّل حمل المعالج مقارنة بالمحاكاة الكاملة.
• ‏Multiqueue — توزيع معالجة الشبكة على عدة أنوية.
• أداء المعالج — نواة واحدة مشبعة تصير عنق الزجاجة قبل الشبكة.
• الجسر والكرت الفيزيائي — نوعه وتفريغه للمهام.
• ‏MTU — قيمة خاطئة تسبب تجزئة أو حزماً ضائعة صامتة.
• التوجيه — مسار سيئ يفسد كل ما سبق.

10. ‏Multiqueue: مثال عملي

إذا كان الجهاز الافتراضي يملك 8 أنوية وكرت VirtIO، يمكن ضبط:

queues=8

فتوزَّع معالجة الشبكة على ثماني قوائم بدل واحدة، ويستفيد النظام من أكثر من نواة في معالجة المقاطعات.

لاحظ الفرق في الوظيفة: ‏Multiqueue يوزّع الحمل على المعالجات، وBBR يقرر كم يُرسَل ومتى. هما لا يتنافسان بل يعملان في طبقتين مختلفتين.

11. ‏Rate Limit: الحدّ يبقى حدّاً

في Proxmox يُضبَط حدّ سرعة الواجهة هكذا:

rate=40

والقيمة بالميجابايت في الثانية، أي 40 ميجابايت ≈ 320 ميجابت تقريباً.

و‏BBR لا يتجاوز هذا الحدّ إطلاقاً. الحدّ يُطبَّق على مستوى الواجهة في المضيف، وخوارزمية الازدحام تعمل داخل الضيف — فهي ترى الحدّ كأنه سعة المسار وتتكيّف معه.

12. إعداد BBR على Ubuntu وDebian

sudo modprobe tcp_bbr

cat <<EOF | sudo tee /etc/sysctl.d/99-bbr.conf
net.core.default_qdisc=fq
net.ipv4.tcp_congestion_control=bbr
EOF

sudo sysctl --system

ثم التحقق:

sysctl net.ipv4.tcp_congestion_control
sysctl net.core.default_qdisc
lsmod | grep bbr

النتيجة المتوقعة:

net.ipv4.tcp_congestion_control = bbr
net.core.default_qdisc = fq

13. اختبارات الأداء: كيف تقارن بإنصاف

شروط المقارنة العادلة

• نفس الوقت تقريباً — المسارات تتغيّر خلال اليوم.
• نفس عدد الجداول. الاختبار متعدد الجداول يخفي الفرق لأنه يملأ المنفذ بأي خوارزمية.
• جولات متعددة لا جولة واحدة.
• سجّل الفقد والتذبذب مع الإنتاجية — فبلا معرفة الفقد لا تفسير للنتيجة.

14. هل BBR مهم لخدمات VPN؟

نعم، لكن بشرط فهم أين يعمل. خذ السيناريو:

عميل في العراق
   ↓
VPN Server في بريطانيا
   ↓
مواقع وخدمات على الإنترنت

هنا مساران مختلفان:

• من العميل إلى سيرفر الـVPN: إن كان النفق على UDP — كـWireGuard — فلا علاقة لـBBR به.
• من سيرفر الـVPN إلى الإنترنت: هنا يفتح السيرفر جلسات TCP فعلية، وهذه تستفيد من BBR لأنها تنتهي عليه.

وكذلك أي خدمة TCP تعمل على السيرفر نفسه — وكيل، أو واجهة إدارة، أو تطبيق ويب. كلما زاد الزمن والمسافة زادت قيمة التحسين، بشرط وجود فقد يُستفاد من معالجته.

15. الفرق بين مشكلة الباندويث ومشكلة TCP

هذا التفريق يوفّر عليك تشخيصاً خاطئاً. ‏BBR لا يفعل الآتي:

• لا يزيد سعة منفذ الشبكة.
• لا يحوّل 320 ميجابت إلى 1 جيجابت.
• لا يصلح وصلة صاعدة مزدحمة.
• لا يعالج فقداً كبيراً — فوق حدّ معيّن ينهار كل شيء.
• لا يصلح توجيهاً سيئاً.
• لا يحلّ اختناق المعالج.

ما يفعله هو تحسين كيفية استخدام TCP للباندويث المتاح فعلاً — لا أكثر ولا أقل.

16. ‏BBR لا يصلح كل مشاكل الشبكة

قبل أن تفعّله وتنتظر المعجزة، تأكّد أن مشكلتك ليست واحدة من هذه:

• فقد حزم مرتفع (فوق نسب قليلة).
• تبادل (Peering) سيئ مع شبكة العميل.
• وصلة صاعدة مزدحمة في ساعة الذروة.
• قيمة MTU غير صحيحة — شائعة جداً مع الأنفاق.
• اختناق في المعالج أو في كرت الشبكة.
• عقدة Proxmox محمّلة فوق طاقتها.
• ضعف شبكة لاسلكية عند العميل.
• مشاكل لدى مزوّد خدمة الإنترنت أو توجيه غير جيد.

17. أفضل إعداد لخادم VPS أو VPN

جدول المكوّنات ووظائفها

18. أسئلة شائعة

19. الخلاصة

‏BBR من أهم إعدادات تحسين TCP على لينكس، خصوصاً لخدمات الاستضافة والـVPS والوكلاء والـVPN التي تخدم مستخدمين بعيدين جغرافياً. لكنه ليس زرّاً سحرياً: قياساتنا أظهرت أنه قد يعطي أقل بنحو 5% على مسار نظيف، بينما يتفوّق بمضاعفات كبيرة حين يظهر فقد ولو بنسبة عُشر بالمئة.

ولهذا يجب أن يكون جزءاً من إعداد متكامل: BBR مع fq، وVirtIO مع Multiqueue، ومعالج مناسب وكرت جيد وMTU صحيح وتوجيه سليم وباندويث كافٍ.

وقبل أن تغيّر الخوارزمية، قِس أولاً: شغّل mtr لتعرف أين الفقد، وiperf3 بجدول واحد لتعرف السقف الحقيقي. فإن وجدت فقداً فأنت في المكان الصحيح لتفعيل BBR. وإن لم تجد، فالمشكلة في مكان آخر — ولن تحلّها خوارزمية.