هل يسرّع BBR نفق WireGuard؟ الحقيقة عن TCP وUDP

تقرأ في منتدى أن تفعيل BBR يضاعف سرعة VPN. تنفذ سطرين، فلا يتغير شيء في نفقك. ثم تجد شخصاً آخر يقسم أن سرعته تضاعفت فعلاً. كلاهما قد يكون صادقاً، لكنهما يقيسان شيئين مختلفين.

الجواب القصير: BBR لا يسرّع WireGuard مباشرة، لأن WireGuard يعمل على UDP، وBBR خوارزمية خاصة بـTCP. أما الجواب الكامل ففيه تفاصيل تستحق المعرفة، لأنها تحدد متى يفيدك BBR فعلاً.

ما هو BBR؟

BBR خوارزمية للتحكم في الازدحام طورتها Google لبروتوكول TCP. وظيفتها أن تقرر بأي سرعة يرسل الطرف بياناته.

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

ولهذا يتميز BBR على المسارات التي فيها فقد، خصوصاً مع زمن وصول كبير.

لماذا لا يؤثر في WireGuard مباشرة؟

يأخذ WireGuard كل حزمة ويغلّفها مشفرة داخل حزمة UDP. وUDP لا يعرف الازدحام، ولا يعيد الإرسال، ولا يملك نافذة ترتفع وتنخفض. فليس فيه شيء يتحكم به BBR.

لكن ماذا عن اتصالات TCP داخل النفق؟ هذه نقطة الخلط. فالتحكم في الازدحام يحدث عند طرفي اتصال TCP، أي الجهاز المرسل، وليس الموجّهات في الطريق. وسيرفر WireGuard هنا موجّه يمرر الحزم فقط.

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

وماذا أظهرت قياساتنا؟

على أحد سيرفراتنا، قسنا الرفع عبر Ookla باستخدام TCP، وعلى منفذ بحد policer:

فرق كبير، لكن اقرأه بدقة. هذا قياس TCP على المنفذ، وليس قياساً لنفق WireGuard. وسبب الفرق مرتبط بطبيعة الـpolicer نفسه.

يرمي الـpolicer كل ما يتجاوز الحد فوراً. فيرى CUBIC هذا الفقد على أنه ازدحام ويتراجع بقوة، ثم يعود ببطء. فيبقى متوسط السرعة بعيداً عن الحد. أما BBR فلا ينهار أمام الفقد بالطريقة نفسها، فيبقى قريباً من السرعة المتاحة.

أما النفق نفسه، فقد أعطى في قياس آخر تنزيلاً قدره 57MB/s. ولا ننسب هذا الرقم إلى BBR. فهو يعود إلى قدرة المعالج على التشفير، وإلى سعة المنفذ.

لماذا يرى بعض الناس تحسناً في VPN إذن؟

لأن ما يسمونه VPN قد لا يكون نفق UDP نقياً. وهناك تفسيرات شائعة لما يرونه:

• يعمل على السيرفر بروكسي ينهي اتصال TCP، فيتحكم BBR في الجزء الخارج منه.
• قاسوا السرعة من السيرفر نفسه، لا عبر النفق.
• فعّلوا BBR على السيرفر الذي يرسل الملفات، لا على سيرفر النفق.
• أجروا القياسين في وقتين مختلفين، فتغيرت حالة الشبكة.

والسبب الأخير أكثرها إهمالاً. فقياس قبل التفعيل صباحاً وبعده ليلاً لا يثبت شيئاً. الطريقة الصحيحة هي جولات متناوبة في الفترة نفسها.

TCP داخل UDP: ماذا يحدث عند الفقد؟

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

كيف تفعّله إن كان يفيدك؟

إن كان سيرفرك يرسل TCP بنفسه، فالتفعيل سهل على لينكس الحديث:

cat > /etc/sysctl.d/90-bbr.conf <<'EOF'
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr
EOF

modprobe tcp_bbr
sysctl --system

# التحقق
sysctl net.ipv4.tcp_available_congestion_control
sysctl net.ipv4.tcp_congestion_control

ويؤثر الإعداد في الاتصالات الجديدة، لا في القائمة. ولكي تتأكد من اتصال فعلي، استعمل:

ss -ti | grep -m3 -o -w bbr

وإذا كنت تستعمل Proxmox، فتذكر أن كل VM لها نواة وإعداد مستقل. فتفعيله على العقدة لا يغيّر سلوك TCP داخل الضيف.

وهل يعالج الـshaper مشكلة الـpolicer؟

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

جرّبنا ذلك بـcake عند 465Mbps على 3 جولات متناوبة. لم نجد فرقاً واضحاً، فلم نعتمده. ولا يعني هذا أن الفكرة خاطئة في كل مكان، لكنها لم تعطِ فائدة قابلة للقياس في حالتنا. إن أردت التجربة، فهذا هو الأمر، واختبره بجولات متناوبة:

# استبدل eth0 باسم البطاقة الخارجية
tc qdisc replace dev eth0 root cake bandwidth 465mbit

# العودة إلى الوضع السابق
tc qdisc del dev eth0 root

ومتى لا تحتاج إلى BBR أصلاً؟

على مسار نظيف بلا فقد ولا حد قاسٍ، قد لا تلاحظ فرقاً كبيراً. وعلى الروابط المشتركة، راقب أثره في بقية الحركة، فالخوارزميات لا تتقاسم الرابط دائماً بالتساوي. والقاعدة كما في كل إعداد: فعّله، ثم قس، ثم قرر.

ما الذي يسرّع WireGuard فعلاً؟

• معالج قوي. التشفير يحدث عليه، وعلى VM تأكد أن تعليمات المعالج متاحة للضيف بـcpu host.
• MTU صحيح. الحزم المفقودة بسبب الحجم تقتل الأداء.
• منفذ وحد مناسبان. لا يتجاوز النفق سرعة الرابط.
• إعداد الأطراف. BBR مفيد عند السيرفر الذي يرسل البيانات عبر النفق.

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

سؤال أخير قبل أي تعديل

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

الخلاصة

BBR مفيد جداً لـTCP، خصوصاً مع منفذ يفرض policer، وقد رأينا ذلك في الأرقام. لكنه لا يسرّع WireGuard مباشرة. فعّله حيث يرسل السيرفر TCP بنفسه، ولا تنتظر منه أن يغيّر نفق UDP.

وإن أردت سيرفراً يخدم TCP وVPN معاً بأداء ثابت، ففريق مرام هوست يساعدك في اختيار المعالج والمنفذ المناسبين لعملك. وتتوفر لدينا خيارات منافذ بسرعات أعلى تصل إلى 100 جيجابت حسب التوفر والموقع، ونؤكد التفاصيل قبل الطلب.