تفاوت الگوریتم‌های کنترل ازدحام TCP: چگونه CUBIC و BBR تأخیر و توان عملیاتی اینترنت را مدیریت می‌کنند؟

مهندسان شبکه در مورد نحوه ارسال داده‌ها در اینترنت بدون ایجاد اختلال، با یک شکاف اساسی روبرو هستند. در یک سو، رویکرد سنتی مبتنی بر افت بسته (Loss-based) فرض می‌کند که از دست رفتن یک بسته به معنای پر شدن شبکه است و برای جلوگیری از فروپاشی، کاهش فوری سرعت را الزامی می‌داند. در سوی دیگر، یک فلسفه جدیدتر مبتنی بر مدل (Model-based) استدلال می‌کند که افت بسته یک سیگنال پرنویز است، به ویژه در لینک‌های بی‌سیم مدرن، و فرستنده‌ها باید به جای آن، سرعت واقعی خط ارتباطی را اندازه‌گیری کرده و بسته‌های خود را متناسب با آن تنظیم کنند.[6]

برای هر کسی که یک سرور، پلتفرم پخش ویدئو یا شبکه پرسرعت را مدیریت می‌کند، انتخاب بین این دو رویکرد، کف توان عملیاتی و سقف تأخیر برنامه را تعیین می‌کند. الگوریتم پیش‌فرض در اکثر سیستم‌عامل‌ها، CUBIC، در شبکه‌های محلی تمیز عملکرد فوق‌العاده‌ای دارد اما در اتصالات دارای افت بسته با مشکل مواجه می‌شود. تغییر سرور به الگوریتم BBR (Bottleneck Bandwidth and Round-trip propagation time) تنها به یک تغییر پیکربندی در هسته لینوکس نیاز دارد، با این حال می‌تواند توان عملیاتی یک جریان ویدئویی را در یک لینک ضعیف ۴G، بدون نیاز به دستکاری کد برنامه، دو برابر کند.[6]

برای درک این تفاوت، باید به نحوه مدیریت ترافیک توسط پروتکل کنترل انتقال (TCP) در طول تاریخ نگاه کرد. TCP از یک پنجره ازدحام (Congestion Window) استفاده می‌کند تا تعداد کل بسته‌های تأیید نشده‌ای را که ممکن است به صورت سرتاسری در حال انتقال باشند، محدود کند. CUBIC، که به الگوریتم پیش‌فرض در پشته‌های لینوکس، ویندوز و اپل تبدیل شد، ظرفیت شبکه را با ارسال سریع‌تر و سریع‌تر داده‌ها تا زمانی که افت بسته‌ای مشاهده کند، پیدا می‌کند.[2][5]

هنگامی که افت بسته رخ می‌دهد، CUBIC به شدت پنجره ارسال خود را کاهش می‌دهد و سپس از یک تابع چندجمله‌ای درجه سه (Cubic Polynomial Function) استفاده می‌کند تا به سرعت به حداکثر قبلی بازگردد و سپس برای جستجوی ظرفیت بیشتر، سرعت را ثابت نگه می‌دارد. این رویکرد ریاضی به CUBIC اجازه می‌دهد تا ازدحام را با پیچیدگی بسیار بیشتری نسبت به توابع خطی که توسط الگوریتم‌های قدیمی‌تر مانند Reno استفاده می‌شد، مدیریت کند.[2]

محدودیت این طراحی مبتنی بر افت بسته این است که بافرهای شبکه را تا سرریز شدن پر می‌کند. شرکت ThousandEyes در تحلیل کیفیت مسیرهای خود در سال ۲۰۲۴ اشاره می‌کند: «در تجهیزات شبکه با بافرهای کم‌عمق، افت بسته قبل از ازدحام رخ می‌دهد.» در لینک‌هایی با بافرهای عمیق، CUBIC باعث پدیده «بافر بلوت» (Buffer Bloat) می‌شود—پدیده‌ای که در آن بسته‌ها در صف‌های طولانی می‌مانند و صدها میلی‌ثانیه تأخیر به اتصال اضافه می‌کنند.[3]

علاوه بر این، در لینک‌های بی‌سیم یا ماهواره‌ای که بسته‌ها به طور معمول به دلیل تداخل (و نه ازدحام) از دست می‌روند، CUBIC این افت را اشتباه تفسیر کرده و به طور غیرضروری سرعت اتصال را کاهش می‌دهد. این رفتار هر افت بسته را به عنوان نشانه‌ای از فروپاشی شبکه تلقی می‌کند، که فرضیه‌ای نادرست در شبکه‌های مدرن ۴G و ۵G است.[3][6]

گوگل BBR را برای شکستن وابستگی به افت بسته معرفی کرد. BBR که به عنوان پیش‌نویس نیروی کار مهندسی اینترنت (IETF) استاندارد شده است، به طور فعال شبکه را بررسی می‌کند تا مدلی از دو پارامتر بسازد: پهنای باند گلوگاه (Bottleneck Bandwidth) (حداکثر نرخ داده‌ای که مسیر می‌تواند پشتیبانی کند) و زمان رفت و برگشت (Round-Trip Time یا RTT) (تأخیر پایه زمانی که شبکه خالی است).[1]

BBR به جای انتظار برای سرریز شدن بافر، بسته‌های خود را با سرعت دقیق ظرفیت لینک گلوگاه تنظیم می‌کند. با این کار، تلاش می‌کند تا نرخ ارسال را در سطحی نگه دارد که درست قبل از شروع صف‌بندی بسته‌ها در بافرهای شبکه است، و بدین ترتیب ضمن به حداکثر رساندن توان عملیاتی، پدیده بافر بلوت را به طور مؤثر حذف می‌کند.[1]

تفاوت عملکرد زمانی که شرایط شبکه بدتر می‌شود، آشکار می‌گردد. در یک بنچمارک ThousandEyes در سال ۲۰۲۴، هر دو الگوریتم در یک شبکه متقارن و تمیز به توان عملیاتی پایه مشابهی دست یافتند—۸۰۴.۶ مگابیت بر ثانیه برای CUBIC و ۸۶۸.۵ مگابیت بر ثانیه برای BBR. با این حال، هنگامی که مهندسان نرخ افت بسته ۱ درصد را اعمال کردند، توان عملیاتی CUBIC به ۲۳۵.۵۱ مگابیت بر ثانیه سقوط کرد.[3]

BBR، با نادیده گرفتن افت تصادفی، توان عملیاتی ۷۹۴.۰۶ مگابیت بر ثانیه را حفظ کرد—یعنی بیش از ۹۱ درصد از ظرفیت پایه خود را نگه داشت. این نشان‌دهنده تفاوت ۷۰.۳ درصدی در توان عملیاتی به دست آمده بین CUBIC و BBR تحت شرایط افت بسته یکسان است. این انعطاف‌پذیری، BBR را برای پخش ویدئو و تحویل موبایلی، که حفظ یک کف توان عملیاتی بالا برای تجربه کاربر حیاتی است، بسیار جذاب می‌کند.[3]

با وجود مزایای توان عملیاتی، BBR یک راه‌حل جهانی نیست. محققان مشکلات مربوط به «انصاف» (Fairness) را زمانی که جریان‌های BBR مستقیماً با جریان‌های CUBIC در یک لینک گلوگاه رقابت می‌کنند، مستند کرده‌اند. از آنجا که BBR افت بسته را نادیده می‌گیرد و به ارسال داده با پهنای باند مدل‌سازی شده ادامه می‌دهد، می‌تواند الگوریتم‌های مبتنی بر افت بسته را که به شدت عقب‌نشینی می‌کنند، از منابع محروم سازد.[4][5]

علاوه بر این، BBR به طور تاریخی به نفع جریان‌هایی با زمان رفت و برگشت طولانی‌تر (RTT) عمل کرده و پهنای باند بیشتری نسبت به جریان‌های رقیب با RTT کوتاه به آن‌ها اختصاص داده است. مجله MDPI تحقیقاتی را در مورد بهینه‌سازی BBR از طریق «مدل بهره‌وری تنظیم سرعت» (Pacing Gain Model) برای رفع دقیق این نابرابری در انصاف منتشر کرد و اشاره نمود که تنظیم بهره‌وری تنظیم سرعت بر اساس RTT می‌تواند انصاف درون پروتکلی BBR را تا ۴۶ درصد بهبود بخشد.[4]

جامعه شبکه‌سازی همچنان در حال اصلاح این مدل‌ها برای اطمینان از تخصیص عادلانه پهنای باند است. BBRv3 در هسته‌های اخیر لینوکس ۶.x ادغام شده است و به‌روزرسانی‌هایی را به همراه دارد که همزیستی با CUBIC را بهبود بخشیده و ارسال مجدد بسته‌ها را کاهش می‌دهد. این بهبودهای تکراری قبل از اینکه الگوریتم‌های مبتنی بر مدل بتوانند به طور کامل جایگزین الگوریتم‌های مبتنی بر افت بسته در اینترنت عمومی شوند، ضروری هستند.[1][4]

گذار از کنترل ازدحام مبتنی بر افت بسته به کنترل ازدحام مبتنی بر مدل، نشان‌دهنده یک تغییر ساختاری در معماری اینترنت است. در حالی که CUBIC همچنان استاندارد قوی و جهانی برای محیط‌های تمیز باقی مانده است، BBR یک جایگزین ضروری برای اینترنت عمومی که به طور فزاینده‌ای بی‌سیم و ناهمگن است، فراهم می‌کند. تصمیم‌گیری به مسیر شبکه خاص بستگی دارد: یک شبکه محلی (LAN) ممکن است مزایای کمی از BBR ببیند، اما برای تحویل محتوای جهانی، تنظیم سرعت بر اساس گلوگاه در حال جایگزینی با روش جستجو بر اساس افت بسته است.[6]