بافربلات
بافربلات علت تأخیر و لرزش زیاد در شبکه‌های سوئیچ بسته به دلیل بافر بیش از حد بسته‌ها است. بافربلات همچنین می‌تواند باعث تغییرات تأخیر بسته (همچنین به عنوان جیتر) شود و همچنین باعث کاهش توان عملیاتی شبکه شود. هنگامی که یک روتر یا سوئیچ برای استفاده از بافرهای بسیار بزرگ پیکربندی شده‌است، حتی شبکه‌های پرسرعت می‌توانند عملاً برای بسیاری از برنامه‌های تعاملی مانند صدا از طریق IP (VoIP)، پخش صدا، بازی آنلاین و حتی مرورگر وب معمولی غیرقابل استفاده شوند.
برخی از تولیدکنندگان تجهیزات ارتباطی، بافرهای بزرگ غیرضروری را در برخی از محصولات شبکه خود طراحی کردند. در چنین تجهیزاتی، بافربلات زمانی اتفاق می‌افتد که یک پیوند شبکه متراکم می‌شود و باعث می‌شود بسته‌ها برای مدت طولانی در این بافرهای بزرگ در صف قرار گیرند. در یک سیستم صف اول ورودی اول، بافرهای بیش از حد بزرگ منجر به صف‌های طولانی‌تر و تأخیر بیشتر می‌شود و توان عملیاتی شبکه را بهبود نمی‌بخشد. همچنین می‌تواند توسط اتصالات با سرعت آهسته خاص ایجاد شود که مانع از تحویل به موقع سایر بسته‌ها می‌شود.
پدیده بافربلات در اوایل سال ۱۹۸۵ توصیف شد. از سال ۲۰۰۹ توجه گسترده‌تری را به خود جلب کرد.
یک قانون کلی ثابت شده برای تولیدکنندگان تجهیزات شبکه این بود که بافرهایی به اندازه کافی برای گنجاندن حداقل ۲۵۰ میلی‌ثانیه بافر برای جریان ترافیکی که از یک دستگاه می‌گذرد فراهم کنند. برای مثال، رابط اترنت گیگابیتی روتر به یک بافر نسبتاً بزرگ ۳۲ مگابایتی نیاز دارد. چنین اندازه‌گیری بافرها می‌تواند منجر به شکست الگوریتم کنترل تراکم TCP شود. سپس تخلیه بافرها مدتی طول می‌کشد، قبل از اینکه کنترل ازدحام بازنشانی شود و اتصال TCP به سرعت بالا برود و دوباره بافرها را پر کند. بنابراین بافربلات باعث ایجاد مشکلاتی مانند تأخیر زیاد و متغیر می‌شود و گلوگاه‌های شبکه را برای همه جریان‌های دیگر خفه می‌کند زیرا بافر از بسته‌های یک جریان TCP پر می‌شود و بسته‌های دیگر حذف می‌شوند.
بافر متورم تنها زمانی اثر می‌گذارد که این بافر واقعاً استفاده شود. به عبارت دیگر، بافرهای بزرگ تنها زمانی اثر مخرب دارند که پیوندی که بافر می‌کنند به گلوگاه تبدیل می‌شود.. اندازه بافری که به یک گلوگاه خدمت می‌کند را می‌توان با استفاده از ابزار پینگ ارائه شده توسط اکثر سیستم عامل‌ها اندازه‌گیری کرد. ابتدا، میزبان دیگر باید به‌طور مداوم پینگ شود. سپس، دانلود چند ثانیه ای از آن باید شروع شود و چند بار متوقف شود. با طراحی، الگوریتم اجتناب از تراکم TCP به سرعت گلوگاه مسیر را پر می‌کند. اگر دانلود (و آپلود، به ترتیب) با افزایش مستقیم و مهم زمان رفت و برگشت گزارش شده توسط پینگ مرتبط باشد، نشان می‌دهد که بافر گلوگاه فعلی در جهت دانلود (و آپلود، به ترتیب) متورم است. از آنجایی که افزایش زمان رفت و برگشت ناشی از بافر روی گلوگاه است، حداکثر افزایش تخمین تقریبی اندازه آن را بر حسب میلی ثانیه می‌دهد.
در مثال قبلی، استفاده از یک ابزار ردیابی پیشرفته به جای پینگ ساده (مثلا MTR) نه تنها وجود یک بافر متورم در گلوگاه را نشان می‌دهد، بلکه مکان آن را در شبکه نیز مشخص می‌کند. Traceroute با نمایش مسیر (مسیر) و اندازه‌گیری تاخیرهای انتقال بسته‌ها در سراسر شبکه به این امر دست می‌یابد. تاریخچه مسیر به عنوان زمان‌های رفت و برگشت بسته‌های دریافتی از هر میزبان متوالی (گره راه دور) در مسیر (مسیر) ثبت می‌شود.
اکثر الگوریتم‌های کنترل تراکم TCP برای تعیین پهنای باند موجود بین دو انتهای یک اتصال، بر اندازه‌گیری وقوع افت بسته تکیه می‌کنند. الگوریتم‌ها انتقال داده را تا زمانی که بسته‌ها شروع به افت کنند سرعت می‌بخشند، سپس سرعت انتقال را کاهش می‌دهند. در حالت ایده‌آل، آنها به تنظیم نرخ انتقال ادامه می‌دهند تا زمانی که به سرعت تعادل پیوند برسد. به طوری که الگوریتم‌ها بتوانند سرعت انتقال مناسبی را انتخاب کنند، بازخورد در مورد افت بسته‌ها باید به موقع رخ دهد. با یک بافر بزرگ که پر شده‌است، بسته‌ها به مقصد خود می‌رسند، اما با تأخیر بالاتر. بسته‌ها رها نشدند، بنابراین TCP پس از اشباع شدن لینک بالا کند نمی‌شود و بافر را بیشتر پر می‌کند. بسته‌های تازه‌وارد تنها زمانی که بافر کاملاً اشباع شده‌است، حذف می‌شوند. هنگامی که این اتفاق می‌افتد TCP حتی ممکن است تصمیم بگیرد که مسیر اتصال تغییر کرده‌است و دوباره به جستجوی تهاجمی تر برای یک نقطه عملیاتی جدید بپردازد.
بسته‌ها قبل از ارسال در یک بافر شبکه در صف قرار می‌گیرند. در شرایط مشکل ساز، بسته‌ها تنها در صورتی حذف می‌شوند که بافر پر باشد. در روترهای قدیمی‌تر، بافرها نسبتاً کوچک بودند بنابراین به سرعت پر می‌شدند و بنابراین بسته‌ها مدت کوتاهی پس از اشباع شدن پیوند شروع به افت کردند، بنابراین پروتکل TCP می‌توانست تنظیم شود و مشکل آشکار نمی‌شد. در روترهای جدیدتر، بافرها به اندازه ای بزرگ شده‌اند که می‌توانند چندین ثانیه از داده‌های بافر را در خود نگه دارند. از نظر TCP، یک پیوند متراکم به نظر می‌رسد که به‌طور معمول با پر شدن بافر کار می‌کند. الگوریتم TCP از متراکم بودن پیوند اطلاعی ندارد و تا زمانی که بافر در نهایت سرریز شود و بسته‌ها حذف نشوند، شروع به انجام اقدامات اصلاحی نمی‌کند.
صرف نظر از الزامات پهنای باند، هر نوع سرویسی که به تأخیر پیوسته کم یا انتقال بدون لرزش نیاز دارد، می‌تواند تحت تأثیر بافربلات قرار گیرد. به عنوان مثال می‌توان به تماس‌های صوتی، بازی‌های آنلاین، چت ویدیویی و سایر برنامه‌های تعاملی مانند پیام‌رسانی فوری، پخش رادیو، ویدیوی درخواستی، و ورود از راه دور اشاره کرد.
هنگامی که پدیده بافربلات وجود دارد و شبکه تحت بارگیری است، حتی بارگیری‌های عادی صفحه وب نیز ممکن است چندین ثانیه طول بکشد تا تکمیل شود، یا پرس و جوهای ساده DNS ممکن است به دلیل وقفه‌های زمانی با شکست مواجه شوند. در واقع، هر اتصال TCP می‌تواند به پایان برسد و قطع شود، و بسته‌های UDP ممکن است گم شوند. از آنجایی که ادامه جریان دانلود TCP به بسته‌های ACK در جریان آپلود بستگی دارد، مشکل بافر در آپلود می‌تواند باعث شکست سایر برنامه‌های دانلود غیرمرتبط شود، زیرا بسته‌های ACK مشتری به موقع به سرور اینترنت نمی‌رسند. به عنوان مثال، ممکن است سرعت انتقال آپلود همگام سازی OneDrive را به منظور ایجاد مزاحمت برای سایر کاربران شبکه خانگی، مانند گوش دادن به رادیو اینترنتی، محدود کنید.
چندین راه حل فنی وجود دارد که به‌طور کلی می‌توان آنها را به دو دسته دسته‌بندی کرد: راه حل‌هایی که شبکه را هدف قرار می‌دهند و راه حل‌هایی که نقاط پایانی را هدف قرار می‌دهند. این دو نوع راه حل اغلب مکمل هم هستند. مشکل گاهی اوقات با ترکیبی از مسیرهای سریع و کند شبکه ایجاد می‌شود.
راه حل‌های شبکه به‌طور کلی به شکل الگوریتم‌های مدیریت صف هستند. این نوع راه حل مورد توجه گروه کاری IETF AQM بوده‌است. نمونه‌های قابل توجه عبارتند از:
نمونه‌های قابل توجهی از راه حل‌هایی که نقاط پایانی را هدف قرار می‌دهند عبارتند از:
این مشکل همچنین ممکن است با کاهش اندازه بافر در سیستم عامل و سخت‌افزار شبکه کاهش یابد. با این حال، این اغلب قابل تنظیم نیست و اندازه بافر بهینه به نرخ خط بستگی دارد که ممکن است برای مقاصد مختلف متفاوت باشد.