ابداع جدید گوگل که TCP BBR نام دارد، که سرعت انتقال اطلاعات در پروتکل TCP را افزایش میدهد. TCP پروتکلی است که برای تنظیم نرخ ارسال یک کاربر در اینترنت کاربرد دارد. توانسته ترافیک شبکه یوتیوب را به طور میانگین ۴ درصد سرعت بیشتری ببخشد. در این نوشتار می خواهیم با طرز کار پروتکل جدید به طور خلاصه آشنا شویم.
گوگل خدمات بسیاری به دنیای علم و پژوهشی کرده است. (ارزشی مالی شرکت نشان می دهد پاداش آن را هم دریافت کرده است!) الگوریتمی پژوهش های گوگل است که به نظر میرسد با پشتوانه این شرکت وارد صنعت خواهد شد. این پروتکل سرعت انتقال اطلاعات را افزایش میدهد و هیچ هزینه ای (به جز تغییر در نرمافزار) ندارد، با این حال موفقیت آن را باید در عمل سنجید.
نگاهی به گذشته پروتکل TCP از همان ابتدای شکل گیری اینترنت (دهه ۷۰ میلادی) با آن همراه بوده است. یک پروتکل ساده ولی بسیار کارآمد است برای اینکه از ازدحام در شبکه تا حد امکان جلوگیری شود. TCP برگرفته از عبارتی به معنای «پروتکل کنترل ارسال» است و اگر بخواهیم طرز کار آن را ارسال بسته های بیشتر خودداری کن ! البته کمی سازی همین یک جمله و تبدیل آن به پروتکلی که چندین دهه جزئی اساسی از اینترنت باشد، قطعا به خلاقیت و ابتکار زیادی نیاز داشته است و ما این را مدیون وینت سرف و باب کان دو دانشمند برجسته در مهندسی شبکه هستیم. لازم به ذکر است، TCP اجزا و کارکردهای مهم دیگری نیز دارد که تمرکز مادر این مقاله بر کارکرد آن به منظور جلوگیری از ازدحام است. در پروتکل TCP، یک پنجره ارسال وجود دارد که تعداد بسته های ارسال شده حداکثر برابر اندازه آن است. اگر یک بسته به طور صحیح به مقصد برسد، پنجره یک واحد جلو می رود. برای مثال در شکل ۱، آن به طور صحیح به مقصد رسیده اند. اگر بسته ۱۳ نیز به مقصد برسد. و تأییدیه (ACK) آن دریافت شود، پنجره یک واحد جلو می رود و بسته شماره ۱۹ داخل پنجره قرار می گیرد. مطابق این شکل بسته های ۱۳، ۱۴ و ۱۵ نیز ارسال شده اند، اما فرستنده از رسیدن آنها به مقصد هنوز اطلاعی ندارد. بسته های ۱۶، ۱۷ و ۱۸ نیز می توانند ارسال شوند. اندازه پنجره را گیرنده بر اساس اندازه بافر خود اعلام می کند و در عین حال ازدحام شبکه بر آن تأثیر دارد. اگر ازدحام شدید باشد، ممکن است اندازه پنجره حتی به صفر نیز برسد. بنابراین، تغییر در اندازه پنجره است که به نوعی نرخ ارسالی از سوی فرستنده را کنترل می کند.
یک نمونه از تغییرات اندازه پنجره بر حسب زمان در شکل 2 به تصویر کشیده شده است. روال TCP این گونه است که در ابتدای کار اندازه پنجره به سرعت افزایش یافته و پس از اینکه به یک حد نصاب رسید (خط چین در شکل) دیگر به صورت تدریجی افزایش مییابد تا زمانی که یک تعداد بسته به مقصد نرسند. در این صورت فرض می شود که در شبکه ازدحامی رخ داده که به نرسیدن بسته ها منجر شده است. بنابراین، اندازه پنجره نصف خواهد شد و روند ارسال با نرخ کمتر ادامه خواهد یافت. ثابت شده است که اگر تمام فرستنده ها به پروتکل TCP پایبند باشند، عدالت نسبی در شبکه برقرار خواهد شد. حال که کلیات عملکرد کنترل ارسال در TCP را بررسی کردیم صرف نظر از جزئیات فراوان)، به سراغ BBR خواهیم رفت تا ببینیم شرکت گوگل چه ارمغانی را برای ما آورده است.
گوگل وارد بازی می شود
از زمان معرفی TCP، اصلاحات زیادی در ارتباط با ان ارائه شده است که مواردی را از جمله نحوه تشخیصی ازدحام و میزان کاهش اندازه پنجره در هنگام بروز ازدحام در بر می گیرد. برخی از این بهبودها در حد یک کار پژوهشی باقی مانده و برخی دیگر در عمل استفاده شدهاند. در واقع، نسخه TCP که امروزه در ارتباطات اینترنتی ما استفاده می شود، یک نسخه اصلاح شده از آن است. در این میان، شرکت گوگل که خود را یک شرکت پژوهشی میداند (که ادعای درستی هم است) یک الگوریتم معرفی کرده است. الگوریتم گوگل TCP BBR نام دارد که قسمت دوم ان کوتاه شده عبارت Bottleneck Bandwidth and RTT به معنای پهنای باند گلوگاه و زمان رفت و برگشت سفر است. این الگوریتم سالها قبل طراحی شده است، اما در سپتامبر ۲۰۱۶ به صورت یک وصله به کرنل لینوکس اضافه شد و در حال حاضر به سکوی ابری گوگل نیز افزوده شده است. با این حساب ما با یک فناوری کاملاً جدید روبه رو نیستیم، بلکه این فناوری هم اکنون به جهان عرضه شده است. تفاوت اصلی الگوریتم گوگل با نسخه های قبلی TCP در نحوه تشخیصی ازدحام است. در نسخه های قبلی، ازدحام پس از رخ دادن شناسایی می شد، اما در TCP BBR ازدحام قبل از وقوع پیش بینی می شود. این تفاوت برای اینترنت فعلی که انتقال اطلاعات به صورت بیدرنگ در ان اهمیت روزافزونی یافته است، بسیار مهم خواهد بود. در بخش بعدی، نحوه کار این الگوریتم را به اختصار بیان خواهیم کرد.
الگوریتم چگونه کار می کند
الگوریتم TCP BBR یک براورد دائمی از دو پارامتر را لحاظ می کند. پارامتر اول زمان رفت و برگشت سفر موسوم به RTT است. این پارامتر بازه زمانی را مشخص میکند که اطلاعات از مبداً به مقصد رفته و سپس تأییدیه آن به مبداً برگشته است. هرچه این پارامتر کوچکتر باشد، به معنای سرعت بیشتر انتقال اطلاعات است. الگوریتم مذکور کمترین مقدار RTT ثبت شده را در لحظات اخیر به عنوان برآوردی از آن ثبت می کند. پارامتر دوم پهنای باند گلوگاه است که بر اساس بیشینه نرخ دریافت شده توسط گیرنده در یک بازه مشخصی تخمین زده می شود. دو پارامتر فوق مستقل از هم در نظر گرفته می شوند و محاسبه هریک جداگانه انجام می شود. برای هر تأییدیه دریافتی، اگر بسته از نوع محدود از نظر اپلیکیشن نباشد، فرستنده دو پارامتر فوق را به روزرسانی می کند. محدود از نظر اپلیکیشن یعنی اینکه برنامهای که در حال ارسال اطلاعات است، خودش جریان اطلاعات را قطع کرده باشد. روال اصلی الگوریتم این است که فرستنده بسته ها را با نرخی ارسال کند که صف در هیچ نقطه از مسیر شکل نگیرد. این برخلاف پروتکل های قبلی است که نرخ فرستنده را (با افزایش اندازه پنجره ارسال) آنقدر بالا می برند که صف تشکیل بشود و درنهایت از هدر رفتن بسته ها در مسیر متوجه رخ دادن ازدحام بشوند. اگر نگاهی مجدد به شکل ۲ بیاندازید، متوجه حالت زیگزاگی نمودار می شوید که حکایت از کنش و واکنش های متناوب نسبت به ازدحام در شبکه دارد. اما BBR این حالت زیگزاگی را ندارد و ثبات بیشتری دارد. در شکل ۳ نیز این پروتکل (منحنی سبز رنگ) با دو نسخه دیگر RenO ) TCP با منحنی آبی رنگ و CUBIC با منحنی قرمز رنگ) مقایسه شده است.
اگر با نسخه های مختلف TCP آشنا باشید، شاید به نظرتان برسد که این الگوریتم همان TCP Vegas است، در حالی که از نظر رفتار انطباقی جریان با آن تفاوت دارد. در BBR اندازه پنجره برابر حاصل ضرب پهنای باند گلوگاه و RTT است. برای مثال اگر پهنای باند یک گیگابیت بر ثانیه و RT T یک میلی ثانیه باشد، حاصل ضرب آن دو برابر یک میلیون می شود، در نتیجه اندازه پنجره برابر یک میلیون بیت است. برای آشنایی با چگونگی تنظیم نرخ ارسال و جزئیات دیگر الگوریتم، به مقاله ای که گوگل با عنوان BBR Congestion-Based Congestion Control منتشر شده کرده مراجعه کنید.
منبع: ماهنامه شبکه
