تفعيل BBR: كيف رفعنا سرعة الإرسال من السيرفر إلى العراق بسطرين (تجربة حقيقية)

في الجزء الأول لاحظنا شيئًا غريبًا: السيرفر يستقبل البيانات من الشبكات العراقية بقرابة 900 Mbps، لكنه يرسل إليها بين 297 و455 Mbps فقط، مهما كانت الشبكة. ولأن الإرسال هو الاتجاه الذي يخدم زوار موقعك في العراق، فتّشنا عن السبب. النتيجة كانت مفاجئة: تفعيل BBR، وهو تغيير من سطرين في إعدادات النواة، رفع متوسط سرعة الإرسال إلى العراق بنسبة 82% في تجربتنا، بين 69% و98% حسب الجولة.

لماذا يهمّك «الرفع» تحديدًا؟

في مصطلحات Speedtest، «الرفع» يعني البيانات الخارجة من سيرفرك. وهذا بالضبط ما يحدث حين يفتح زائر عراقي موقعك: الصفحات والصور والفيديو وملفات التحميل كلها تخرج من السيرفر نحو العراق. وكذلك النسخ الاحتياطية التي ترسلها إلى مكتبك، والبثّ المباشر، واتصالات VPN.

لذلك فالسيرفر الذي يستقبل بسرعة 900 ويرسل بسرعة 350 يخدم زواره بالرقم الأصغر. صحيح أن 350 Mbps تكفي أغلب المواقع، لكنها تعني أيضًا أن كل اتصال منفرد (تحميل ملف كبير مثلًا) أبطأ مما يجب.

المشتبه الأول: ذاكرة TCP ومعادلة «الحزمة × الزمن»

كل اتصال TCP يستطيع إرسال كمية محدودة من البيانات قبل أن ينتظر تأكيد الاستلام من الطرف الآخر، وتحدّد هذه الكمية ذاكرة الإرسال (tcp_wmem). على مسار زمنه 90 ms، إن كانت الذاكرة 4 MB فأقصى ما يرسله اتصال واحد:

4 MiB ÷ 0.090 s ≈ 46.6 MB/s ≈ 373 Mbps   (لاتصال واحد)

# والمطلوب لملء بورت 1 Gbps على المسار نفسه:
1 Gbps × 0.090 s = 11.25 MB في الطريق في كل لحظة

القيمة الافتراضية في Ubuntu 24.04 هي 4 MiB بالضبط، والرقم الناتج (373 Mbps) قريب جدًا مما رأيناه. بدا الأمر محسومًا، لكن Speedtest يستعمل عدة اتصالات متوازية، فالذاكرة وحدها لا تفسّر السقف. كان علينا أن نقيس لا أن نخمّن.

المشتبه الثاني: CUBIC مقابل BBR

خوارزمية التحكّم بالازدحام تقرّر بأي سرعة يرسل TCP. الافتراضية في لينكس هي CUBIC، وهي «قائمة على الفقدان»: تزيد السرعة حتى تفقد حزمة، فتعدّ ذلك ازدحامًا وتخفّض السرعة بشدّة، ثم تعاود الصعود ببطء يتناسب مع زمن المسار. على مسار طويل كبريطانيا–العراق، أي فقدان عابر يكلّف ثواني من السرعة المنخفضة.

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

التجربة: أربع إعدادات وخمس شبكات عراقية

أجرينا التجربة على سيرفر VPS تجريبي من مرام في مركز البيانات نفسه، بالشبكة نفسها ونظام Ubuntu 24.04 نفسه، وبورت سرعته 800 Mbps. قسنا الرفع بأداة Speedtest CLI الرسمية إلى خمس شبكات عراقية (نوروز وكورك في أربيل، وإيرثلنك وآسياسيل في بغداد، وزين في البصرة) في أربعة إعدادات:

• A: الافتراضي: CUBIC مع ذاكرة إرسال قصوى 4 MiB.
• B: ذاكرة أكبر: CUBIC مع رفع ذاكرة الإرسال والاستقبال إلى 32 MiB.
• C: BBR فقط: BBR مع مجدول الحزم fq، والذاكرة الافتراضية.
• D: الاثنان معًا: BBR وfq وذاكرة 32 MiB.

كرّرنا التجربة في جولتين بترتيب مختلف (A ثم B ثم C ثم D، ثم C ثم A ثم D) كي لا يكون الفرق بسبب تغيّر الازدحام مع الوقت، وأعدنا الإعدادات الأصلية بعد الانتهاء. في منتصف الجولة الثانية أوقفت Ookla الفحوص مؤقتًا لكثرتها (رسالة Limit reached)، فاكتمل الإعداد D بقياسات الجولة الأولى وقياس واحد من الثانية.

النتائج: BBR هو الفارق الحقيقي

• الذاكرة وحدها لم تكفِ: في الجولة نفسها ارتفع المتوسط من 335 إلى 359 Mbps فقط (+7%).
• BBR وحده هو القفزة: من 310 إلى 564 Mbps في متوسط الجولتين (+82%): +69% في الجولة الأولى و+98% في الثانية، وفي كل شبكة من الخمس دون استثناء.
• BBR مع الذاكرة الكبيرة: 596 Mbps، لكن مقارنته بـBBR وحده على الخوادم نفسها وفي الجولة نفسها لا تُظهر فرقًا يُذكر (-2%). أي أن الذاكرة الإضافية لا تضيف شيئًا فوق BBR في هذا المسار.
• الثبات: مع CUBIC تراوح الرفع بين 121 و402 Mbps، ومع BBR بين 422 و648. BBR ليس أسرع فحسب، بل أقل تأثرًا بتقلّبات المسار.
• التنزيل لم يتغيّر: بقي قرب سقف البورت (نحو 800 Mbps) في كل الإعدادات، لأن BBR يعمل في جهة المرسِل فقط.

كيف تفعّل BBR على سيرفرك (أوبنتو وديبيان وألما لينكس)

الخطوات التالية تعمل على أي توزيعة بنواة 4.9 أو أحدث، ولا تحتاج إعادة تشغيل. نفّذها بمستخدم لديه صلاحيات sudo:

# الخطوة 1: تأكّد من الوضع الحالي
sysctl net.ipv4.tcp_congestion_control      # غالبًا: cubic
sysctl net.ipv4.tcp_available_congestion_control

# الخطوة 2: حمّل وحدة BBR واجعلها تُحمَّل عند الإقلاع
sudo modprobe tcp_bbr
echo tcp_bbr | sudo tee /etc/modules-load.d/bbr.conf

# الخطوة 3: الإعداد الدائم
sudo tee /etc/sysctl.d/90-bbr.conf <<'EOF'
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr
EOF
sudo sysctl --system

# الخطوة 4: طبّق مجدول fq على الواجهة الحالية فورًا، أو أعد التشغيل
IFACE=$(ip route get 1.1.1.1 | awk '{for(i=1;i<=NF;i++) if($i=="dev") print $(i+1)}')
sudo tc qdisc replace dev "$IFACE" root fq

# الخطوة 5: تحقّق
sysctl net.ipv4.tcp_congestion_control      # يجب أن تظهر: bbr
tc qdisc show dev "$IFACE" | head -1        # يجب أن تظهر: qdisc fq

الإعداد يسري على الاتصالات الجديدة فقط، فالاتصالات المفتوحة قبل التفعيل تبقى على CUBIC حتى تُغلق. بعد التفعيل قِس مرة أخرى بالخوادم نفسها كما في الجزء الرابع لتتأكد من الفارق على سيرفرك أنت.

وماذا عن رفع ذاكرة TCP؟ في تجربتنا لم يضف شيئًا يُذكر فوق BBR، لذلك لا ننصح به كخطوة أولى. قد يفيد في سيرفرات تنقل ملفات ضخمة عبر اتصال واحد على مسارات أطول (آسيا أو أمريكا مثلًا). إن أردت تجربته فهذه القيم التي استعملناها:

# اختياري: ذاكرة TCP قصوى 32 MiB
sudo tee /etc/sysctl.d/91-tcp-buffers.conf <<'EOF'
net.core.rmem_max = 33554432
net.core.wmem_max = 33554432
net.ipv4.tcp_rmem = 4096 131072 33554432
net.ipv4.tcp_wmem = 4096 16384 33554432
EOF
sudo sysctl --system

التراجع بسطر واحد

sudo rm /etc/sysctl.d/90-bbr.conf /etc/modules-load.d/bbr.conf
sudo sysctl -w net.ipv4.tcp_congestion_control=cubic net.core.default_qdisc=fq_codel
sudo tc qdisc replace dev "$IFACE" root fq_codel

متى لا يفيدك BBR؟

• حين يكون الحدّ عند الزائر: إن كان اشتراك زائرك 50 Mbps فلن يصله أكثر منها مهما كانت إعدادات سيرفرك. BBR يرفع سقف سيرفرك لا سقف الزائر.
• في البيانات الواردة إلى سيرفرك: BBR يعمل في جهة المرسِل فقط، فلا يسرّع ما يرسله الآخرون إليك.
• في الصفحات الخفيفة جدًا: صفحة بحجم 200 KB تنتهي قبل أن تصل CUBIC إلى سقفها أصلًا. هنا يهمّ زمن الاستجابة أكثر، وتفاصيله في دليل تقليل TTFB.
• حين يكون البورت نفسه هو الحد: إن كانت خطتك ببورت 100 Mbps فلن يتجاوزه أي إعداد. راجع اختيار سرعة البورت.

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

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

ما هو BBR؟

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

هل تفعيل BBR آمن على سيرفر إنتاجي؟

نعم في الغالب، فهو إعداد نواة قياسي يُفعَّل بسطرين ويُلغى بسطر، ولا يحتاج إعادة تشغيل. تستعمله Google في خدماتها الكبرى منذ سنوات. جرّبه وقِس قبله وبعده، واحتفظ بطريقة التراجع.

هل يسرّع BBR تحميل البيانات إلى سيرفري أيضًا؟

لا. BBR يعمل في جهة المرسِل فقط، أي أنه يسرّع ما يرسله سيرفرك (صفحات موقعك وملفاته وبثّه ونسخه الاحتياطية الصادرة). سرعة ما يستقبله سيرفرك تحدّدها خوارزمية الطرف المرسِل الآخر، ولذلك بقي التنزيل عند سقف البورت في كل تجاربنا.

هل أحتاج BBR إن كان زوار موقعي في العراق؟

إن كان موقعك صغيرًا فالفارق لن يُلحظ في صفحات خفيفة. أما إن كنت تقدّم ملفات كبيرة أو فيديو أو تنقل نسخًا احتياطية أو تشغّل VPN لمستخدمين في العراق فالفارق كبير، لأن المسار طويل (75 إلى 108 ms) وفيه ما يكفي من التذبذب لإبطاء CUBIC.

هل يعمل BBR على ألما لينكس وروكي وديبيان؟

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

الخلاصة

بدأنا بسؤال: لماذا يرسل السيرفر إلى العراق بنصف سرعة ما يستقبله؟ توقّعنا أن السبب ذاكرة TCP، لكن القياس أثبت غير ذلك: الذاكرة الأكبر أضافت 7% فقط، بينما تفعيل BBR رفع متوسط الرفع بنسبة 82% وجعله أثبت، مع خمس شبكات عراقية وفي جولتين مستقلتين. إن كان سيرفرك يرسل بيانات كثيرة إلى العراق (ملفات، فيديو، نسخ احتياطية، VPN) فهذا أسهل تحسين مجاني يمكنك تطبيقه اليوم: سطران للتفعيل، وسطر للتراجع، وقياس قبل وبعد.

التالي: الجزء الرابع: افحص سرعة سيرفرك إلى العراق بنفسك

سيرفر VPS أو VDS من مرام بصلاحيات root كاملة لضبط كل شيء