Bufferbloat

Bufferbloat – zjawisko nadmiernego opóźnienia w sieci komputerowej, wywołane przez zbyt duże bufory pakietów w routerach, modemach i innych urządzeniach sieciowych. Gdy łącze zostaje nasycone, pakiety zamiast być odrzucane gromadzą się w rozbudowanych kolejkach, co powoduje wzrost opóźnienia nawet o kilka rzędów wielkości, zwiększa jego zmienność (jitter) i obniża użyteczną przepustowość łącza.

Zjawisko dotyczy sytuacji, w której łącze o wysokiej przepustowości pozostaje praktycznie bezużyteczne dla zastosowań interaktywnych – telefonii internetowej, wideokonferencji, gier sieciowych czy zwykłego przeglądania stron – mimo że pomiar samej prędkości transmisji nie wykazuje nieprawidłowości. Klasyczny test prędkości mierzy bowiem, ile danych da się przesłać w jednostce czasu, a nie to, jak szybko sieć reaguje w trakcie przesyłania^[1].

Mechanizm opisano po raz pierwszy w 1985 roku^[2], jednak szerszą uwagę zwrócono na niego dopiero po 2009 roku, za sprawą prac Jima Gettysa i Kathleen Nichols^[3].

Większość algorytmów kontroli przeciążenia protokołu TCP wnioskuje o dostępnej przepustowości na podstawie utraty pakietów. Nadawca zwiększa tempo transmisji aż do momentu, w którym pakiety zaczynają ginąć, po czym je redukuje. Sygnałem zwrotnym jest zatem odrzucenie pakietu, a warunkiem poprawnego działania – odpowiednio szybkie dotarcie tego sygnału do nadawcy^[4].

Duży bufor ten sygnał tłumi. Pakiety, które w mniejszej kolejce zostałyby odrzucone, są przyjmowane i dostarczane – tyle że z coraz większym opóźnieniem. Z punktu widzenia algorytmu kontroli przeciążenia łącze nadal wygląda na niewysycone, więc nadawca dalej zwiększa tempo, pogłębiając zapełnienie bufora. Odrzucanie pakietów rozpoczyna się dopiero po całkowitym wypełnieniu kolejki, a więc znacznie później, niż powinno – i często na tyle gwałtownie, że algorytm interpretuje sytuację jako zmianę trasy połączenia i ponownie przechodzi w agresywną fazę poszukiwania punktu pracy^[1].

W prostym buforze zorganizowanym jako pojedyncza kolejka FIFO opóźnienie dotyka wszystkich przepływów przechodzących przez dane urządzenie, niezależnie od ich charakteru. Pojedyncze masowe pobieranie pliku potrafi w ten sposób zdegradować jakość wszystkich pozostałych połączeń, w tym korzystających z protokołu UDP, który własnej kontroli przeciążenia nie posiada^[1].

Wśród producentów sprzętu sieciowego przez lata obowiązywała reguła praktyczna, zgodnie z którą urządzenie powinno buforować co najmniej 250 ms ruchu przechodzącego przez interfejs. Dla interfejsu Gigabit Ethernet oznaczało to bufor rzędu 32 MB^[5]. Spadające ceny pamięci sprawiły, że projektanci nie mieli powodu, by rozmiary buforów ograniczać – większy bufor traktowano jako zabezpieczenie przed utratą danych, nie dostrzegając jego wpływu na opóźnienie^[3].

Późniejsze prace wykazały, że dobór rozmiaru oparty na tej regule jest nadmiarowy. Aby połączenia o największym opóźnieniu nadal otrzymywały sprawiedliwy udział w paśmie, rozmiar bufora powinien odpowiadać iloczynowi opóźnienia i przepustowości podzielonemu przez pierwiastek z liczby równoczesnych strumieni^[5]. W praktyce jako punkt odniesienia przyjmuje się około 50 ms transmisji przy pełnej prędkości łącza^[6].

Nadmiarowy bufor ujawnia swoje działanie wyłącznie wtedy, gdy obsługiwane przez niego łącze staje się wąskim gardłem.

Bufferbloat pogarsza działanie każdej usługi wymagającej niskiego i przewidywalnego opóźnienia, niezależnie od jej zapotrzebowania na pasmo. Dotyczy to rozmów głosowych, wideokonferencji, gier sieciowych, zdalnego dostępu do systemów oraz transmisji strumieniowych^[1].

Przy obciążonym łączu wydłuża się także czas otwierania zwykłych stron internetowych, a zapytania DNS mogą kończyć się przekroczeniem limitu czasu^[1]. Szczególne znaczenie ma zatkanie kierunku wysyłania: ponieważ ciągłość pobierania danych przez TCP zależy od terminowego powrotu potwierdzeń (ACK), przepełniony bufor w kierunku nadawania potrafi zablokować transmisje przychodzące, niezwiązane z aplikacją, która to obciążenie wywołała.

Podstawową metodą wykrywania bufferbloatu jest porównanie opóźnienia na łączu nieobciążonym z opóźnieniem mierzonym w trakcie jego nasycenia – wielkość ta bywa określana jako opóźnienie pod obciążeniem (ang. loaded latency). Wzrost czasu obiegu pakietu (round-trip time) w trakcie transmisji odpowiada w przybliżeniu rozmiarowi kolejki utrzymywanej w buforze, wyrażonemu w milisekundach. Pomiar wykonuje się osobno dla kierunku pobierania i wysyłania, co pozwala wskazać, po której stronie łącza występuje problem^[7].

Wynik samego testu przepustowości nie jest wystarczający do wykrycia zjawiska – łącze osiągające pełną deklarowaną prędkość może jednocześnie wykazywać wielokrotny wzrost opóźnienia w trakcie transmisji^[1].

Spośród narzędzia przeglądarkowych raportujących opóźnienie pod obciążeniem stosowane są m.in. Waveform Bufferbloat Test oraz testy prędkości udostępniane przez Cloudflare i Ookla. Do pomiarów szczegółowych, wykorzystywanych w badaniach nad algorytmami zarządzania kolejką, służą narzędzia wiersza poleceń, takie jak flent i irtt^[7].

Dwa narzędzia szeroko cytowane w starszej literaturze nie są już dostępne: ICSI Netalyzr zakończył działanie w marcu 2019 roku, a test DSLReports Speedtest – 26 marca 2025 roku.

Stosowane rozwiązania dzielą się na te działające w sieci oraz te wdrażane w urządzeniach końcowych; oba podejścia wzajemnie się uzupełniają.

Podstawowym narzędziem jest aktywne zarządzanie kolejką (ang. active queue management, AQM), czyli algorytmy sterujące zawartością bufora przed jego całkowitym wypełnieniem. Najstarszym rozwiązaniem tego typu jest RED, a pracami nad kolejnymi zajmowała się grupa robocza AQM organizacji IETF. Do najważniejszych należą:

• CoDel (Controlled Delay) – algorytm sterujący czasem przebywania pakietu w kolejce zamiast jej długością^[8];
• PIE (Proportional Integral controller Enhanced) – rozwiązanie o zbliżonym celu, opracowane z myślą o sprzęcie operatorskim^[9];
• FQ-CoDel – połączenie CoDel ze sprawiedliwym szeregowaniem przepływów, dzięki któremu pojedyncza transmisja masowa nie degraduje pozostałych^[10];
• CAKE (Common Applications Kept Enhanced) – kompleksowe rozwiązanie dla routerów domowych, obecne w jądrze systemu Linux jako sch_cake i stosowane jako domyślny mechanizm ograniczania kolejki w systemie OpenWrt^[11];
• L4S (Low Latency, Low Loss, Scalable Throughput) – architektura oparta na rozszerzonej semantyce Explicit Congestion Notification i podwójnej kolejce, pozwalająca sygnalizować przeciążenie bez odrzucania pakietów^[12][13].

Rozwiązania te wdrażane są także w standardach dostępowych – w specyfikacji DOCSIS w postaci mechanizmu Low Latency DOCSIS^[14], a w sieciach Wi-Fi przez integrację FQ-CoDel z podsystemem bezprzewodowym jądra Linuksa^[15].

• algorytm kontroli przeciążenia BBR, szacujący przepustowość i opóźnienie zamiast opierać się na utracie pakietów; podlega standaryzacji w IETF^[16];
• protokół Micro Transport Protocol (µTP), stosowany przez klienty BitTorrent, ustępujący pasma ruchowi interaktywnemu;
• ograniczanie liczby równoczesnych połączeń, m.in. przez zastosowanie protokołu HTTP/2 zamiast wielu równoległych połączeń HTTP^[1].

Pomocnicze znaczenie ma także różnicowanie klas ruchu, pozwalająca priorytetyzować transmisje wrażliwe na opóźnienie kosztem ruchu masowego^[17]. Samo zmniejszenie rozmiaru buforów jest rozwiązaniem ograniczonym – optymalna wielkość zależy od prędkości łącza, która dla różnych tras bywa różna, a w sprzęcie konsumenckim parametr ten zwykle nie jest konfigurowalny^[1].

Problem nadmiernego buforowania opisał w 1985 roku John Nagle, autor algorytmu Nagle'a, w dokumencie On Packet Switches with Infinite Storage. Wskazał w nim, że węzeł sieci o nieograniczonej pamięci nie eliminuje przeciążenia, lecz zamienia utratę pakietów na nieograniczony wzrost opóźnienia^[2].

Do szerszej świadomości zjawisko trafiło dopiero po 2009 roku. Termin bufferbloat ukuł Jim Gettys, który wraz z Kathleen Nichols i Vanem Jacobsonem opisał je w publikacjach IEEE i ACM oraz zainicjował projekt Bufferbloat.net, skupiający prace nad algorytmami zarządzania kolejką^[3][1]. Efektem tych prac były algorytmy CoDel i FQ-CoDel, a następnie standaryzacja rozwiązań AQM w IETF.

• Random early detection
• Algorytm Nagle'a
• Quality of service
• Jakość doświadczenia
• Jitter