الگوریتم TCP BBR، راهکار جامع گوگل برای حل مشکل ازدحام در شبکه

نگاهی به گذشته

پروتکل TCP از همان ابتدای شکل‌گیری اینترنت (دهه 70 میلادی) با آن همراه بوده است. یک پروتکل ساده ولی بسیار کارآمد است برای اینکه از ازدحام در شبکه تا حد امکان جلوگیری شود. TCP برگرفته از عبارتی به معنای «پروتکل کنترل ارسال» است و اگر بخواهیم طرز کار آن را در یک جمله بیان کنیم، باید گفت که اگر بسته‌ها به مقصد نمی‌رسند، از ارسال بسته‌های بیشتر خودداری کن! البته کمی‌سازی همین یک جمله و تبدیل آن به پروتکلی که چندین دهه جزئی اساسی از اینترنت باشد، قطعاً به خلاقیت و ابتکار زیادی نیاز داشته است و ما این را مدیون وینت سرف و باب کان دو دانشمند برجسته در مهندسی شبکه هستیم. لازم به ذکر است، TCP اجزا و کارکردهای مهم دیگری نیز دارد که تمرکز ما در این مقاله بر کارکرد آن به‌منظور جلوگیری از ازدحام است.
در پروتکل TCP، یک پنجره ارسال وجود دارد که تعداد بسته‌های ارسال ‌شده حداکثر برابر اندازه آن است. اگر یک بسته به طور صحیح به مقصد برسد، پنجره یک واحد جلو می‌رود. برای مثال در شکل 1،هر عدد نشان‌گر یک بسته است. طبق این شکل بسته‌های 12 و قبل از آن به طور صحیح به مقصد رسیده‌اند. اگر بسته 13 نیز به مقصد برسد و تأییدیه (ACK) آن دریافت شود، پنجره یک واحد جلو می‌رود و بسته شماره 19 داخل پنجره قرار می‌گیرد. مطابق این شکل بسته‌های 13، 14 و 15 نیز ارسال شده‌اند، اما فرستنده از رسیدن آن‌ها به مقصد هنوز اطلاعی ندارد. بسته‌های 16، 17 و 18 نیز می‌توانند ارسال شوند. اندازه پنجره را گیرنده بر اساس اندازه بافر خود اعلام می‌کند و در عین حال ازدحام شبکه بر آن تأثیر دارد. اگر ازدحام شدید باشد، ممکن است اندازه پنجره حتی به صفر نیز برسد. بنابراین، تغییر در اندازه پنجره است که به‌نوعی نرخ ارسالی از سوی فرستنده را کنترل می‌کند. 

مطلب پیشنهادی

روش جدید گوگل برای جلوگیری از سرریز شدن شبکه

الگوریتم جدید گوگل کلاود باعث افزایش سرعت انتقال اطلاعات می‌شود

یک نمونه از تغییرات اندازه پنجره برحسب زمان در شکل 2 به تصویر کشیده شده است. روال TCP این گونه است که در ابتدای کار اندازه پنجره به‌سرعت افزایش یافته و پس از اینکه به یک حد نصاب رسید (خط‌چین در شکل) دیگر به صورت تدریجی افزایش می‌یابد تا زمانی که یک تعداد بسته به مقصد نرسند. در این صورت فرض می‌شود که در شبکه ازدحامی رخ داده که به نرسیدن بسته‌ها منجر شده است. بنابراین، اندازه پنجره نصف خواهد شد و روند ارسال با نرخ کمتر ادامه خواهد یافت. ثابت شده است که اگر تمام فرستنده‌ها به پروتکل TCP پایبند باشند، عدالت نسبی در شبکه برقرار خواهد شد.
حال که کلیات عملکرد کنترل ارسال در TCP را بررسی کردیم (صرف نظر از جزئیات فراوان)، به سراغ BBR خواهیم رفت تا ببینیم شرکت گوگل چه ارمغانی را برای ما آورده است.

مطلب پیشنهادی

۱۲ نرم‌افزار مدیریت بر شبکه و ترافیک شبکه

نرم‌افزارهایی برای کنترل پهنای باند و نظارت بر شبکه (بخش اول)

گوگل وارد بازی می‌شود

از زمان معرفی TCP، اصلاحات زیادی در ارتباط با آن ارائه شده است که مواردی را از جمله نحوه تشخیص ازدحام و میزان کاهش اندازه پنجره در هنگام بروز ازدحام در بر می‌گیرد. برخی از این بهبودها در حد یک کار پژوهشی باقی ‌مانده و برخی دیگر در عمل استفاده شده‌اند. در واقع، نسخه‌ TCP که امروزه در ارتباطات اینترنتی ما استفاده می‌شود، یک نسخه اصلاح ‌شده از آن است. در این میان، شرکت گوگل که خود را یک شرکت پژوهشی می‌داند (که ادعای درستی هم است) یک الگوریتم معرفی کرده است. الگوریتم گوگل TCP BBR نام دارد که قسمت دوم آن کوتاه‌شده عبارت Bottleneck Bandwidth and RTT به‌معنای پهنای ‌باند گلوگاه و زمان رفت ‌و‌ برگشت سفر است. این الگوریتم سال‌ها قبل طراحی شده است، اما در سپتامبر 2016 به‌صورت یک وصله به کرنل لینوکس اضافه شد و در حال حاضر به سکوی ابری گوگل نیز افزوده شده است. 
با این حساب ما با یک فناوری کاملاً جدید روبه‌رو نیستیم، بلکه این فناوری هم‌اکنون به جهان عرضه شده است. تفاوت اصلی الگوریتم گوگل با نسخه‌های قبلی TCP در نحوه تشخیص ازدحام است. در نسخه‌های قبلی، ازدحام پس از رخ دادن شناسایی می‌شد، اما در TCP BBR ازدحام قبل از وقوع پیش‌بینی می‌شود. این تفاوت برای اینترنت فعلی که انتقال اطلاعات به‌صورت بی‌درنگ در آن اهمیت روزافزونی یافته است، بسیار مهم خواهد بود. در بخش بعدی، نحوه کار این الگوریتم را به اختصار بیان خواهیم کرد.

مطلب پیشنهادی

در دوران زتااستراکچر چه بخش‌هایی باید متحول شوند؟

در حال ورود به عصر زتابایت هستیم، آیا شما آمادگی دارید؟

الگوریتم چگونه کار می‌کند

الگوریتم TCP BBR یک برآورد دائمی از دو پارامتر را لحاظ می‌کند. پارامتر اول زمان رفت ‌و ‌برگشت سفر موسوم به RTT است. این پارامتر بازه زمانی را مشخص می‌کند که اطلاعات از مبدأ به مقصد رفته و سپس تأییدیه آن به مبدأ برگشته است. هرچه این پارامتر کوچک‌تر باشد، به‌معنای سرعت بیشتر انتقال اطلاعات است. الگوریتم مذکور کمترین مقدار RTT ثبت ‌شده را در لحظات اخیر به‌عنوان برآوردی از آن ثبت می‌کند. پارامتر دوم پهنای باند گلوگاه است که بر اساس بیشینه نرخ دریافت ‌شده توسط گیرنده در یک بازه مشخص تخمین زده می‌شود. دو پارامتر فوق مستقل از هم در نظر گرفته می‌شوند و محاسبه هریک جداگانه انجام می‌شود. برای هر تأییدیه دریافتی، اگر بسته از نوع محدود از نظر اپلیکیشن نباشد، فرستنده دو پارامتر فوق را به‌روزرسانی می‌کند. محدود از نظر اپلیکیشن یعنی اینکه برنامه‌ای که در حال ارسال اطلاعات است، خودش جریان اطلاعات را قطع کرده باشد. روال اصلی الگوریتم این است که فرستنده بسته‌ها را با نرخی ارسال کند که صف در هیچ نقطه از مسیر شکل نگیرد. این برخلاف پروتکل‌های قبلی است که نرخ فرستنده را (با افزایش اندازه پنجره ارسال) آنقدر بالا می‌برند که صف تشکیل بشود و درنهایت از هدر رفتن بسته‌ها در مسیر متوجه رخ دادن ازدحام بشوند. اگر نگاهی مجدد به‌ شکل 2 بیاندازید، متوجه حالت زیگزاگی نمودار می‌شوید که حکایت از کنش و واکنش‌های متناوب نسبت به ازدحام در شبکه دارد. اما BBR این حالت زیگزاگی را ندارد و ثبات بیشتری دارد. در شکل 3 نیز این پروتکل (منحنی سبز رنگ) با دو نسخه دیگر Reno   ) Tcp با منحنی آبی ‌رنگ و CUBIC با منحنی قرمز رنگ) مقایسه شده است.

اگر با نسخه‌های مختلف TCP آشنا باشید، شاید به نظرتان برسد که این الگوریتم همان TCP Vegas است، در حالی که از نظر رفتار انطباقی جریان با آن تفاوت دارد. در BBR اندازه پنجره برابر حاصل ‌ضرب پهنای باند گلوگاه و RTT است. برای مثال اگر پهنای باند یک گیگابیت بر ثانیه و RTT یک میلی ‌ثانیه باشد، حاصل ضرب آن دو برابر یک میلیون می‌شود، در نتیجه اندازه پنجره برابر یک میلیون بیت است. برای آشنایی با چگونگی تنظیم نرخ ارسال و جزئیات دیگر الگوریتم، به مقاله‌ای که گوگل با عنوان BBR Congestion-Based Congestion Control منتشر کرده، مراجعه کنید.

مطلب پیشنهادی

ماهنامه شبکه 197 با پرونده ویژه «داده‌های بزرگ؛ فردای بزرگ‌تر» منتشر شد

سخن آخر

گوگل خدمات بسیاری به دنیای علم و پژوهش کرده است. (ارزش مالی شرکت نشان می‌دهد پاداش آن را هم دریافت کرده است!) الگوریتمی که در این نوشتار به‌صورت اجمالی بررسی شد، یک نمونه از نتایج پژوهش‌های گوگل است که به نظر می‌رسد با پشتوانه این شرکت وارد صنعت خواهد شد. این پروتکل سرعت انتقال اطلاعات را افزایش می‌دهد و هیچ هزینه‌ای (به‌جز تغییر در نرم‌افزار) ندارد، با این حال موفقیت آن را باید در عمل سنجید.