Liiallinen verkon puskurointi ( eng. Bufferbloat - puskurin turpoaminen) on ilmiö, joka esiintyy pakettivälitteisissä verkoissa, kun liiallinen puskurointi lisää pakettien siirtoaikaa (latenssia) ja pakettien viiveen leviämistä (jitter) ja sen seurauksena pienenee. läpäisyssä. www.bufferbloat.net-projektissa tämä termi määriteltiin pilkallisesti "Internetin suorituskyvyn heikkenemiseksi, joka johtuu aikaisemmista yrityksistä parantaa sitä" [1] .
Termin Bufferbloat loi vuoden 2010 lopulla Jim Gettys Bell Labsista , W3C - komitean jäsen ja yksi HTTP/1.1-määrityksen toimittajista [2] .
Ylipuskuroinnin ongelma ilmenee, kun pakettien lähteestä määränpäähän lähtevällä polulla on laite, jossa on liian suuri puskuri. Puskureita on pääsääntöisesti lähes kaikissa verkkosolmuissa: kytkimissä, reitittimissä, käyttöjärjestelmäpinoissa jne. Ne on suunniteltu tallentamaan väliaikaisesti "ylimääräisiä" paketteja, jotta ne eivät katoa lähettäjän lähettäessä dataa solmulle sitä nopeammin. voi saada vastaanottajan. Tämä tapahtuu, kun lähettäjän kaistanleveys on suurempi kuin vastaanottajan. Puskurointi viivästyttää paketin lähetystä muutaman millisekunnin. Jos puskuri täyttyy, seuraava paketti hylätään. Ruuhkanhallintaprotokollat havaitsevat tämän lähettäjäpuolella ja vähentävät lähetysnopeutta. Dataa siirretään edelleen mahdollisimman suurella kaistanleveydellä.
Mutta jos puskuri jossain verkkosolmussa on liian suuri, se jatkaa pakettien keräämistä pitkään. Tämän pitkän tauon vuoksi ruuhkanhallintaalgoritmit menevät harhaan eivätkä toimi niin kuin pitäisi. Suuren ja muuttuvan pakettiviiveen ilmiö alkaa ilmaantua, verkon pullonkaulat "tukkeutuvat" ylimääräisistä paketeista yhdestä TCP-virrasta ja muut paketit hylätään. Siellä on ruuhkaa. Hetken kuluttua puskurit vapautetaan, sitten siirtonopeutta nostetaan, kunnes puskurit ovat taas täynnä, seuraavaan ruuhkaan asti.
Tavallisten käyttäjien näkökulmasta pääasialliset oireet liiallisesta verkkopuskuroinnista ovat, kun verkko on kuormitettu (siirretään paljon dataa), tavallisten verkkosivujen latautuminen kestää hyvin kauan (useita sekunteja tai jopa minuutteja) ; kaikki palvelut, jotka vaativat jatkuvaa kaistanleveyttä (joko korkea tai pieni), kuten VoIP, verkkopelit, chat, interaktiiviset sovellukset, kuten etäkäyttö, tulevat käyttökelvottomiksi. Priorisointimenetelmät (QoS), joissa tietylle liikenteelle luodaan erillinen pakettijono, eivät juurikaan ratkaise ongelmaa.
Liiallisen puskuroinnin ongelman aiheuttavat pääasiassa reitittimien, kytkimien valmistajat ja käyttöjärjestelmien kehittäjät, jotka ovat viime vuosina alkaneet asentaa laitteisiin liian suuria puskureita (useita megatavuja), mikä puolestaan johtuu jyrkästä muistin hinta.
Ongelma voidaan ratkaista yksinkertaisesti pienentämällä verkkolaitteiden puskurien kokoa. Sitä ei kuitenkaan ole määritetty useimpiin reitittimiin ja kytkimiin, varsinkin jos ne sijaitsevat tavallisten käyttäjien ulottumattomissa.
Liiallinen verkon puskurointi voi johtua mistä tahansa palvelusta tai toiminnasta verkossa, joka lähettää suuria määriä dataa tai suuria määriä paketteja verkon kautta. Heidän keskuudessaan:
Ilmiö voi esiintyä kaikkialla, missä puskurointi tapahtuu. Ensinnäkin solmuun syntyy ruuhkaa, jonka jälkeen on kapein kaistanleveys. Esimerkiksi:
Monet protokollat ja verkkopalvelut kärsivät ruuhkasta ja hitaista vasteajoista. Esimerkiksi:
Kuitenkin suuria verkkopuskureita tarvitaan käsittelemään oikein paketteja, joilla on suuri MTU , kuten jumbokehykset .
Verkkojen ruuhkautumisongelma on verkkojen vanha ongelma, joka on ollut olemassa niiden olemassaolon alkuajoista lähtien. Verkon ruuhkautuminen aiheuttaa suorituskyvyn heikkenemistä, pidentynyttä pakettien siirtoaikaa ja pakettien katoamista. Verkon ruuhkan seurauksena jotkin verkkopalvelut yksinkertaisesti lakkaavat toimimasta.
Ensimmäinen ilmentymä verkon ruuhkautumisesta suuressa mittakaavassa tapahtui vuonna 1986 NSFNetissä [3] . Vastauksena tähän tapahtumaan Van Jacobsonin ruuhkanhallintaprotokolla kehitettiin vuonna 1988 .
Internet jatkoi kasvuaan. Vuonna 1993 S. Floyd ja W. Jacobson kehittivät RED -algoritmin ( Random early detection - Arbitrary Early Detection) hallitsemaan reititinjonojen ylivuotoa [ 4] .
Vuonna 1997 julkaistiin RFC 2068 , joka muotoili "kahden yhteyden periaatteen": yhden asiakkaan tulisi käyttää enintään kahta yhteyttä samaan aikaan saman palvelimen kanssa [5] . Saman RFC:n mukaan tämä suositus annetaan "HTTP-vastausajan lyhentämiseksi ja Internetin tai muiden verkkojen liiallisen kuormituksen välttämiseksi."
Vuotta myöhemmin julkaistaan RFC 2309 , "Suositukset Internet-jonojen hallintaan ja ruuhkan välttämiseen", jossa ehdotetaan toimenpiteitä Internetin suorituskyvyn parantamiseksi ja säilyttämiseksi.
Vuonna 2001 julkaistiin RFC 3168 : " Explicit Congestion Notification (ECN) IP-osoitteeseen lisääminen", joka ehdotti ECN-kentän lisäämistä IP- ja TCP-paketteihin varaamalla tälle 2 bittiä.
Vuosina 2004-2007 Comcast, yksi Yhdysvaltojen suurimmista Internet-palveluntarjoajista, kärsii vaikeuksista verkon ruuhkautumisen vuoksi. Tästä ovat osoituksena Internetin toistuvat sulkemiset "raskaita" käyttäjiltä [6] . Ja vuonna 2007 Comcast Jim Gettisin mukaan "tukeutui" bittorrenteihin [7] . Yritystä on syytetty torrent-liikenteen estämisestä [8] [9] ja sitä jopa haastaa oikeuteen [10] .
Jim Getisin mukaan ensimmäinen henkilö, joka havaitsi verkon puskurointiongelman, oli Dave Clark [7] . Vuonna 2004 hän havaitsi tämän ilmiön DSLAM -laitteellaan ja käytti sitä luopumaan poikansa pelaamisesta pitkiä WOW -tunteja [11] .
Vuonna 2007 Jim Gettis itse alkaa saada valituksia perheeltään huonosta internetistä ja kokee laitteistovaurioita salamavirralla [7] .
Vuonna 2009 Dave Reed ilmoitti pakettien liian suuresta edestakaisen matka-ajasta (RTT) (jopa 30 sekuntia) ja pieni pakettihäviö 3G-verkoissa lähettämällä viestin täyden syklin postituslistalle. Jim Gettis itse tallensi 3G RTT -verkkoihin jopa 6 sekuntia.
Gettys saa edelleen perheeltä valituksia hitaasta internetistä. Huhtikuussa 2010 hän suoritti kaistanleveys/latenssitestin [12] . Testitulos osoitti, että pakettien odotusaika (viive) kasvaa pitkän tiedonsiirron myötä. Heinäkuun 15. päivänä 2010 Gettys kävi yhteisellä lounaalla Comcastin edustajien kanssa [13] , jossa ongelman syyksi ehdotettiin: liian suuret puskurit. Syytä puolestaan ehdotti yritykselle Dave Clark kaksi vuotta aiemmin, mutta yhtiö ei löytänyt todisteita tästä. Muita syitä puskurin paisumiseen: RED ei usein sisälly verkkoihin, koska se vaatii monimutkaisen konfiguroinnin; ECN:t on estetty joissakin verkoissa, koska ne kaatuvat kotireitittimiin.
Gettys jatkoi tutkimustaan tekemällä mittauksia kotona ja työmatkoilla. Syyskuun 20. päivän mittaus osoitti 8 sekunnin viiveen reitillä, joka kuljetetaan yleensä 10 ms:ssa [14] . Sitten Gettis toisti tämän muilla eri valmistajien reitittimillä.
Marraskuussa Gettys toisti ongelman useissa käyttöjärjestelmissä. Kävi ilmi, että Linuxissa ja Macissa tämä ongelma on helpompi toistaa kuin Windowsissa. Gettys päätteli: "käyttöjärjestelmien verkkopinoissa on jotain" [15] .
3. joulukuuta 2010 Jim Gettis julkaisee blogissaan artikkelin "The Criminal mastermind: bufferbloat!", jossa hän antaa tälle ilmiölle nimen - bufferbloat . Tässä ja myöhemmissä artikkeleissa Gettis puhuu ilmiön olemuksesta, esiintymispaikoista, syistä ja seurauksista [16] .
Robert Kringley, toimittaja, joka kirjoittaa InfoWorldille, artikkelissaan "Ennusteet 2011: Yksi sana - puskuroi. Vai onko se kaksi sanaa? ennustaa, että liiallinen verkon puskurointi on vuoden 2011 suurin ongelma [17] . Gettysin viitaten hän antaa kuvauksen ongelmasta. 3 päivää myöhemmin ars technica julkaisi Ilyich van Beinumin artikkelin, jossa hän huomautti, että jotkin Kringleyn kuvaamista yksityiskohdista olivat vääriä, mutta samalla vahvisti liiallisen verkon puskuroinnin ongelman [18] .
Wayback Machine -projekti www.bufferbloat.net arkistoitu 4. joulukuuta 2012 luotiin pian koordinoimaan asianomaisten henkilöiden toimia verkon liiallisen puskuroinnin ongelman ratkaisemiseksi. Hankkeen päätehtävät: