بافربلوت

بافربلوت (Bufferbloat) علت تأخیر و لرزش زیاد در شبکه‌های سوئیچ بسته به دلیل بافر بیش از حد بسته‌ها است. بافربلوت همچنین می‌تواند باعث تغییرات تأخیر بسته (همچنین به عنوان جیتر) شود و همچنین باعث کاهش توان عملیاتی شبکه شود. هنگامی که یک روتر یا سوئیچ برای استفاده از بافرهای بسیار بزرگ پیکربندی شده‌است، حتی شبکه‌های پرسرعت می‌توانند عملاً برای بسیاری از برنامه‌های تعاملی مانند صدا از طریق IP (VoIP)، پخش صدا، بازی آنلاین و حتی مرورگر وب معمولی غیرقابل استفاده شوند.

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

پدیده بافربلوت در اوایل سال ۱۹۸۵ توصیف شد. از سال ۲۰۰۹ توجه گسترده‌تری را به خود جلب کرد.

بافر کردن

یک قانون کلی ثابت شده برای تولیدکنندگان تجهیزات شبکه این بود که بافرهایی به اندازه کافی برای گنجاندن حداقل ۲۵۰ میلی‌ثانیه بافر برای جریان ترافیکی که از یک دستگاه می‌گذرد فراهم کنند. برای مثال، رابط اترنت گیگابیتی روتر به یک بافر نسبتاً بزرگ ۳۲ مگابایتی نیاز دارد. چنین اندازه‌گیری بافرها می‌تواند منجر به شکست الگوریتم کنترل تراکم TCP شود. سپس تخلیه بافرها مدتی طول می‌کشد، قبل از اینکه کنترل ازدحام بازنشانی شود و اتصال TCP به سرعت بالا برود و دوباره بافرها را پر کند. بنابراین بافربلوت باعث ایجاد مشکلاتی مانند تأخیر زیاد و متغیر می‌شود و گلوگاه‌های شبکه را برای همه جریان‌های دیگر خفه می‌کند زیرا بافر از بسته‌های یک جریان TCP پر می‌شود و بسته‌های دیگر حذف می‌شوند.

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

در مثال قبلی، استفاده از یک ابزار ردیابی پیشرفته به جای پینگ ساده (مثلا MTR) نه تنها وجود یک بافر متورم در گلوگاه را نشان می‌دهد، بلکه مکان آن را در شبکه نیز مشخص می‌کند. Traceroute با نمایش مسیر (مسیر) و اندازه‌گیری تاخیرهای انتقال بسته‌ها در سراسر شبکه به این امر دست می‌یابد. تاریخچه مسیر به عنوان زمان‌های رفت و برگشت بسته‌های دریافتی از هر میزبان متوالی (گره راه دور) در مسیر (مسیر) ثبت می‌شود.

سازوکار

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

بسته‌ها قبل از ارسال در یک بافر شبکه در صف قرار می‌گیرند. در شرایط مشکل ساز، بسته‌ها تنها در صورتی حذف می‌شوند که بافر پر باشد. در روترهای قدیمی‌تر، بافرها نسبتاً کوچک بودند بنابراین به سرعت پر می‌شدند و بنابراین بسته‌ها مدت کوتاهی پس از اشباع شدن پیوند شروع به افت کردند، بنابراین پروتکل TCP می‌توانست تنظیم شود و مشکل آشکار نمی‌شد. در روترهای جدیدتر، بافرها به اندازه ای بزرگ شده‌اند که می‌توانند چندین ثانیه از داده‌های بافر را در خود نگه دارند. از نظر TCP، یک پیوند متراکم به نظر می‌رسد که به‌طور معمول با پر شدن بافر کار می‌کند. الگوریتم TCP از متراکم بودن پیوند اطلاعی ندارد و تا زمانی که بافر در نهایت سرریز شود و بسته‌ها حذف نشوند، شروع به انجام اقدامات اصلاحی نمی‌کند.

تأثیر بر برنامه‌ها

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

هنگامی که پدیده بافربلوت وجود دارد و شبکه تحت بارگیری است، حتی بارگیری‌های عادی صفحه وب نیز ممکن است چندین ثانیه طول بکشد تا تکمیل شود، یا پرس و جوهای ساده DNS ممکن است به دلیل وقفه‌های زمانی با شکست مواجه شوند. در واقع، هر اتصال TCP می‌تواند به پایان برسد و قطع شود، و بسته‌های UDP ممکن است گم شوند. از آنجایی که ادامه جریان دانلود TCP به بسته‌های ACK در جریان آپلود بستگی دارد، مشکل بافر در آپلود می‌تواند باعث شکست سایر برنامه‌های دانلود غیرمرتبط شود، زیرا بسته‌های ACK مشتری به موقع به سرور اینترنت نمی‌رسند. به عنوان مثال، ممکن است سرعت انتقال آپلود همگام سازی OneDrive را به منظور ایجاد مزاحمت برای سایر کاربران شبکه خانگی، مانند گوش دادن به رادیو اینترنتی، محدود کنید.

راه حل‌ها و کاهش

چندین راه حل فنی وجود دارد که به‌طور کلی می‌توان آنها را به دو دسته دسته‌بندی کرد: راه حل‌هایی که شبکه را هدف قرار می‌دهند و راه حل‌هایی که نقاط پایانی را هدف قرار می‌دهند. این دو نوع راه حل اغلب مکمل هم هستند. مشکل گاهی اوقات با ترکیبی از مسیرهای سریع و کند شبکه ایجاد می‌شود.

راه حل‌های شبکه به‌طور کلی به شکل الگوریتم‌های مدیریت صف هستند. این نوع راه حل مورد توجه گروه کاری IETF AQM بوده‌است. نمونه‌های قابل توجه عبارتند از:

• محدود کردن طول صف IP
• الگوریتم‌های AQM
• AQM ترکیبی و الگوریتم‌های زمان‌بندی بسته‌ها
• اصلاحات استاندارد DOCSIS برای فعال کردن کنترل هوشمندتر بافر در مودم‌های کابلی.
• یکپارچه سازی مدیریت صف (FQ-CoDel) به وای فای زیر سیستم از لینوکس سیستم عامل لینوکس است که معمولاً در استفاده از نقاط دسترسی بی‌سیم.

نمونه‌های قابل توجهی از راه حل‌هایی که نقاط پایانی را هدف قرار می‌دهند عبارتند از:

• الگوریتم کنترل تراکم BBR برای TCP.
• پروتکل Micro Transport که توسط بسیاری از مشتریان BitTorrent استفاده می‌شود.
• تکنیک‌هایی برای استفاده از اتصالات کمتر، مانند لوله گذاری HTTP یا HTTP/2 به جای پروتکل HTTP ساده.

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

منابع

• December 31, 1985.
• van Beijnum, Iljitsch (۷ ژانویه ۲۰۱۱). "Understanding Bufferbloat and the Network Buffer Arms Race". Ars Technica. Retrieved November 12, 2011.
• Guido Appenzeller; Isaac Keslassy; Nick McKeown (2004). "Sizing Router Buffers" (PDF). ACM SIGCOMM. ACM. Retrieved October 15, 2013.
• Nichols, Kathleen; Jacobson, Van (۶ مه ۲۰۱۲). "Controlling Queue Delay". ACM Queue. ACM Publishing. Retrieved September 27, 2013.
• Gettys, Jim (May–June 2011). "Bufferbloat: Dark Buffers in the Internet". IEEE Internet Computing. 15 (3). IEEE: 95–96. doi:10.1109/MIC.2011.56. Archived from the original on October 12, 2012. Retrieved February 20, 2012.
• "traceroute(8) – Linux man page". die.net. Retrieved September 27, 2013.
• Jacobson, Van; Karels, MJ (1988). "Congestion avoidance and control" (PDF). ACM SIGCOMM Computer Communication Review. 18 (4): 314–329.
• "Technical Introduction to Bufferbloat". Bufferbloat.net. Retrieved September 27, 2013.
• Gettys, Jim; Nichols, Kathleen (ژانویه ۲۰۱۲). "Bufferbloat: Dark Buffers in the Internet". Communications of the ACM. 55 (1). ACM: 57–65.
• "Speed test - how fast is your internet?". dslreports.com. Retrieved October 26, 2017.
• berkeley.edu. Archived from the original on April 7, 2019. Retrieved January 30, 2015.
• Retrieved October 26, 2017.
• bufferbloat.net. Retrieved October 26, 2017.
• ietf.org. Retrieved October 26, 2017.
• Pan, Rong; Natarajan, Preethi; Piglione, Chiara; Prabhu, Mythili; Subramanian, Vijay; Baker, Fred; VerSteeg, Bill (2013). PIE: A Lightweight Control Scheme To Address the Bufferbloat Problem. 2013 IEEE 14th International Conference on High Performance Switching and Routing (HPSR). IEEE
• Høiland-Jørgensen, Toke; McKenney, Paul; Taht, Dave; Gettys, Jim; Dumazet, Eric
• CableLabs. pp. 554–556. Retrieved August 9, 2012.
• Høiland-Jørgensen, Toke; Kazior, Michał; Täht, Dave; Hurtig, Per; Brunstrom, Anna (2017). Ending the Anomaly: Achieving Low Latency and Airtime Fairness in WiFi. 2017 USENIX Annual Technical Conference (USENIX ATC 17). USENIX - The Advanced Computing Systems Association. pp. 139–151. ISBN 978-1-931971-38-6. Retrieved September 28, 2017
• Hein, Mathias. "Bufferbloat " ADMIN Magazine". ADMIN Magazine. Retrieved June 11, 2020.