یکی از چالش‌های بنیادین در مهندسی شبکه‌های رایانه‌ای، پدیده افت شدید بازده داده‌ها در مسیرهای ترانزیتی راه دور است. کاربری با اتصال فیبر نوری متقارن ۱ گیگابیت بر ثانیه به یک تونل رمزنگاری‌شده بین‌المللی—برای مثال از توکیو به فرانکفورت با تأخیر رفت‌وبرگشت 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) ──> افت بسته ──> کاهش ۳۰ درصدی پنجره
                         ▲                                                                       │
                         └──────────────── بازسازی کند بر پایه تابع درجه ۳ ──────────────────────┘
                                 پیامد: پدیده مخرب Bufferbloat، ناپایداری تأخیر و افت فاحش بازده

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

[سازوکار مدرن الگوریتم TCP BBR مبتنی بر مشخصه‌های فیزیکی]
اندازه‌گیری پیوسته: پهنای باند گلوگاه (BtlBw) و کمینه تأخیر فیزیکی رفت‌وبرگشت (RTprop)
تنظیم نرخ ارسال بسته (Kernel Pacing) بر مبنای توان واقعی ──> صف روترها خالی می‌ماند ──> بدون داده انباشته
                                 نتیجه: دستیابی به بالاترین توان پیوند، حذف Bufferbloat، پایداری تأخیر

کاستی‌های ریاضی در الگوریتم مبتنی بر اتلاف بسته: CUBIC (RFC 9438)

برای درک علت افت عملکرد اتصالات راه دور، باید ساختار محاسباتی TCP CUBIC (مطابق با استاندارد RFC 9438) را بررسی نمود.

در چارچوب افزایش خطی و کاهش ضربی (AIMD)، الگوریتم CUBIC فرض می‌کند که افت بسته تنها نشانه بروز ازدحام در شبکه است. این الگوریتم پیوسته پنجره ازدحام ($cwnd$) را افزایش می‌دهد تا زمانی که حافظه بافر یکی از روترهای میانی پر شده و بسته‌ای دور ریخته شود (Tail Drop).

به محض شناسایی بسته مفقود از طریق اعلان‌های تکراری سه‌گانه (Triple-Duplicate ACK) یا تأیید انتخابی (SACK)، الگوریتم جریمه سختی اعمال می‌کند:

$$W_{\max} = \text{اندازه داده‌های در حال انتقال (Flight Size)}$$ $$cwnd_{\text{جدید}} = W_{\max} \times \beta \quad (\text{با ضریب } \beta = 0.7)$$

پنجره انتقال ۳۰ درصد کاهش می‌یابد؛ بدون توجه به این‌که آیا افت بسته ناشی از پر شدن واقعی روتر بوده یا ناشی از تداخل‌های فرکانسی معمول در بسترهای Wi-Fi و شبکه‌های سلولی.

در سال ۱۹۹۷، متیو ماتیس محدودیت سقف انتقال در پروتکل‌های مبتنی بر افت بسته را با نام فرمول ماتیس (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$ است.

در بستر یک تونل شبکه امن فرامرزی:

  • $\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—پشت هزاران بسته داده بزرگ محبوس می‌شوند. ۳. زمان رفت‌وبرگشت از مقدار پایه ۲۵ میلی‌ثانیه به بیش از ۴۰۰ میلی‌ثانیه اوج می‌گیرد. ۴. نوسان شدید در تحویل بسته‌ها (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 برای کشف ظرفیت تازه، ۰.۷۵ برابر برای تخلیه صف، و ۱.۰ برابر در ۶ چرخه RTT بعدی).
  • PROBE_RTT: تقلیل بسته‌های در حال انتقال به ۴ بسته در هر ۱۰ ثانیه برای مدت ۲۰۰ میلی‌ثانیه جهت سنجش دقیق تأخیر خالص مسیر $\text{RTprop}$.

با به‌کارگیری زمان‌بندی منظم بسته‌ها در سطح هسته Kernel Pacing از طریق Fair Queueing به جای ارسال انفجاری داده‌ها، BBR مانع از ایجاد ترافیک نامنظم می‌شود.

روند بهینه‌سازی: از BBRv1 تا نسخه BBRv3

به‌کارگیری اولیه BBRv1 دو چالش کلیدی را آشکار ساخت: ۱. رقابت با CUBIC: در بافرهای عمیق، جریان‌های CUBIC با پر کردن صف‌ها سهم منصفانه پهنای باند BBRv1 را تضعیف می‌کردند. ۲. بافرهای کم‌عمق: در افت‌های تصادفی شدید (بالاتر از ۱۵ تا ۲۰ درصد)، حجم داده‌های در جریان BBRv1 بالاتر از حد باقی می‌ماند.

کارگروه مهندسی اینترنت (IETF) و شرکت گوگل این موارد را در BBRv2 و نسخه مدرن BBRv3 ارتقا دادند:

  • پشتیبانی از هشدار آشکار ازدحام (ECN): خواندن نشانگرهای CE مطابق با RFC 3168 جهت کاهش تدریجی نرخ ارسال پیش از ریزش بسته‌ها.
  • سقف‌گذاری پویا برای داده‌های در جریان: تعدیل هوشمندانه حجم داده‌ها بر پایه افت واقعی برای همزیستی مسالمت‌آمیز با CUBIC.
  • اندازه‌گیری پرسرعت RTT: کوتاه کردن زمان فرورفتگی نرخ در فاز PROBE_RTT برای تثبیت پایداری جریان داده.
ویژگی فنی TCP Reno (RFC 5681) TCP CUBIC (RFC 9438) TCP BBRv1 TCP BBRv3
سیگنال هدایت‌کننده اتلاف بسته اتلاف بسته مدل پهنای باند و تأخیر پهنای باند، تأخیر، افت و ECN
روش ارسال رگباری (Bursts) رگباری (Bursts) تنظیم نرخ هسته (fq) تنظیم نرخ هسته (fq)
شدت Bufferbloat بسیار شدید بسیار شدید ناچیز کاملاً مهارشده
تحمل ۱٪ افت بسته افت شدید (< ۵٪ سرعت) افت بالا (< ۱۰٪ سرعت) بسیار عالی (+۹۵٪ سرعت) حداکثری (+۹۸٪ سرعت)
دستیابی به ظرفیت BDP بسیار کند متوسط فوری فوری و تطبیقی
تسهیم منصفانه پایه پایه تهاجمی به CUBIC تنظیم تعادلی منصفانه

پیکربندی عملیاتی 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

بررسی کارکرد الگوریتم با ابزار ss صورت می‌پذیرد:

# بررسی جزئیات پارامترهای BBR روی درگاه‌های فعال
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 میلی‌ثانیه و نرخ تنظیم‌شده سخت‌افزاری است.

بهره‌گیری زیرساخت VPNRice و پروتکل RiceGuard از BBR

امنیت پایدار در کنار عملکرد سریع، نیازمند هدایت هوشمندانه ترافیک در شبکه است. سامانه VPNRice تنظیم نرخ BBR را در هسته ارتباطی RiceGuard تعبیه کرده است:

  • تنظیم آهنگ ارسال در دروازه‌های Anycast: تمام گره‌های Anycast در VPNRice ترافیک را از طریق الگوریتم‌های پیشرفته BBR و زمان‌بند FQ تنظیم می‌کنند تا از انباشتگی بافرها در گره‌های میانی اینترنت جلوگیری شود.
  • جلوگیری از افت سرعت در اتصالات ناپایدار: در شبکه‌های متغیر سلولی یا Wi-Fi عمومی با افت‌های تصادفی، پروتکل RiceGuard مانع از سقوط ۷۰ درصدی سرعت در الگوریتم‌های سنتی می‌گردد.
  • تضمین ثبات تأخیر در تبادلات بلادرنگ: تخلیه پیوسته بافرها در نقطه بهینه کلین‌راک، امکان تجربه بازی‌های آنلاین و تماس‌های صوتی بدون نوسان تأخیر (Jitter) را مهیا می‌سازد.