بهینه‌سازی شبکه سرور لینوکس: فعال‌سازی TCP BBR و تنظیم sysctl روی VPS و سرور اختصاصی

سرعت دانلود از یک سرور فقط به پهنای باند پورت آن وابسته نیست. الگوریتم کنترل ازدحام TCP، تأخیر مسیر، نرخ از دست رفتن بسته‌ها، اندازه بافرها و محدودیت‌های مجازی‌ساز هم روی throughput واقعی اثر دارند. ممکن است یک VPS به پورت یک گیگابیتی متصل باشد، اما در انتقال فایل روی مسیری با تأخیر زیاد تنها بخشی از این ظرفیت را استفاده کند. BBR الگوریتم کنترل ازدحام TCP توسعه‌یافته توسط گوگل است. این الگوریتم به‌جای تکیه‌ی اصلی بر از دست رفتن بسته برای تشخیص ازدحام، پهنای باند قابل‌دستیابی و حداقل زمان رفت‌وبرگشت را تخمین می‌زند. در بعضی مسیرهای دارای تأخیر یا packet loss، نتیجه می‌تواند throughput پایدارتر و صف کوتاه‌تر باشد. در این راهنما، فعال کردن TCP BBR در لینوکس را مرحله‌به‌مرحله انجام می‌دهیم، چند تنظیم sysctl کم‌خطر و قابل‌اندازه‌گیری را بررسی می‌کنیم و با iperf3 وضعیت قبل و بعد را می‌سنجیم. دستورها برای توزیع‌های رایج مبتنی بر Debian، Ubuntu، RHEL، Rocky Linux و AlmaLinux قابل استفاده‌اند؛ هرجا تفاوتی وجود داشته باشد، آن را مشخص می‌کنیم.

پیش از شروع: BBR چه چیزی را تغییر می‌دهد؟

هر اتصال TCP باید تصمیم بگیرد چه مقدار داده را بدون دریافت تأیید از مقصد در شبکه نگه دارد. الگوریتم کنترل ازدحام این مقدار را تنظیم می‌کند. CUBIC، الگوریتم پیش‌فرض بسیاری از توزیع‌های لینوکسی، اندازه پنجره ازدحام را با تابعی مکعبی تغییر می‌دهد و معمولاً عملکرد مناسبی در اینترنت عمومی دارد. BBR مدل متفاوتی دارد. این الگوریتم به‌طور پیوسته دو مقدار را تخمین می‌زند: - بیشترین نرخ تحویل داده که اتصال اخیراً تجربه کرده است - کمترین RTT مشاهده‌شده که تخمینی از تأخیر مسیر بدون صف است BBR با استفاده از این دو مقدار، نرخ ارسال و حجم داده در حال انتقال را کنترل می‌کند. هدف آن پر نگه داشتن مسیر انتقال، بدون ساختن صف‌های طولانی در تجهیزات میانی است. تغییر الگوریتم کنترل ازدحام نمی‌تواند محدودیت پورت، کیفیت ضعیف مسیر، CPU اشباع‌شده یا محدودیت اعمال‌شده توسط ارائه‌دهنده را حذف کند. BBR همچنین سرعت UDP را افزایش نمی‌دهد، چون کنترل ازدحام TCP فقط روی اتصال‌های TCP اثر دارد.

مقایسه CUBIC و BBR

هیچ الگوریتمی در تمام شبکه‌ها برنده نیست. انتخاب درست به RTT، میزان ازدحام، نوع ترافیک و رفتار شبکه مقصد بستگی دارد.

معیار	CUBIC	BBR
مبنای اصلی تصمیم‌گیری	رشد پنجره و واکنش به از دست رفتن بسته	تخمین پهنای باند و حداقل RTT
عملکرد در مسیرهای کم‌تأخیر	معمولاً مناسب	معمولاً مناسب
عملکرد در مسیرهای با RTT بالا	ممکن است دیرتر به ظرفیت برسد	در بسیاری از مسیرها ظرفیت را سریع‌تر پیدا می‌کند
حساسیت به packet loss غیرناشی از ازدحام	بیشتر	معمولاً کمتر
احتمال تشکیل صف طولانی	به وضعیت شبکه وابسته است	با مدیریت pacing برای کاهش صف طراحی شده است
نتیجه روی هر سرور	قابل پیش‌بینی نیست؛ باید اندازه‌گیری شود	قابل پیش‌بینی نیست؛ باید اندازه‌گیری شود

نسخه BBR موجود به کرنل توزیع بستگی دارد. صرف مشاهده نام bbr در فهرست الگوریتم‌ها به معنی استفاده از جدیدترین نسل BBR نیست. برای بیشتر مدیران سرور، استفاده از نسخه پشتیبانی‌شده در کرنل رسمی توزیع از نصب کرنل آزمایشی انتخاب مطمئن‌تری است.

بررسی پیش‌نیازهای سرور

برای فعال‌سازی پایدار به دسترسی root یا امکان اجرای sudo نیاز دارید. ابتدا نسخه کرنل را ببینید:

uname -r

سپس الگوریتم فعلی و الگوریتم‌های در دسترس را بررسی کنید:

sysctl net.ipv4.tcp_congestion_control
sysctl net.ipv4.tcp_available_congestion_control

خروجی ممکن است شبیه نمونه زیر باشد:

net.ipv4.tcp_congestion_control = cubic
net.ipv4.tcp_available_congestion_control = reno cubic

اگر bbr در فهرست نیست، بررسی کنید ماژول آن در کرنل وجود دارد یا نه:

modinfo tcp_bbr

اگر این فرمان اطلاعات ماژول را نشان داد، آن را بارگذاری کنید:

sudo modprobe tcp_bbr

حالا دوباره فهرست الگوریتم‌ها را بخوانید:

sysctl net.ipv4.tcp_available_congestion_control

در بعضی کرنل‌ها BBR به‌صورت داخلی کامپایل شده و modinfo خروجی ندارد، اما نام آن همچنان در tcp_available_congestion_control دیده می‌شود. معیار نهایی همین فهرست است. اگر BBR در دسترس نیست، ابتدا بسته‌های رسمی کرنل توزیع را به‌روزرسانی و سرور را در یک بازه نگهداری راه‌اندازی مجدد کنید. تعویض کرنل روی سرور راه دور ریسک قطع دسترسی دارد؛ پیش از reboot از وجود کنسول اضطراری و نسخه پشتیبان مطمئن شوید.

فعال کردن TCP BBR در لینوکس

برای استفاده از BBR دو تنظیم اصلی نیاز است: الگوریتم کنترل ازدحام روی bbr قرار بگیرد و یک queue discipline مناسب مانند fq انتخاب شود. یک فایل مستقل بسازید تا تنظیمات با فایل اصلی /etc/sysctl.conf مخلوط نشوند:

sudo nano /etc/sysctl.d/99-tcp-bbr.conf

محتوای زیر را در فایل قرار دهید:

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

تنظیمات را بدون reboot اعمال کنید:

sudo sysctl --system

سپس نتیجه را کنترل کنید:

sysctl net.core.default_qdisc
sysctl net.ipv4.tcp_congestion_control

خروجی مورد انتظار چنین است:

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

وجود ماژول بارگذاری‌شده را نیز می‌توان با این فرمان بررسی کرد:

lsmod | grep tcp_bbr

اگر BBR داخل خود کرنل کامپایل شده باشد، نبودن آن در خروجی lsmod الزاماً خطا نیست. مقدار tcp_congestion_control و مشاهده BBR روی اتصال فعال، بررسی دقیق‌تری است.

اطمینان از بارگذاری ماژول پس از راه‌اندازی مجدد

اگر توزیع شما BBR را به شکل ماژول ارائه می‌کند، نام آن را در تنظیمات بارگذاری خودکار ثبت کنید:

echo tcp_bbr | sudo tee /etc/modules-load.d/tcp-bbr.conf

پس از reboot دوباره این دو مقدار را بررسی کنید:

sysctl net.ipv4.tcp_congestion_control
sysctl net.core.default_qdisc

تنظیم sysctl بدون نسخه‌های جادویی

در اینترنت فایل‌هایی با ده‌ها تنظیم sysctl پیدا می‌شوند که بدون توجه به RAM، سرعت پورت و نوع بار کاری پیشنهاد شده‌اند. کپی کردن چنین فایل‌هایی ممکن است مصرف حافظه را بالا ببرد یا رفتار شبکه را بدتر کند. هر پارامتر باید برای یک مشکل اندازه‌گیری‌شده تغییر کند.

افزایش سقف بافرهای TCP

در مسیرهایی با پهنای باند و RTT بالا، پنجره TCP باید بتواند به اندازه حاصل‌ضرب پهنای باند و تأخیر رشد کند. برای نمونه، مسیر یک گیگابیتی با RTT برابر ۱۰۰ میلی‌ثانیه تقریباً به ۱۲٫۵ مگابایت داده در حال پرواز نیاز دارد. لینوکس autotuning دارد، اما سقف بافر ممکن است برای بعضی ارتباط‌ها پایین باشد. یک نقطه شروع محافظه‌کارانه برای سروری با RAM کافی:

net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 131072 16777216
net.ipv4.tcp_wmem = 4096 131072 16777216

این اعداد بر حسب بایت هستند. مقدارهای tcp_rmem و tcp_wmem به‌ترتیب حداقل، پیش‌فرض و حداکثر را مشخص می‌کنند. افزایش سقف به این معنی نیست که تمام اتصال‌ها فوراً ۱۶ مگابایت حافظه مصرف می‌کنند، اما تعداد زیاد اتصال می‌تواند مصرف کلی را افزایش دهد. برای شروع، بهتر است BBR را به‌تنهایی آزمایش کنید. فقط وقتی داده‌های تست نشان می‌دهد پنجره یا بافر گلوگاه است، تنظیمات بافر را اضافه کنید.

حفظ تنظیمات در یک فایل جداگانه

می‌توانید تنظیمات تکمیلی را در فایل دیگری نگه دارید:

sudo nano /etc/sysctl.d/99-network-tuning.conf

پس از ویرایش، ابتدا صحت فایل را با اعمال آن بررسی کنید:

sudo sysctl -p /etc/sysctl.d/99-network-tuning.conf

اگر خطایی دریافت شد، همان پارامتر را بررسی یا حذف کنید. نام پارامترها و امکان تغییر آن‌ها ممکن است میان نسخه‌های کرنل، کانتینرها و میزبان‌های مجازی متفاوت باشد.

بنچمارک قبل و بعد با iperf3

بدون تست کنترل‌شده و بنچمارک نمی‌توان گفت BBR روی سرور شما مفید بوده است. speedtest برای مشاهده تقریبی سرعت اینترنت مناسب است، اما برای مقایسه الگوریتم‌های TCP کنترل کافی روی مقصد، تعداد جریان‌ها و مدت تست نمی‌دهد. iperf3 ابزار مناسب‌تری است. روی Debian و Ubuntu نصب کنید:

sudo apt update
sudo apt install iperf3

روی Rocky Linux، AlmaLinux یا RHEL:

sudo dnf install iperf3

به دو سرور نیاز دارید؛ بهتر است میان آن‌ها RTT و مسیر واقعی مشابه کاربران هدف باشد. روی سرور مقصد اجرا کنید:

iperf3 -s

پورت پیش‌فرض 5201/TCP است. آن را فقط برای IP مبدأ در فایروال باز کنید. روی سرور مورد آزمایش این فرمان را اجرا کنید:

iperf3 -c SERVER_IP -t 30

برای سنجش مسیر معکوس:

iperf3 -c SERVER_IP -t 30 -R

برای بررسی چند جریان هم‌زمان:

iperf3 -c SERVER_IP -t 30 -P 4

یک جریان تکی برای تشخیص اثر کنترل ازدحام مفیدتر است؛ تست چندجریانی نشان می‌دهد برنامه‌هایی که چند اتصال دارند چه عملکردی خواهند داشت.

روش مقایسه منصفانه

ابتدا با CUBIC سه بار تست بگیرید:

sudo sysctl -w net.ipv4.tcp_congestion_control=cubic
iperf3 -c SERVER_IP -t 30

بعد BBR را فعال کنید و همان تست را در همان ساعت، روی همان مقصد و با همان گزینه‌ها تکرار کنید:

sudo sysctl -w net.ipv4.tcp_congestion_control=bbr
iperf3 -c SERVER_IP -t 30

میانگین throughput، تعداد retransmission و ثبات نرخ انتقال را مقایسه کنید. یک اجرای منفرد ممکن است تحت تأثیر ازدحام لحظه‌ای اینترنت قرار بگیرد. بهتر است نتایج را در چند ساعت مختلف ثبت کنید. برای بررسی RTT زیر بار، هم‌زمان با اجرای iperf3 از یک ترمینال دیگر مقصد را ping کنید:

ping SERVER_IP

اگر throughput افزایش یافته اما RTT زیر بار چند برابر شده است، فقط عدد پهنای باند را مبنای تصمیم قرار ندهید. کیفیت شبکه برای API، SSH و برنامه‌های تعاملی به تأخیر نیز وابسته است.

بررسی BBR روی اتصال واقعی

فرمان ss اطلاعات TCP را از سوکت‌های فعال نشان می‌دهد. هنگام وجود یک انتقال TCP، اجرا کنید:

ss -ti

در جزئیات اتصال به دنبال bbr بگردید. برای محدود کردن خروجی به یک پورت مشخص، برای مثال HTTPS:

ss -ti sport = :443

توجه کنید تغییر tcp_congestion_control معمولاً روی اتصال‌های TCP جدید اعمال می‌شود. برای اطمینان، پس از تغییر الگوریتم یک اتصال تازه ایجاد کنید و همان را بررسی کنید. اگر سرور داخل کانتینر اجرا می‌شود، ممکن است اجازه تغییر این پارامترها را نداشته باشید. کنترل الگوریتم TCP و queue discipline معمولاً در اختیار کرنل میزبان است. در VPS کامل با مجازی‌سازی KVM معمولاً دسترسی بیشتری دارید، اما سیاست ارائه‌دهنده همچنان تعیین‌کننده است.

خطاهای رایج و راه‌حل آن‌ها

خطای «No such file or directory»

اگر هنگام تنظیم BBR این خطا را می‌بینید، کرنل احتمالاً الگوریتم را ارائه نمی‌کند یا ماژول آن بارگذاری نشده است. خروجی این دو فرمان را بررسی کنید:

modprobe tcp_bbr
sysctl net.ipv4.tcp_available_congestion_control

اگر همچنان BBR دیده نمی‌شود، از کرنل رسمی جدیدتر توزیع استفاده کنید.

خطای «Operation not permitted»

این خطا معمولاً در کانتینرهای بدون دسترسی لازم رخ می‌دهد. تغییر sysctl از داخل کانتینر ممکن نیست و باید در میزبان انجام شود. در یک سرویس مدیریت‌شده نیز شاید لازم باشد موضوع را از پشتیبانی ارائه‌دهنده پیگیری کنید.

افزایش نیافتن سرعت

ثابت ماندن throughput الزاماً نشانه خرابی BBR نیست. ممکن است عامل محدودکننده یکی از این موارد باشد: - سقف سرعت پورت یا محدودیت پلن - محدودیت دیسک هنگام انتقال فایل - CPU اشباع‌شده به‌دلیل TLS، VPN یا رمزنگاری - مسیر کم‌تأخیر و بدون packet loss که CUBIC روی آن خوب عمل می‌کند - محدودیت سمت گیرنده یا شبکه مقصد - شکل‌دهی ترافیک در hypervisor یا شبکه ارائه‌دهنده برای جداسازی مشکل دیسک از شبکه، iperf3 را به‌جای انتقال فایل استفاده کنید. هنگام تست نیز مصرف CPU، retransmission و RTT را زیر نظر بگیرید.

بازگرداندن تنظیمات

اگر نتیجه بدتر شد، الگوریتم را موقتاً به CUBIC برگردانید:

sudo sysctl -w net.ipv4.tcp_congestion_control=cubic

برای بازگشت پایدار، فایل /etc/sysctl.d/99-tcp-bbr.conf را ویرایش کنید:

net.core.default_qdisc = fq_codel
net.ipv4.tcp_congestion_control = cubic

پیش از انتخاب fq_codel بررسی کنید که در کرنل شما موجود باشد. سپس تنظیمات را اعمال کنید:

sudo sysctl --system

اگر تنظیمات تکمیلی بافر را نیز افزوده‌اید، آن‌ها را جداگانه حذف کنید تا مشخص شود کدام تغییر روی نتیجه اثر داشته است.

انتخاب زیرساخت مناسب برای ترافیک شبکه

BBR می‌تواند استفاده TCP از مسیر را بهتر کند، اما ظرفیت پردازنده، کیفیت شبکه و محدودیت پورت را تغییر نمی‌دهد. برای وب‌سایت، API، پراکسی و load balancer یا سرویس دانلود با بار متوسط، یک سرور مجازی ابری آریاسرویس امکان انتخاب منابع متناسب با بار کاری را فراهم می‌کند. برای بارهای سنگین‌تر، راهنمای خرید سرور اختصاصی گزینه‌های CPU و پهنای باند بیشتر را بررسی می‌کند. پیش از تهیه سرویس، موقعیت کاربران، حجم ترافیک، نیاز پردازشی و سقف پهنای باند پلن را کنار هم بررسی کنید.

جمع‌بندی

برای فعال کردن TCP BBR در لینوکس، ابتدا باید پشتیبانی کرنل را با tcp_available_congestion_control بررسی کنید. سپس net.ipv4.tcp_congestion_control=bbr و معمولاً net.core.default_qdisc=fq را در یک فایل زیر /etc/sysctl.d/ قرار دهید و با sysctl --system اعمال کنید. مرحله مهم‌تر، اندازه‌گیری است. با iperf3 در شرایط یکسان از CUBIC و BBR تست بگیرید، تست معکوس را هم اجرا کنید و علاوه بر throughput، به retransmission و RTT زیر بار توجه داشته باشید. تنظیمات بافر را تنها در صورت مشاهده گلوگاه و با در نظر گرفتن RAM و تعداد اتصال‌ها تغییر دهید. این روش نتیجه‌ای قابل دفاع‌تر از کپی کردن یک فهرست طولانی از پارامترهای sysctl دارد.