Softver otvorenog koda postao je temelj za neke od najvećih web stranica. Kako su ove web stranice rasle, pojavile su se najbolje prakse i smjernice za njihovu arhitekturu. Ovo poglavlje ima za cilj pokriti neka od ključnih pitanja koja treba uzeti u obzir prilikom dizajniranja velikih web stranica, kao i neke od osnovnih komponenti koje se koriste za postizanje ovih ciljeva.

Fokus ovog poglavlja je na analizi web sistema, iako se dio materijala može ekstrapolirati na druge distribuirane sisteme.

1.1 Principi izgradnje distribuiranih web sistema

Šta tačno znači kreirati i upravljati skalabilnom web lokacijom ili aplikacijom? Na primitivnom nivou, ovo je jednostavno povezivanje korisnika sa udaljenim resursima preko Interneta. I resursi ili pristup tim resursima, koji su raspoređeni po mnogim serverima i predstavljaju vezu koja osigurava skalabilnost web stranice.

Kao i većina stvari u životu, odvajanje vremena za planiranje unaprijed za izgradnju web servisa može biti daleko; razumijevanje nekih razmatranja i kompromisa iza velikih web stranica može se isplatiti u obliku pametnijih odluka pri izradi manjih web stranica. Ispod su neki od ključnih principa koji upravljaju dizajnom velikih web sistema:

• Dostupnost: Vrijeme rada web stranice ključno je za reputaciju i funkcionalnost mnogih kompanija. Za neke od većih maloprodajnih objekata na mreži, nedostupnost čak i nekoliko minuta može rezultirati hiljadama ili milionima dolara gubitka prihoda. Stoga je razvoj sistema koji su stalno dostupni i otporni na kvar i osnovni poslovni i tehnološki zahtjev. Visoka dostupnost u distribuiranim sistemima zahtijeva pažljivo razmatranje redundanse za ključne komponente, brz oporavak od djelomičnih kvarova sistema i glatko smanjenje kapaciteta kada se pojave problemi.
• Performanse: Učinak web stranice postao je važan pokazatelj za većinu web stranica. Brzina web stranice utiče na korisničko iskustvo i zadovoljstvo, kao i na rangiranje na pretraživačima – faktor koji direktno utiče na zadržavanje publike i prihod. Kao rezultat toga, ključ je stvoriti sistem koji je optimiziran za brze odgovore i nisko kašnjenje.
• Pouzdanost: sistem mora biti robustan, tako da će dati zahtjev za podacima konzistentno vraćati određene podatke. U slučaju promjene ili ažuriranja podataka, isti upit mora vratiti nove podatke. Korisnici moraju znati da ako se nešto upiše ili pohrani u sistem, onda možete biti sigurni da će to ostati na svom mjestu kako bi se podaci kasnije mogli preuzeti.
• Skalabilnost: Kada je u pitanju bilo koji veliki distribuirani sistem, veličina je samo jedna stavka na listi koju treba uzeti u obzir. Jednako važni su napori da se poveća propusnost za rukovanje velikim količinama posla, što se obično naziva skalabilnost sistema. Skalabilnost se može odnositi na različite parametre sistema: količinu dodatnog saobraćaja koji može da obradi, koliko je lako proširiti kapacitet skladištenja ili koliko se više drugih transakcija može obraditi.
• Upravljivost: dizajniranje sistema koji je jednostavan za rukovanje je još jedan važan faktor. Upravljivost sistema je jednaka skalabilnosti operacija "održavanja" i "nadogradnje". Upravljivost mora uzeti u obzir lakoću dijagnosticiranja i razumijevanja problema koji se pojavljuju, lakoću ažuriranja ili modifikacije i hiroviti sistem u radu (tj. da li radi kao očekivano bez kvarova ili izuzetaka?)
• Cijena: Trošak je važan faktor. Ovo očigledno može uključivati ​​troškove hardvera i softvera, ali je takođe važno uzeti u obzir druge aspekte potrebne za implementaciju i održavanje sistema. Potrebno je uzeti u obzir količinu vremena programera koji je potreban za izgradnju sistema, količinu operativnog napora potrebnog da se sistem pokrene, pa čak i dovoljan nivo obuke. Trošak predstavlja ukupan trošak vlasništva.

Svaki od ovih principa je osnova za donošenje odluka u dizajnu distribuirane web arhitekture. Međutim, mogu biti i u sukobu jedni s drugima, jer postizanje ciljeva jednog dolazi na račun zanemarivanja drugih. Jednostavan primjer: odabir jednostavnog dodavanja više servera kao rješenja za performanse (skalabilnost) može povećati cijenu upravljivosti (morate pokrenuti dodatni server) i kupovinu servera.

Prilikom razvoja bilo koje vrste web aplikacije, važno je uzeti u obzir ove ključne principe, čak i ako se želi potvrditi da projekat može žrtvovati jedan ili više njih.

1.2 Osnove

Kada se razmatra arhitektura sistema, postoji nekoliko pitanja koja se moraju pozabaviti, kao što su koje komponente koristiti, kako se uklapaju i koji kompromisi se mogu napraviti. Ulaganje u skaliranje bez jasne potrebe za tim nije pametna poslovna odluka. Međutim, određeno predviđanje u planiranju može uštedjeti mnogo vremena i resursa u budućnosti.

Ovaj dio se fokusira na neke osnovne faktore koji su bitni za gotovo sve velike web aplikacije: Usluge,
redundantnost, segmentacija, i rukovanje kvarovima. Svaki od ovih faktora uključuje izbore i kompromise, posebno u kontekstu principa opisanih u prethodnom dijelu. Da pojasnimo, uzmimo primjer.

Primjer: Aplikacija za hostovanje slika

Vjerovatno ste ranije postavljali slike na internet. Za velike web lokacije koje pohranjuju i isporučuju mnogo slika, postoje izazovi u stvaranju isplative, visoko pouzdane arhitekture koju karakteriziraju niske latencije odgovora (brzo pronalaženje).

Zamislite sistem u kojem korisnici mogu učitati svoje slike na centralni server, a slike se mogu zatražiti putem linka na web-stranici ili API-ja, slično kao Flickr ili Picasa. Da bismo pojednostavili opis, pretpostavimo da ova aplikacija ima dva glavna zadatka: mogućnost upload-ovanja (pisanja) slika na server i traženje slika. Naravno, efikasno učitavanje je važan kriterij, ali prioritet će biti brza isporuka na zahtjev korisnika (na primjer, može se tražiti da se slike prikažu na web stranici ili drugoj aplikaciji). Ova funkcionalnost je slična onome što web server ili rubni server mreže za isporuku sadržaja (CDN) može pružiti. CDN server obično pohranjuje objekte podataka na mnogo lokacija, tako da je njihova geografska/fizička lokacija bliža korisnicima, što rezultira boljim performansama.

Ostali važni aspekti sistema:

• Broj pohranjenih slika može biti neograničen, pa se s ove tačke gledišta mora razmotriti skalabilnost pohrane.
• Trebalo bi postojati malo kašnjenje za preuzimanje/zahtjeve slika.
• Ako korisnik postavi sliku na server, tada njegovi podaci moraju uvijek ostati netaknuti i dostupni.
• Sistem treba da bude lak za održavanje (upravljanje).
• Pošto hosting slika nije baš isplativ, sistem mora biti isplativ.

Još jedan potencijalni problem s ovim dizajnom je taj što web server kao što je Apache ili lighttpd obično ima gornju granicu broja istovremenih veza koje može poslužiti (podrazumevana vrijednost je oko 500, ali može biti i mnogo veća) i sa velikim prometom, piše može brzo iskoristiti ovo ograničenje. Budući da čitanje može biti asinkrono ili iskoristiti prednosti drugih optimizacija performansi kao što je gzip kompresija ili chunking, web server može brže prebacivati ​​čitanje feedova i prebacivati ​​se između klijenata, služeći mnogo više zahtjeva od maksimalnog broja veza (sa Apacheom i s maksimalnim brojem veze postavljene na 500, sasvim je moguće poslužiti nekoliko hiljada zahtjeva za čitanje u sekundi). Pisanje, s druge strane, ima tendenciju da drži vezu otvorenom tokom preuzimanja. Dakle, prijenos datoteke od 1 MB na server može potrajati više od 1 sekunde na većini kućnih mreža, što rezultira time da web server može obraditi samo 500 ovih simultanih upisa.

Slika 1.2: Razdvajanje čitanja i pisanja

Predviđanje ovakvog potencijalnog problema ukazuje na potrebu odvajanja čitanja i pisanja slika u nezavisne servise, prikazane u . Ovo ne samo da će nam omogućiti da skaliramo svaki od njih pojedinačno (pošto je vjerovatno da ćemo uvijek raditi više čitanja nego pisanja), već i da budemo svjesni šta se dešava u svakom servisu. Konačno, to će ocrtati probleme koji se mogu pojaviti u budućnosti, što olakšava dijagnosticiranje i procjenu problema sporog pristupa čitanju.

Prednost ovog pristupa je u tome što smo u mogućnosti rješavati probleme nezavisno jedan od drugog - bez potrebe da razmišljamo o potrebi pisanja i preuzimanja novih slika u istom kontekstu. Obje ove usluge i dalje koriste globalni korpus slika, ali korištenjem metoda specifičnih za uslugu, oni su u mogućnosti da optimiziraju svoje vlastite performanse (na primjer, stavljanjem zahtjeva u red čekanja ili keširanjem popularnih slika - više o tome kasnije). I u smislu održavanja i troškova, svaka usluga se može samostalno skalirati prema potrebi. A ovo je pozitivan faktor, jer njihovo kombiniranje i miješanje može nenamjerno utjecati na njihov učinak, kao u gore opisanom scenariju.

Naravno, rad gornjeg modela će biti optimalan ako postoje dvije različite krajnje točke (u stvari, ovo je vrlo slično nekoliko implementacija dobavljača usluga skladištenja u oblaku i mreža za isporuku sadržaja). Postoji mnogo načina za rješavanje takvih problema i u svakom slučaju se može naći kompromis.

Na primjer, Flickr rješava ovaj problem čitanja i pisanja distribucijom korisnika na različite podove tako da svaki pod može opsluživati ​​samo ograničen broj definiranih korisnika, a kako se broj korisnika povećava, više podova se dodaje u klaster (pogledajte Flickrovu prezentaciju skaliranja ,
http://mysqldba.blogspot.com/2008/04/mysql-uc-2007-presentation-file.html). U prvom primjeru, lakše je skalirati hardver na osnovu stvarnog opterećenja (broj čitanja i upisivanja u cijelom sistemu), dok Flickr mjeri na osnovu korisničke baze (međutim, koristi pretpostavku o ravnomjernoj upotrebi među različitim korisnicima , pa kapacitet treba planirati sa rezervom). U prošlosti je nedostupnost ili problem sa jednom od usluga onemogućavao funkcionalnost cijelog sistema (na primjer, niko ne može pisati fajlove), a onda će nedostupnost jednog od Flickr modula uticati samo na korisnike koji su s njim povezani. U prvom primjeru, lakše je izvoditi operacije na cijelom skupu podataka - na primjer, ažurirati uslugu snimanja da uključi nove metapodatke ili pretraživati ​​sve metapodatke slike - dok je kod Flickrove arhitekture svaki modul morao biti ažuriran ili pretraživan ( ili je morao biti kreiran servis za pretraživanje da sortira metapodatke koji su zapravo namijenjeni za ovu svrhu).

Što se tiče ovih sistema, nema leka, ali uvek treba poći od principa opisanih na početku ovog poglavlja: odrediti potrebe sistema (učitavanje operacijama „čitanja“ ili „pisanja“ ili sve odjednom, nivo paralelizma , upiti o skupovima podataka, rasponima, trijaži, itd.), usporedite različite alternative jedna s drugom, razumiju potencijalne uslove kvara sistema i razviju sveobuhvatan plan u slučaju kvara.

Redundantnost

Da bi graciozno riješila neuspjeh, web arhitektura mora imati redundantnost u svojim uslugama i podacima. Na primjer, ako postoji samo jedna kopija datoteke pohranjena na jednom serveru, gubitak tog servera bi značio gubitak datoteke. Malo je vjerovatno da se takva situacija može pozitivno okarakterizirati, a obično se može izbjeći stvaranjem višestrukih ili rezervnih kopija.

Isti princip važi i za usluge. Od kvara jednog čvora može se zaštititi obezbjeđivanjem integralnog dijela funkcionalnosti za aplikaciju kako bi se osiguralo da više kopija ili verzija iste radi u isto vrijeme.

Kreiranje redundantnosti u sistemu omogućava vam da se riješite slabosti i pružite rezervnu ili redundantnu funkcionalnost u slučaju nužde. Na primjer, ako postoje dvije instance iste usluge koje su pokrenute u proizvodnji, a jedna od njih u potpunosti ili djelimično zakaže, sistem može prevladati kvar tako što prelazak na radnu instancu.
Prebacivanje može biti automatsko ili zahtijevati ručnu intervenciju.

Druga ključna uloga redundantnosti usluge je stvaranje arhitektura dijeljenja resursa. Sa ovom arhitekturom, svaki čvor je u stanju da radi nezavisno i, štaviše, u odsustvu centralnog „mozga“ koji upravlja stanjima ili koordinira radnje drugih čvorova. Promoviše skalabilnost, budući da dodavanje novih čvorova ne zahtijeva posebne uslove ili znanje. I što je najvažnije, ne postoji kritična tačka kvara u ovim sistemima, što ih čini mnogo otpornijim na kvar.

Na primjer, u našoj aplikaciji servera za slike, sve slike bi imale suvišne kopije negdje u drugom komadu hardvera (idealno s drugom geografskom lokacijom u slučaju katastrofe kao što je potres ili požar u podatkovnom centru), a usluge pristupa slikama bi bile suvišan, s obzirom da bi svi oni potencijalno služili zahtjevima. (Cm. .)
Gledajući unaprijed, balanseri opterećenja su odličan način da se to omogući, ali više o tome u nastavku.

Slika 1.3: Aplikacija za hostovanje slika sa redundantnošću

Segmentacija

Skupovi podataka mogu biti toliko veliki da ne mogu biti smješteni na jednom serveru. Takođe se može desiti da računarske operacije zahtevaju previše računarskih resursa, smanjujući performanse i čineći neophodnim povećanje snage. U svakom slučaju, imate dvije opcije: vertikalno ili horizontalno skaliranje.

Vertikalno skaliranje uključuje dodavanje više resursa na jedan server. Dakle, za vrlo veliki skup podataka, to bi značilo dodavanje više (ili više) tvrdih diskova, i na taj način bi cijeli skup podataka mogao stati na jedan server. U slučaju računskih operacija, to bi značilo premještanje računala na veći server sa bržim CPU-om ili više memorije. U svakom slučaju, vertikalno skaliranje se vrši kako bi se jedan resurs računarskog sistema učinio sposobnim za dodatnu obradu podataka.

Horizontalno skaliranje, s druge strane, uključuje dodavanje više čvorova. U slučaju velikog skupa podataka, to bi značilo dodavanje drugog servera za pohranjivanje dijela ukupnih podataka, a za računski resurs, to bi značilo podjelu rada ili opterećenja kroz neke dodatne čvorove. Da bi se u potpunosti iskoristio potencijal horizontalnog skaliranja, ono mora biti implementirano kao interni princip dizajna arhitekture sistema. Inače, promjena i isticanje konteksta potrebnog za horizontalno skaliranje može biti problematično.

Najčešći način skaliranja je segmentiranje usluga u dijelove ili podove. Mogu se distribuirati na način da svaki logički skup funkcionalnosti radi zasebno. To se može učiniti geografskim granicama ili drugim kriterijima kao što su korisnici koji plaćaju i koji ne plaćaju. Prednost ovih šema je što pružaju uslugu ili skladište podataka sa poboljšanom funkcionalnošću.

U našem primjeru servera slika, moguće je da jedan server datoteka koji se koristi za pohranu slike može biti zamijenjen sa više servera datoteka, od kojih svaki sadrži svoj jedinstveni skup slika. (Vidi .) Ova arhitektura će omogućiti sistemu da popuni svaki server datoteka slikama, dodajući dodatne servere kako se prostor na disku popunjava. Dizajn će zahtijevati šemu imenovanja koja će povezati ime datoteke slike sa serverom koji ga sadrži. Ime slike se može formirati iz konzistentne šeme heširanja povezane sa serverima. Ili alternativno, svaka slika može imati inkrementalni ID, koji bi omogućio službi isporuke, kada zahtijeva sliku, da obradi samo raspon ID-ova povezanih sa svakim serverom (kao indeks).

Slika 1.4: Aplikacija za hostovanje slika sa redundantnošću i segmentacijom

Naravno, postoje poteškoće u distribuciji podataka ili funkcionalnosti na više servera. Jedno od ključnih pitanja je lokacija podataka; u distribuiranim sistemima, što su podaci bliži tački operacije ili tački računanja, to je bolje performanse sistema. Stoga je distribucija podataka na više servera potencijalno problematična, budući da svaki put kada podaci mogu biti potrebni, postoji rizik da možda neće biti dostupni na lokaciji potražnje, server će morati izvršiti skupo preuzimanje potrebnih informacija preko mreža.

Još jedan potencijalni problem javlja se u formi
nedosljednosti (nedosljednosti) Kada različite usluge čitaju i pišu u zajednički resurs, potencijalno drugu uslugu ili skladište podataka, postoji mogućnost "uslova trke" - gdje se smatra da su neki podaci ažurirani u trenutno stanje, ali u stvarnosti se čitaju prije stvarnog stanja. vrijeme - u tom slučaju podaci su nedosljedni. Na primjer, u scenariju hostinga slika, uvjet utrke može se pojaviti ako je jedan klijent poslao zahtjev za ažuriranje slike psa sa naslovom "Dog" promijenjenim u "Gizmo" dok je drugi klijent čitao sliku. U takvoj situaciji nije jasno koji bi naslov, "Pas" ili "Gizmo", dobio drugi klijent.

Postoje, naravno, neke prepreke povezane s dijeljenjem podataka, ali dijeljenje omogućava da se svaki problem razlikuje od ostalih: po podacima, po opterećenju, obrascima korištenja itd. u upravljive blokove. Ovo može pomoći u skalabilnosti i upravljivosti, ali rizik je i dalje prisutan. Postoji mnogo načina za ublažavanje rizika i rješavanje kvarova; međutim, u interesu kratkoće, oni nisu obuhvaćeni u ovom poglavlju. Ako želite više informacija o ovoj temi, trebali biste pogledati blog o toleranciji grešaka i praćenju.

1.3. Strukturne komponente brzog i skalabilnog pristupa podacima

Pošto smo pokrili neke osnovne principe u razvoju distribuiranih sistema, pređimo sada na težu tačku - skaliranje pristupa podacima.

Najjednostavnije web aplikacije, kao što su LAMP stack aplikacije, slične su slici u .

Slika 1.5: Jednostavne web aplikacije

Kako aplikacija raste, pojavljuju se dva glavna izazova: skaliranje pristupa poslužitelju aplikacija i bazi podataka. U visoko skalabilnom dizajnu aplikacije, web server ili poslužitelj aplikacija obično je minimiziran i često implementira arhitekturu bez dijeljenja. Ovo čini sloj aplikacijskog servera sistema horizontalno skalabilnim. Kao rezultat korišćenja ovog dizajna, naporan rad će se prebaciti niz stog na server baze podataka i usluge podrške; ovdje dolaze u obzir stvarni problemi skaliranja i performansi.

Ostatak ovog poglavlja fokusira se na neke od uobičajenih strategija i tehnika za poboljšanje performansi i skalabilnosti ovih vrsta usluga pružanjem brzog pristupa podacima.

Slika 1.6: Pojednostavljena web aplikacija

Većina sistema se može pojednostaviti na dijagram na,
što je dobra polazna tačka za razmatranje. Ako imate puno podataka, može se pretpostaviti da želite imati isti lak pristup i brz pristup kao i kutiji lizalica u gornjoj ladici vašeg stola. Iako je ovo poređenje previše pojednostavljeno, ono ukazuje na dva teška pitanja: skalabilnost skladišta podataka i brz pristup podacima.

Za potrebe ovog odeljka, pretpostavimo da imate mnogo terabajta (TB) podataka i dozvoljavate korisnicima da pristupe malim delovima tih podataka nasumično. (Cm. .)
Povezani zadatak je locirati datoteku slike negdje na serveru datoteka u primjeru aplikacije za hosting slika.

Slika 1.7: Pristup određenim podacima

Ovo je posebno teško jer učitavanje terabajta podataka u memoriju može biti veoma skupo i direktno utiče na količinu I/O diska. Brzina čitanja sa diska je nekoliko puta manja od brzine čitanja iz RAM-a - možete reći da je pristup memoriji brz kao Chuck Norris, dok je pristup disku sporiji od reda u klinici. Ova razlika u brzini je posebno uočljiva za velike skupove podataka; u suhim brojevima, pristup memoriji je 6 puta brži od čitanja diska za sekvencijalno čitanje i 100.000 puta brži za nasumično čitanje (pogledajte Patologije velikih podataka, http://queue.acm.org/detail. cfm?id=1563874). ). Takođe, čak i sa jedinstvenim identifikatorima, lociranje malog podatka može biti teško rešiti kao pokušaj da se izvuče poslednji štapić iz kutije sa stotinu drugih bombona bez gledanja.

Srećom, postoji mnogo pristupa kojima se mogu pojednostaviti stvari, od kojih su četiri najvažnija pristupa upotreba predmemorije, proksija, indeksa i balansera opterećenja. Ostatak ovog odjeljka govori o tome kako se svaki od ovih koncepata može koristiti da pristup podacima bude mnogo brži.

Caches

Keširanje ima koristi od karakteristične karakteristike osnovnog principa: nedavno traženi podaci će vjerovatno ponovo biti potrebni. Keš memorije se koristi na gotovo svim nivoima računarstva: hardveru, operativnim sistemima, web pretraživačima, web aplikacijama i još mnogo toga. Keš memorija je poput kratkoročne memorije: ograničena po veličini, ali brža od izvornog izvora podataka i sadrži stavke kojima se nedavno pristupilo. Keš memorije mogu postojati na svim nivoima u arhitekturi, ali su često na najbližem nivou prednjem kraju, gdje su implementirani da brzo vraćaju podatke bez značajnog opterećenja pozadinske mreže.

Dakle, kako se keš može koristiti za ubrzavanje pristupa podacima u našem uzorku API-ja? U ovom slučaju postoji nekoliko prikladnih keš lokacija. Kao jednu od mogućih opcija postavljanja, možete odabrati čvorove na nivou upita, kao što je prikazano u
.

Slika 1.8: Postavljanje keš memorije na čvor nivoa zahtjeva

Postavljanje predmemorije direktno na čvor sloja zahtjeva omogućava lokalno skladištenje podataka odgovora. Svaki put kada se uputi zahtjev servisu, domaćin će brzo vratiti lokalne, keširane podatke, ako postoje. Ako nije u kešu, tada će host zahtjeva zatražiti podatke s diska. Keš memorija na jednom čvoru na nivou zahtjeva također može biti smještena i u memoriji (što je vrlo brzo) i na lokalnom disku čvora (brže od pokušaja pristupa mrežnoj pohrani).

Slika 1.9: Keš sistemi

Šta se dešava kada proširite keširanje na više čvorova? Kao što možete vidjeti, ako će sloj zahtjeva uključivati ​​mnogo čvorova, onda je vjerovatno da će svaki čvor imati svoju vlastitu keš memoriju. Međutim, ako vaš balansator opterećenja nasumično distribuira zahtjeve između čvorova, tada će isti zahtjev ići na različite čvorove, povećavajući tako promašaje keša. Dva načina za prevazilaženje ove prepreke su globalni i distribuirani kešovi.

Global Cache

Značenje globalne keš memorije jasno je iz imena: svi čvorovi koriste isti jedan keš prostor. U ovom slučaju, dodaje se neka vrsta servera ili spremišta datoteka koja je brža od vašeg originalnog spremišta i koja će biti dostupna svim čvorovima na razini zahtjeva. Svaki od čvorova zahtjeva zahtijeva keš memoriju na isti način kao da je lokalni. Ovakva šema keširanja može uzrokovati neke probleme, jer se pojedinačna keš memorija vrlo lako može preopteretiti ako se broj klijenata i zahtjeva poveća. Istovremeno, ovakva šema je vrlo efikasna na određenim arhitekturama (posebno onima povezanim sa specijalizovanim hardverom koji ovu globalnu keš memoriju čini veoma brzom, ili koja ima fiksni skup podataka koji se moraju keširati).

Postoje dva standardna oblika globalnih predmemorija prikazanih na dijagramima. Situacija je prikazana kada keširani odgovor nije pronađen u predmemoriji, sama keš memorija postaje odgovorna za dobijanje nedostajućeg dela podataka iz osnovne prodavnice. Ona ilustruje dužnost čvorova zahtjeva da dohvate sve podatke koji nisu pronađeni u kešu.

Slika 1.10: Globalna keš memorija gdje je keš odgovoran za dohvat

Slika 1.11: Globalna keš memorija u kojoj su čvorovi upita odgovorni za dohvat

Većina aplikacija koje koriste globalne keš memorije imaju tendenciju da koriste prvi tip, gdje sama keš memorija upravlja zamjenom i dohvaćanjem podataka kako bi spriječila klijente da preplave zahtjeve za istim podacima. Međutim, postoje slučajevi u kojima druga implementacija ima više smisla. Na primjer, ako se keš koristi za vrlo velike datoteke, niska stopa pogodaka u keš memoriju će uzrokovati preopterećenje keš memorije s promašajima keša; u ovoj situaciji pomaže imati veliki postotak ukupnog skupa podataka (ili vrućeg skupa podataka) u kešu. Drugi primjer je arhitektura u kojoj su keširane datoteke statične i ne treba ih brisati. (Ovo može biti zbog osnovnih karakteristika performansi takvog kašnjenja podataka - možda određeni dijelovi podataka moraju biti vrlo brzi za velike skupove podataka - gdje logika aplikacije razumije strategiju zamjene ili pristupne tačke bolje od keša.)

Distribuirana keš memorija

Ovi indeksi se često pohranjuju u memoriju ili negdje vrlo lokalno u odnosu na dolazni zahtjev klijenta. Berkeley DB (BDB) i strukture podataka stabla, koje se obično koriste za skladištenje podataka u uređenim listama, idealne su za indeksirani pristup.

Često postoji mnogo nivoa indeksa koji služe kao mapa, vode vas s jedne lokacije na drugu, i tako dalje, dok ne dobijete dio podataka koji vam je potreban. (Cm. )

Slika 1.17: Višerazinski indeksi

Indeksi se također mogu koristiti za kreiranje nekoliko drugih prikaza istih podataka. Za velike skupove podataka, ovo je odličan način za definiranje različitih filtera i pogleda bez potrebe za pravim mnogo dodatnih kopija podataka.

Na primjer, pretpostavimo da gore spomenuti sistem hostinga slika zapravo hostuje slike stranica knjiga, a usluga dozvoljava upite na strani klijenta o tekstu na tim slikama, tražeći sav tekstualni sadržaj na datu temu na isti način na koji vam pretraživači dozvoljavaju za pretraživanje po HTML sadržaju. U ovom slučaju, sve ove slike knjiga koriste toliko servera za pohranjivanje datoteka, a pronalaženje jedne stranice koju bi predstavili korisniku može biti prilično teško. U početku, obrnuti indeksi za ispitivanje proizvoljnih riječi i skupova riječi trebali bi biti lako dostupni; zatim postoji zadatak navigacije do tačne stranice i mjesta u toj knjizi i pronalaženja ispravne slike za rezultate pretrage. Dakle, u ovom slučaju, obrnuti indeks bi se mapirao na lokaciju (kao što je knjiga B), a onda bi B mogao sadržavati indeks sa svim riječima, lokacijama i brojem pojavljivanja u svakom dijelu.

Obrnuti indeks koji bi Index1 u gornjem dijagramu mogao predstavljati izgledao bi otprilike ovako: svaka riječ ili skup riječi služi kao indeks za knjige koje ih sadrže.

Srednji indeks će izgledati slično, ali će sadržavati samo riječi, lokaciju i informacije za Knjigu B. Ova arhitektura na više nivoa omogućava svakom od indeksa da zauzme manje prostora nego da su sve ove informacije pohranjene u jednom velikom obrnutom indeksu .

A ovo je ključno u sistemima velikih razmjera, jer čak i kada su komprimirani, ovi indeksi mogu biti prilično veliki i skupi za pohranu. Pretpostavimo da imamo mnogo knjiga iz cijelog svijeta u ovom sistemu - 100.000.000 (pogledajte unos na blogu "Inside Google Books") - i da svaka knjiga ima samo 10 stranica (da pojednostavimo proračune) sa 250 riječi po stranici: ovo daje imamo ukupno 250 milijardi riječi. Ako uzmemo prosječan broj znakova u riječi kao 5, i kodiramo svaki znak sa 8 bitova (ili 1 bajt, iako neki karakteri zapravo zauzimaju 2 bajta), trošeći tako 5 bajtova po riječi, onda indeks, koji sadrži svaki riječ samo jednom, zahtijevalo bi više od 1 terabajta memorije. Tako možete vidjeti da indeksi koji također imaju druge informacije, kao što su skupovi riječi, lokacija podataka i broj korištenja, mogu vrlo brzo rasti.

Kreiranje takvih srednjih indeksa i predstavljanje podataka u manjim komadima čini problem velikih podataka lakšim za rješavanje. Podaci se mogu distribuirati na više servera i u isto vrijeme biti brzo dostupni. Indeksi su kamen temeljac za pronalaženje informacija i temelj za današnje moderne pretraživače. Naravno, ovaj odjeljak se dotiče samo teme indeksiranja općenito, a bilo je mnogo istraživanja o tome kako indekse učiniti manjim, bržim, informativnijim (poput relevantnosti) i besprijekorno ažuriranim. (Postoje neki problemi sa upravljanjem konkurentnim uslovima, kao i sa brojem ažuriranja potrebnih za dodavanje novih ili promenu postojećih podataka, posebno kada je reč o relevantnosti ili bodovanju).

Mogućnost brzog i jednostavnog pronalaženja podataka je vrlo važna, a indeksi su najjednostavniji i najefikasniji alat za postizanje ovog cilja.

Balanseri opterećenja

Konačno, još jedan kritični dio svakog distribuiranog sistema je balansator opterećenja. Balanseri opterećenja su suštinski dio svake arhitekture, jer je njihova uloga da raspodijele opterećenje među čvorovima odgovornim za servisiranje zahtjeva. Ovo omogućava da više čvorova transparentno služe istoj funkciji u sistemu. (Pogledajte .) Njihova glavna svrha je rukovanje mnogim istovremenim vezama i usmjeravanje tih veza na jedan od traženih čvorova, omogućavajući sistemu da se skalira jednostavnim dodavanjem čvorova kako bi opsluživao više zahtjeva.

Slika 1.18: Balansator opterećenja

Postoji mnogo različitih algoritama za posluživanje zahtjeva, uključujući nasumični odabir čvorova, kružni algoritam ili čak odabir čvora na osnovu određenih kriterija kao što je korištenje CPU-a ili RAM-a. Balanseri opterećenja se mogu implementirati kao hardverski uređaji ili softver. Među balansatorima opterećenja otvorenog koda, HAProxy se najviše koristi.

U distribuiranom sistemu, balanseri opterećenja su često na "prvoj liniji" sistema, tako da svi dolazni zahtevi prolaze direktno kroz njih. Vrlo je vjerovatno da će u složenom distribuiranom sistemu zahtjev morati proći kroz nekoliko balansera, kao što je prikazano u
.

Slika 1.19: Višestruki balanseri opterećenja

Poput proksija, neki balanseri opterećenja također mogu drugačije usmjeravati zahtjeve ovisno o vrsti zahtjeva. Oni su također poznati kao obrnuti (obrnuti) proksiji.

Upravljanje podacima specifičnim za određenu korisničku sesiju jedan je od izazova pri korištenju balansera opterećenja. Na web-mjestu za e-trgovinu, kada imate samo jednog kupca, vrlo je lako dopustiti korisnicima da stave stvari u svoju košaricu i pohranjuju sadržaj između posjeta (ovo je važno, jer se vjerovatnoća prodaje artikla značajno povećava ako, kada korisnik se vraća na stranicu, proizvod je još uvijek u njegovoj košarici). Međutim, ako je korisnik upućen na jedan čvor za prvu sesiju, a zatim na drugi čvor tokom svoje sljedeće posjete, tada može doći do nedosljednosti jer novi čvor možda nema podatke o sadržaju kolica tog korisnika. (Nećete li biti frustrirani ako stavite paket Mountain Dew-a u košaricu i nestane ga kada se vratite?) Jedno rješenje bi moglo biti da sesije budu "ljepljive" tako da korisnik uvijek bude usmjeren na isti čvor. Međutim, iskorištavanje prednosti nekih karakteristika pouzdanosti, kao što je automatski prelazak na grešku, bit će znatno teže. U ovom slučaju, korisnička košarica će uvijek imati sadržaj, ali ako njihov sticky čvor postane nedostupan, tada će biti potrebna posebna pažnja i pretpostavka o sadržaju košarice više neće biti istinita (iako se nadamo da ova pretpostavka neće biti ugrađena u aplikacija). Naravno, ovaj problem se može riješiti korištenjem drugih strategija i alata, kao što je opisano u ovom poglavlju, kao što su servisi i mnogi drugi (kao što su kešovi pretraživača, kolačići i prepisivanje URL-a).

Ako sistem ima samo nekoliko čvorova, onda će trikovi poput DNS kružnih tokova vjerovatno biti praktičniji od balansera opterećenja, koji mogu biti skupi i povećati složenost sistema dodavanjem nepotrebnog sloja. Naravno, u velikim sistemima postoje sve vrste različitih algoritama za planiranje i balansiranje opterećenja, od jednostavnih kao što su slučajni odabir ili algoritami vrteške do složenijih mehanizama koji uzimaju u obzir karakteristike performansi obrasca korištenja sistema. Svi ovi algoritmi omogućavaju distribuciju saobraćaja i zahtjeva i mogu pružiti korisne alate za pouzdanost kao što je automatsko prelazak na grešku ili automatsko uklanjanje lošeg čvora (na primjer, kada prestane da odgovara). Međutim, ove napredne funkcije mogu učiniti dijagnosticiranje problema nezgrapnim. Na primjer, u situacijama visokog opterećenja, balanseri opterećenja će ukloniti čvorove koji mogu biti spori ili istekli (zbog navale zahtjeva), što će samo pogoršati stvari za druge čvorove. U ovim slučajevima, opsežna kontrola je važna jer iako se čini da ukupni sistemski promet i opterećenje opadaju (jer čvorovi poslužuju manje zahtjeva), pojedinačni čvorovi i dalje mogu biti gurnuti do granice.

Balanseri opterećenja su jednostavan način za povećanje kapaciteta sistema. Kao i druge metode opisane u ovom članku, on igra bitnu ulogu u arhitekturi distribuiranog sistema. Balanseri opterećenja također pružaju kritičnu funkcionalnost provjera zdravlja čvorova. Ako, kao rezultat takve provjere, čvor ne odgovara ili je preopterećen, tada se može ukloniti iz spremišta za obradu zahtjeva i, zbog redundantnosti vašeg sistema, opterećenje će se preraspodijeliti između preostalih radnih čvorova.

Redovi

Do sada smo razmatrali mnogo načina za brzo čitanje podataka. U isto vrijeme, još jedan važan dio skaliranja nivoa podataka je efikasno upravljanje zapisima. Kada su sistemi jednostavni i karakterizirani minimalnim opterećenjem obrade i malim bazama podataka, pisanje može biti predvidljivo brzo. Međutim, u složenijim sistemima ovaj proces može potrajati neograničeno dugo. Na primjer, podaci će možda morati biti zapisani na više lokacija na različitim serverima ili indeksima, ili sistem može jednostavno biti pod velikim opterećenjem. U slučajevima kada pisanje ili čak bilo koji zadatak traje dugo, postizanje performansi i dostupnosti zahtijeva ugradnju asinhronije u sistem. Uobičajeni način da se to učini je organiziranje reda zahtjeva.

Slika 1.20: Sinhroni zahtjev

Zamislite sistem u kojem svaki klijent traži zadatak udaljenog održavanja. Svaki od ovih klijenata šalje svoj zahtjev serveru, koji izvršava zadatke što je brže moguće i vraća rezultate odgovarajućim klijentima. U malim sistemima u kojima jedan server (ili logička usluga) može opsluživati ​​dolazne klijente čim stignu, ovakve situacije bi trebale dobro funkcionirati. Međutim, kada server primi više zahtjeva nego što može podnijeti, tada je svaki klijent prisiljen čekati da se zahtjevi drugih klijenata završe prije nego što se generira odgovor na njegov vlastiti zahtjev. Ovo je primjer sinhronog zahtjeva, prikazanog u .

Ova vrsta sinhronog ponašanja može značajno smanjiti performanse klijenta; zapravo neaktivan, klijent je prisiljen čekati dok ne primi odgovor na zahtjev. Dodavanje više servera za upravljanje opterećenjem sistema zapravo ne rješava problem; čak i sa efektivnim balansiranjem opterećenja na mestu, izuzetno je teško obezbediti ravnomernu i pravednu raspodelu opterećenja potrebnu za maksimiziranje performansi klijenta. Štaviše, ako server nije dostupan za obradu ovog zahtjeva (ili je u kvaru), tada će i klijent povezan s njim prestati raditi. Efikasno rješavanje ovog problema zahtijeva apstrakciju između zahtjeva klijenta i stvarnog posla koji se radi na njegovom servisiranju.

Slika 1.21: Upotreba redova za upravljanje zahtjevima

Redovi za prijavu. Mehanizam reda je vrlo jednostavan: zadatak stiže, ulazi u red čekanja, a zatim "radnici" prihvataju sljedeći zadatak čim imaju priliku da ga obrade. (Vidi .) Ovi zadaci mogu biti jednostavni poput pisanja u bazu podataka ili nešto tako složeno kao što je generiranje slike za pregled dokumenta. Kada klijent pošalje zahtjeve za zadatkom u red čekanja, više ne mora čekati rezultate izvršenja; umjesto toga, zahtjeve samo treba potvrditi da su pravilno primljeni. Ova potvrda kasnije može poslužiti kao veza sa rezultatima rada kada ih klijent zatraži.

Redovi dopuštaju klijentima da rade na asinhroni način pružajući stratešku apstrakciju za klijentov zahtjev i odgovor. S druge strane, u sinhronom sistemu ne postoji diferencijacija između zahtjeva i odgovora, pa se njima ne može upravljati odvojeno. U asinhronom sistemu, klijent šalje zadatak, servis odgovara porukom koja potvrđuje da je zadatak primljen, a zatim klijent može periodično provjeravati status zadatka, tražeći rezultat tek nakon što je završen. Dok klijent postavlja asinhroni zahtjev, slobodan je obavljati druge poslove, pa čak i postavljati asinhrone zahtjeve drugim servisima. Potonji je primjer kako redovi i poruke rade u distribuiranim sistemima.

Redovi također pružaju određenu zaštitu od prekida usluga i kvarova. Na primjer, prilično je lako kreirati vrlo izdržljiv red koji može ponovo pokušati zahtjeve za uslugu koji ne uspiju zbog kratkih ispada servera. Poželjnije je koristiti red čekanja za implementaciju garancija kvaliteta usluge nego izložiti privremene prekide usluga klijentima, što zahtijeva složeno i često nedosljedno rukovanje greškama na strani klijenta.

1.4. Zaključak

Razvoj efikasnih sistema sa brzim pristupom velikim količinama podataka je veoma interesantna tema, a još uvek postoji značajan broj dobrih alata koji vam omogućavaju da prilagodite sve vrste novih aplikacija. Ovo poglavlje dotaklo je samo nekoliko primjera, ali stvarnost je mnogo više—a nove inovacije u ovoj oblasti će se samo nastaviti.

Ovo djelo se distribuira pod neizmijenjenom licencom Creative Commons Attribution 3.0. Pogledajte detalje u

U ovom članku ćemo izložiti neke koncepte koje trebate koristiti pri odabiru ventilatora u kućištu i govoriti o karakteristikama koje su karakteristične za različite vrste ventilatora. Pored toga, testiraćemo i akasa Amber AK-183-L2B 120mm ventilator, koji više od godinu dana služi kao aktivni element sistema za hlađenje Thermaltake Sonic Tower procesora koji se koristi za testiranje procesora i video kartica. I treba napomenuti da je u potpunosti zaslužio pravo da postane prvi heroj u nizu recenzija posvećenih obožavateljima na našem resursu.

Pitanja na koja ćemo pokušati da odgovorimo su...

Koji su zahtjevi za ventilator kućišta?

1. nivo performansi.
2. Nivo buke.
3. Izgled (prisustvo i vrsta osvjetljenja).
4. Dodatne karakteristike (PWM podrška za napajanje, regulator brzine, antivibracioni nosač).

Koje su glavne razlike između kućišta ventilatora?

1.Dimenzije- veličina radnog kola.

Za stvaranje unutrašnje ventilacije u kućištu, u većini slučajeva koriste se ventilatori standardne veličine od 80 mm, 92 mm ili 120 mm, jer su u početku predviđeni montažni otvori za njihovu ugradnju u kućište. Sasvim je jasno da što je veća veličina radnog kola ventilatora, to je veća njegova sposobnost da pumpa protok zraka. Stoga će manji ventilator morati da se okreće većom brzinom kako bi postigao performanse većih modela, a samim tim i napravio mnogo više buke. Upravo iz tog razloga su popularni veliki ventilatori od 120 mm.

Da biste ilustrirali ova svojstva, možete uporediti karakteristike modela ventilatora iste serije iz Xinruilian Science & Technology Co. sa različitim veličinama:

Veličina, mm
Brzina obrtaja
Protok zraka, CFM
Nivo buke, dB
Pritisak, mm H 2 0

Sudeći po gore navedenim karakteristikama modela, možemo zaključiti da će pri istoj brzini rotacije ventilator od 92 mm biti 1,65 puta efikasniji od ventilatora od 80 mm, a ventilator od 120 mm će biti dvostruko efikasniji od modela od 92 mm. , s obzirom da svi ventilatori imaju jednu vrstu radnog kola.

Osim različitih promjera radnog kola, jednako je važna i veličina profila ili dubina ventilatora. "Classic" za konvencionalne slučajeve je profil od 25 mm. Ventilatori manjeg profila nazivaju se niskoprofilni ventilatori, dok se oni sa većim profilom nazivaju visokoprofilni. Snaga protoka zraka direktno ovisi o veličini profila, koja se u specifikaciji karakterizira vrijednošću maksimalnog pritiska.

Na primjer, uporedimo karakteristike dva modela od 120 mm - s regularnim profilom i visokim profilom, koji rade pri istoj brzini rotacije.

Veličina, mm
Brzina obrtaja
Protok zraka, CFM
Nivo buke, dB
Pritisak, mm H20

Tabela pokazuje da se ventilator visokog profila razlikuje samo po najboljem pokazatelju maksimalnog pritiska protoka zraka. Konvencionalni kompjuterski sistemi ne moraju biti pod pritiskom, tako da se ovi ventilatori u njima ne koriste. U većini slučajeva u serverima se koriste ventilatori visokog profila; osim toga, imaju povećanu brzinu rotacije i, kao rezultat, prilično veliku buku pri radu.

2. Tip ležaja.

Postoje tri glavna tipa ležajeva koji se koriste u ventilatorima: klizni ležajevi, kombinovani klizni i kotrljajući ležajevi i koji se sastoje od dva kotrljajuća ležaja. Pored ovih tipova ležajeva, mnogo rjeđe, postoje hidrodinamički tipovi koje su neki proizvođači posebno razvili.

Najčešće možete odrediti vrstu ležaja prisustvom sljedećih indeksa u nazivu modela ventilatora, iako je uvijek preporučljivo provjeriti sa službenom specifikacijom:

S (rukav) - klizni ležaj, koji je u suštini čaura;
SA (combo) - jedan kuglični ležaj i kratki rukav;
B (lopta) ili 2B (2 lopte)- dva kuglična ležaja.

Najjednostavniji i najjeftiniji, ali, nažalost, ne baš izdržljiv je klizni ležaj. Ovaj ležaj ima oblik male bakrene čaure, unutar koje, rotirajući, klizi osovina radnog kola (šipka). Novi ventilator s podmazanim kliznim ležajem može biti potpuno tih, ali se to svojstvo može izgubiti s vremenom. U nedostatku odgovarajućeg nivoa podmazivanja, čahura "radi" prilično brzo, zbog čega ventilator počinje stvarati buku. Osim toga, u nedostatku podmazivanja, pri radu u području s visokom temperaturom, ventilator se može potpuno zaglaviti. Ovu činjenicu posebno jasno pokazuju slučajevi s jeftinim kineskim izvorima napajanja, u kojima su često bili slučajevi zaustavljanja ventilatora na kliznom ležaju, koji osigurava hlađenje energetskih poluvodičkih elemenata. Kao rezultat, došlo je do kvara napajanja.

Kombinirana verzija ležaja ima relativno duži vijek trajanja ležaja.

Ležaj koji se sastoji od dva kuglična ležaja je najskuplja, ali u isto vrijeme i izdržljivija opcija. Ovaj tip ležaja može slobodno raditi u području visoke temperature. Ali u isto vrijeme, često među takvim obožavateljima možete pronaći primjerke koji prave prilično glasnu i neugodnu buku. Ova slika je posebno tipična za jeftine ventilatore, jer karakteristike buke cijele konstrukcije direktno ovise o kvaliteti izrade minijaturnog ležaja. Stoga, ako odaberete proizvod s kugličnim ležajevima, nikako nemojte ići na njegovu jeftinoću, jer su i skuplji modeli rijetko tihi.

3. Klasa motora.

Svi ventilatori u kućištu rade na 4-polnim DC motorima. Po brzini, svi su razvrstani u tri kategorije: do 2000 o/min male brzine, od 2000 do 3000 o/min srednje i preko 3000 o/min velike brzine. Klasu motora ventilatora često možete saznati po indeksu u njegovom nazivu, koji je često naznačen na naljepnici:

L(nisko) - tiho ( prije 2000 rpm);
M (srednji) - prosjek ( od 2000 do 3000 rpm);
H (visoko) - brzo ( preko 3000 rpm).

Šta karakterišu podaci navedeni u specifikacijama proizvođača?

Brzina ventilatora mjereno u okretajima u minuti (RPM - rotacije u minuti). Budući da sama brzina ventilatora može varirati gotovo direktno proporcionalno naponu napajanja, vrijednost navedena u specifikaciji odgovara nazivnom naponu napajanja. Što je veća brzina rotacije, to je ventilator efikasniji, ali i obično bučniji.

Protok zraka može se specificirati u CFM (kubnim stopama u minuti, CFM) - kubnim stopama po minuti ili u kubnim metrima na sat (m 3 / h). Istovremeno, 1 CFM ≈ 1,7 m 3 / h. Ova vrijednost prikazuje količinu "ispumpanog" zraka za određeni vremenski period, pod uslovom da nema otpora strujanju zraka, odnosno da je pritisak zraka jednak sa obje strane ventilatora. Naravno, što je ova vrijednost veća, to bolje.

Statički pritisak vazduha Brzina ventilatora se obično daje u mm vodenog stupca i karakterizira količinu protoka zraka koju ventilator može stvoriti.

Podsjetimo da se pritisak izračunava po formuli P=F/S. Odnosno, pritisak je omjer sile strujanja zraka i površine na koju djeluje. Specifikacija označava maksimalnu vrijednost protoka zraka koji ventilator stvara kada ne može stvoriti protok zraka zbog otpora.

Celokupna karakteristika ventilatora može se videti na grafu "Kriva performansi".

Kriva performansi predstavlja odnos između protoka vazduha i pritiska. Najviša tačka krivulje, koja se nalazi na osi, nije ništa više od maksimalnog pritiska koji je dat u specifikaciji. Donja tačka krivulje, koja leži na drugoj osi, odgovara maksimalnom protoku vazduha ventilatora kada ne mora da stvara pritisak. U realnim uslovima, odnosno u slučaju, strujanje vazduha mora da savlada određeni otpor. Svaki slučaj pojedinačno ima svoj stepen otpornosti. Otpor sistema će biti izražen nagibom na grafu, a tačka preseka prave i krive nije ništa drugo do radna tačka ventilatora u našem uslovnom sistemu.

Fan resurs meri se brojem hiljada sati tokom kojih ventilator mora da radi i da obezbedi deklarisane karakteristike. Autor članka ne zna u potpunosti pod kojim radnim uvjetima se postižu date vrijednosti, budući da vijek trajanja direktno ovisi o uvjetima rada. Pretpostavlja se da ventilator može da radi određeni broj sati bez gubitka kvaliteta buke. Resurs uvelike ovisi o vrsti i kvaliteti ležaja. Klizni ležajevi se obično navode na 30.000 sati, kombinovani ležajevi na 45.000 sati, a dvostruki kuglični ležaji na 60.000 sati ili više.

U većini slučajeva, ventilator s kliznim ležajem može raditi prilično tiho oko godinu dana, iako proizvođači tvrde da ih ima 30 000. Stoga, ove brojke ne bi trebale biti pristrane - prilično su relativne. A ako kopate, ispada da je proizvođač mislio i na periodično održavanje ventilatora, tj. mazivo koje obični korisnici rijetko proizvode.

Sada se vratimo na junaka naše recenzije, obožavatelja akasa AK-183-L2B i pogledajte njegovu specifikaciju:

	akasaAK-183-L2B
Veličina, mm
Brzina rotacije, o/min
Protok zraka, CFM
Pritisak, mm H20
Resurs, h
Vrsta ležaja	dva kotrljanja
	3 pin
Nivo buke, dB
Napon napajanja, V
Web stranica proizvoda
prosječna cijena

Ventilator akasa AK-183-L2B je upakovan u prozirnu plastičnu kutiju. Na poleđini pakovanja nalazi se plavi karton koji naglašava prozirno kućište i prozirno ćilibarno-žuto radno kolo ventilatora. Općenito, sve je uređeno u uobičajenoj korporativnoj plavoj i žutoj boji Akasa grupe.

Na poleđini kartonskog umetka nalazi se specifikacija na pet različitih jezika.

Pored ventilatora, na samom dnu pakovanja nalazi se i mala crna kartonska kutija sa natpisom u prevodu koji zvuči kao “3-4 pin adapter”.

Stoga uopće ne čudi što se u kutiji nalazi adapter koji omogućava spajanje ventilatora sa konektora perifernih uređaja, a osim toga ima i dodatni 3-pinski konektor za kontrolu brzine ventilatora. Takođe u maloj crnoj kutiji bila su četiri zavrtnja za ugradnju ventilatora u kućište.

Kućište ventilatora akasa AK-183-L2B izrađeno je od bijele prozirne plastike, a radno kolo je od prozirne plastike žute boje. Zapravo, ako uzmemo u obzir cijeli asortiman akasa proizvoda, onda se rijetko susreću sa jednostavnim i standardnim rješenjima, jer kompanija distribuira robu, uglavnom, dizajniranu posebno za modding. Ali to uopće ne znači da ako se ne smatrate modder kastom i navikli ste ocjenjivati ​​proizvod samo iz praktičnih razloga, onda vam ovaj obožavatelj i drugi slični proizvodi ne odgovaraju. Naime, kod proizvodnje proizvoda za tzv. teške korisnike, moddere ili overlockere, uvijek se pojačava pažnja prije svega na kvalitetu izrade i njene nešto veća svojstva. Stoga uopće nije iznenađujuće da su potrošačke kvalitete takvih proizvoda gotovo uvijek veće od onih jednostavnih proizvoda.

Spolja, ventilator se, naravno, ističe prije svega prekrasnom kombinacijom žute i bijele, a čini se da takav ventilator jednostavno mora imati pozadinsko svjetlo, ali zapravo nije. Sa stanovišta aerodinamike, u ventilatoru - jednostavnom rotoru sa sedam lopatica nisu implementirane nikakve inovacije ili znanja.

Ventilator akasa AK-183-L2B spada u modele male brzine, nominalna brzina rotacije mu je 1400 o/min, dok maksimalni protok vazduha može dostići 44,8 CFM, a statički pritisak je 1,1 mm vodenog stuba. Specifikacije nisu ni ultra visoke ni sasvim obične, ali to i ne čudi, budući da je kućište ventilatora kućnog sistema prvenstveno podložno povećanim zahtjevima za bukom.

I u tom smislu, prema specifikaciji, naznačen je prilično nizak nivo buke od 18 dB. Treba napomenuti da je ventilator akasa AK-183-L2B baziran na dva kuglična ležaja, a njegov resurs, prema proizvođaču, iznosi 80.000 sati. Uobičajena vrijednost za kuglične ležajeve je 60.000 sati, pa malo povećana vrijednost daje razloga za nadu u bolji pristup njihovoj izradi, jer, kao što smo već napomenuli, kvalitet izrade kugličnog ležaja određuje njegove karakteristike buke. .

Ventilator se napaja preko 3-pinskog konektora za napajanje koji ne podržava napajanje širine impulsa.

Testiranje

Praktični dio testa sastoji se od dvije faze testiranja stvorenog strujanja zraka ventilatora pri nominalnim brzinama, kao i procjene njegove glasnoće na uho.

Test #1

U prvom testu, ventilator će djelovati kao aktivni element Thermalright SI-128 hladnjaka. Testiranje se vrši u otvorenom kućištu, a glavni kontrolirani parametar je temperatura grijanja Intel Core 2 Duo E6300 procesora overklokovanog na 2,8 GHz i temperatura matične ploče.

Test #2

U drugom testu, ventilator će se koristiti za svoju namjenu kao kućište ventilatora koji se postavlja na stražnju ploču i izduvava. Tokom testa, kućište će biti zatvoreno i u njemu neće biti uključeni drugi ventilatori. Glavni kontrolisani parametar takođe će biti temperatura grejanja Intel Core 2 Duo E6300 procesora, ali sada bez overkloka, na koji je instaliran pasivni sistem hlađenja Thermaltake Sonic Tower (CL-P0071), kao i temperatura matične ploče. Rezultat testa se bilježi nakon 10-minutnog "provođenja" stres testa procesora u aplikaciji Everest.

Test konfiguracija platforme sa Intel procesorom sastoji se od sljedećih komponenti:

Matična ploča	Gigabyte GA-965P-DS4 (Intel P965 Express)
CPU	Intel Core 2 Duo E6300 (LGA775, 1.86GHz, L2 2MB) @2.8GHz
RAM	2 x DDR2-800 1024MB Apacer PC6400
video kartica	EVGA GeForce 8600GTS 256MB DDR3 PCI-E
HDD	Samsung HD080HJ, 80 GB, SATA-300
optički pogon	ASUS DRW-1814BLT SATA
Napajanje	Chieftec CFT-500-A12S 500W, 120mm ventilator
	CODEGEN M603 MidiTower

Ventilator akasa AK-183-L2B pokazuje dobre performanse u poređenju sa drugim konkurentima. Poprilično nizak deklarisani nivo buke od 18 dB možemo potvrditi samo našim subjektivnim mišljenjem. Navedena vrijednost zaista sasvim odgovara stvarnom nivou buke - pri maksimalnoj brzini emituje lagano zujanje.

Zaključci.

Ventilator akasa AK-183-L2B nije isključivo lijepa dekoracija za modding, kako se kupcu može odmah učiniti. Može stvoriti dovoljno veliki protok zraka i, što je najvažnije, proizvodi prilično nizak nivo buke. Ako uzmemo u obzir njegovu prihvatljivu cijenu kao za visokokvalitetni model ventilatora s kugličnim ležajem, onda će u ovoj kategoriji robe u pogledu cijena / potrošačkih kvaliteta biti jedan od najboljih. Ponavljamo da u našoj laboratoriji za testiranje ventilator akasa AK-183-L2B radi više od godinu dana, a njegov kvalitet buke se za to vrijeme nije promijenio.

Prednosti:

• stvara veliki protok vazduha;
• nizak nivo buke;
• dobar omjer cijene i performansi.

Nedostaci uključuju:

• nedostatak PWM podrške.

Izražavamo našu zahvalnost kompaniji PF Service LLC (Dnjepropetrovsk) na opremi koja je data za testiranje.

Članak pročitan 4669 puta

Pretplatite se na naše kanale

Omogućite Javascript da biste koristili pretvarač jedinica

›› Više informacija iz pretvarača jedinica

Koliko cfm u 1 kubnom metru/minuti? Odgovor je 35.314666212661.
Pretpostavljamo da se pretvarate između kubna stopa/minuta i kubnih metara/minuti.
Više detalja o svakoj mjernoj jedinici možete pogledati:
cfm ili kubnih metara/minuti
SI izvedena jedinica za zapreminski protok je kubni metar/sekundi.
1 kubni metar/sekundi jednak je 2118,8799727597 cfm, ili 60 kubnih metara/minuti.
Imajte na umu da može doći do grešaka u zaokruživanju, pa uvijek provjerite rezultate.
Koristite ovu stranicu da naučite kako pretvoriti između kubnih stopa/minuti i kubnih metara/minuti.
Unesite svoje brojeve u obrazac za pretvaranje jedinica!

›› Tabela brze konverzije cfm u kubni metar/minuti

1 cfm u kubni metar/minuti = 0,02832 kubnih metara/minuti

10 cfm do kubnih metara/minuti = 0,28317 kubnih metara/minuti

20 cfm do kubnih metara/minuti = 0,56634 kubnih metara/minuti

30 cfm do kubnih metara/minuti = 0,84951 kubnih metara/minuti

40 cfm do kubnih metara/minuti = 1,13267 kubnih metara/minuti

50 cfm do kubnih metara/minuti = 1,41584 kubnih metara/minuti

100 cfm do kubnih metara/minuti = 2,83168 kubnih metara/minuti

200 cfm do kubnih metara/minuti = 5,66337 kubnih metara/minuti

›› Želite druge jedinice?

›› Definicija: kubna stopa/minuta

Kubične stope u minuti (CFM) je mjera koja se koristi u industrijskoj higijeni i ventilaciji. Opisuje brzinu protoka zapremine gasa ili vazduha u ili iz prostora.

Standardno mjerenje protoka zraka koje pokazuje koliko kubnih stopa zraka prođe pored nepokretne tačke u jednoj minuti. Što je broj veći, to više vazduha prolazi kroz sistem. Volumetrijski protok tekućine ili plina u kubnim stopama u minuti. 1 CFM je približno 0,47 litara u sekundi.

›› Metričke konverzije i još mnogo toga

site pruža online kalkulator konverzije za sve vrste mjernih jedinica. Možete pronaći tablice metričke konverzije za SI jedinice, kao i engleske jedinice, valutu i druge podatke. Unesite simbole jedinica, skraćenice ili pune nazive za jedinice dužine, površine, mase, pritiska i druge vrste. Primjeri uključuju mm, inč, 100 kg, američku tečnu uncu, 6"3", 10 kamena 4, kubni cm, kvadratne metre, grame, molove, stope u sekundi i još mnogo toga!

• Prevod

Mjerenje propusnosti uskih grla prema vremenu povratnog putovanja paketa

Po svemu sudeći, današnji internet ne može prenositi podatke onoliko brzo koliko bi trebao. Većina mobilnih korisnika u svijetu ima kašnjenja u rasponu od nekoliko sekundi do nekoliko minuta: javne WiFi pristupne tačke na aerodromima i na konferencijama su još gore. Fizičari i klimatolozi trebaju razmjenjivati ​​petabajte podataka sa kolegama širom svijeta, ali su suočeni s činjenicom da njihova pažljivo dizajnirana multi-gigabitna infrastruktura često isporučuje samo nekoliko megabita u sekundi na transkontinentalnim vezama.

Ovi problemi su proizašli iz izbora arhitekture koji su napravljeni kada je TCP upravljanje zagušenjem razvijeno 1980-ih, kada je odlučeno da se gubitak paketa protumači kao "zagušenje". Ekvivalencija ovih koncepata vrijedila je za to vrijeme, ali samo zbog ograničenja tehnologije, a ne po definiciji. Kako su se NIC-ovi (kontrolori mrežnog interfejsa) nadogradili sa megabitnih na gigabitne brzine, a memorijski čipovi sa kilobajta na gigabajte, veza između gubitka paketa i zagušenja postala je manje očigledna.

U modernom TCP-u, kontrola zagušenja gubitka paketa - čak iu najnaprednijoj CUBIC tehnologiji ove vrste - je glavni uzrok ovih problema. Ako su međuspremnici uskog grla preveliki, gušenje zagušenja gubitka paketa ih održava punima, uzrokujući prekomjerno mrežno međuspremnik. Ako su baferi premali, sistem za smanjenje zagušenja gubitka paketa pogrešno tumači gubitak paketa kao signal zagušenja, što rezultira smanjenom propusnošću. Rješavanje ovih problema zahtijeva alternativu kontroli zagušenja gubitka paketa. Da biste pronašli ovu alternativu, morate razumjeti gdje i kako dolazi do zagušenja.

Zagušenje i usko grlo

U svakom trenutku postoji samo jedna najsporija veza na (punom dupleksu) TCP vezi, ili usko grlo u svakom pravcu. Usko grlo je važno iz sljedećih razloga:

• Određuje maksimalnu brzinu prijenosa podataka za vezu. Ovo je glavno svojstvo nekomprimovanog toka podataka (na primjer, zamislite autoput sa šest traka tokom špica, ako nesreća uzrokuje da jedan mali dio puta bude ograničen na samo jednu traku. Saobraćaj ispred nesreće se neće kretati brže od saobraćaja ovom trakom.
• Ovo je mjesto gdje se stalno stvaraju redovi. One se smanjuju samo ako je intenzitet izlaznog toka iz "uskog grla" veći od intenziteta dolaznog toka. Za veze koje rade pri maksimalnoj brzini prijenosa, svi odlazni tokovi do uskog grla uvijek imaju veću uzvodnu brzinu, tako da se redovi kreću prema uskom grlu.

Bez obzira na to koliko veza ima veza i koje su njihove pojedinačne brzine, sa TCP tačke gledišta, proizvoljno složena ruta je predstavljena kao jedna veza sa istim RTT-om (vrijeme povratnog putovanja paketa, tj. ) i propusnost uskog grla. Dvije fizičke granice RTprop(vrijeme propagacije povratnog puta) i BtlBw(propusnost uskog grla, propusnost uskog grla) utiču na performanse prenosa. (Da je put mreže materijalna cijev, RTprop bi bio dužina cijevi, a BtlBw bi bio njen promjer.)

Slika 1 prikazuje različite kombinacije RTT-a i brzine prijenosa s volumenom podataka. u letu, tj. let (podaci poslani, ali bez potvrde isporuke). Plave linije pokazuju ograničenje RTpropa, zelene linije BtlBw ograničenje, a crvene linije bafer za usko grlo. Operacije u sivim zonama nisu moguće jer krše barem jedno ograničenje. Prijelazi između ograničenja rezultirali su formiranjem tri regije (ograničena aplikacijom, ograničena propusnošću i ograničena baferom) s kvalitativno različitim ponašanjem.

Slika 1

Kada u letu nema dovoljno podataka za punjenje cijevi, RTprop određuje ponašanje; inače dominira BtlBw. Granične linije se seku u tački , koja je takođe BDP cev (proizvod kašnjenja propusnog opsega, derivat propusnog opsega i kašnjenja). Budući da je cijev puna nakon ove točke, višak stvara red do uskog grla, što rezultira linearnom relacijom između RTT i podataka o letu, prikazanom na gornjem grafikonu. Paketi se ispuštaju kada višak premaši kapacitet bafera. Zagušenje je samo kontinuirana lokacija desno od linije BDP-a, i kontrola zagušenja- neka šema za postavljanje ograničenja koliko se u prosjeku podaci prenose desno od linije BDP-a.

Kontrola zagušenja gubitka radi na desnoj ivici regije ograničene propusnošću, pružajući punu propusnost uskog grla na račun velike latencije i čestih gubitaka paketa. U vrijeme kada je memorija bila skupa, veličine bafera bile su samo nešto veće od BDP-a, što je minimiziralo višak kašnjenja u kontroli zagušenja s gubicima. Naknadno smanjenje cijene memorije rezultiralo je povećanjem baferovanja mreže i povećanjem RTT-a na sekunde umjesto milisekundi.

Na lijevoj ivici područja ograničenog kapacitetom kanala nalazi se radna tačka sa boljim uslovima nego na desnoj. Godine 1979. Leonard Kleinrock je pokazao da je ova radna tačka optimalna, maksimizirajući stvarnu propusnost uz minimiziranje kašnjenja i gubitaka, kako za pojedinačne veze tako i za mrežu u cjelini. Nažalost, otprilike u isto vrijeme, Jeffrey Jaffe je dokazao da je nemoguće stvoriti distribuirani algoritam koji konvergira u ovoj radnoj tački. Ovo otkriće promijenilo je smjer istraživanja. Umjesto da traže distribuirani algoritam koji teži Kleinrockovoj optimalnoj radnoj tački, istraživači su počeli da istražuju alternativne pristupe kontroli zagušenja.

Naš tim u Google-u provodi sate svaki dan pregledavajući zapise snimanja TCP zaglavlja iz cijelog svijeta, razumijevajući anomalije i patologije ponašanja. Obično prvo tražimo ključne karakteristike rute, RTprop i BtlBw. Činjenica da se oni mogu zaključiti iz mrežnih tragova sugerira da Jaffeov zaključak možda nije bio tako jednostavan kao što se nekada činilo. Njegov zaključak se oslanja na fundamentalnu mjernu nesigurnost (na primjer, da li je izmjereno povećanje RTT uzrokovano promjenom dužine putanje, smanjenjem protoka uskog grla ili povećanjem kašnjenja u čekanju zbog prometa s druge veze). Iako nije moguće eliminirati nesigurnost svakog pojedinog mjerenja, ponašanje veze tokom vremena daje jasniju sliku, sugerirajući mogućnost primjene mjernih strategija dizajniranih da eliminišu nesigurnost.

Kombinovanjem ovih merenja sa pouzdanom petljom za praćenje, primenom najnovijih dostignuća u kontrolnim sistemima, možemo se nadati da će se razviti distribuirani protokol kontrole zagušenja koji će reagovati na stvarno zagušenje, a ne na gubitak paketa ili kratkoročno kašnjenje u redu čekanja. I konvergiraće se sa velikom verovatnoćom na Kleinrockovoj optimalnoj radnoj tački. Tako je započeo naš trogodišnji projekat razvoja sistema upravljanja zagušenjima zasnovanog na merenju dva parametra koji karakterišu rutu: kapacitet uskog grla i vreme povratnog putovanja paketa, ili BBR.

karakteristika uskog grla

Veza radi s maksimalnom propusnošću i minimalnim kašnjenjem kada je (ravnoteža brzine) stopa dolaska paketa na usko grlo jednaka BtlBw i (puna veza) ukupni podaci u letu jednaki BDP().

Prvi uslov osigurava da se usko grlo 100% iskoristi. Drugi osigurava da imamo dovoljno podataka da spriječimo jednostavno usko grlo, ali da ne prelijemo kanal. Sam uslov ravnoteže brzine ne ne garantuje red čekanja, samo konstantnu veličinu (na primjer, ako veza započne slanjem početnog prozora od 10 paketa na BDP od pet paketa, a zatim radi na potpuno istoj stopi uskog grla, tada će pet od deset početnih paketa ispuniti kanal, a višak će formirati stajaći red u uskom grlu koje se ne može apsorbirati). Slično tome, uvjet pune veze ne garantuje da nema čekanja (npr. veza šalje BDP rafale preko BDP/2 i u potpunosti iskorištava usko grlo, ali prosječni red čekanja je BDP/4). Jedini način da se minimizira red na uskom grlu i na cijelom kanalu je ispunjavanje oba uslova u isto vrijeme.

Vrijednosti BtlBw i RTprop se mijenjaju tokom životnog vijeka veze, tako da ih treba stalno procjenjivati. Trenutno, TCP prati RTT (vremenski interval između slanja paketa podataka i izvještavanja o njegovoj isporuci) jer je on neophodan za utvrđivanje gubitka. u bilo kom trenutku,

gdje predstavlja "šum" iz redova duž rute, primaočevu strategiju kašnjenja potvrde, agregaciju potvrde, itd. RTprop je fizičko svojstvo veze i mijenja se samo kada se promijeni sam kanal. Zato što se promjene kanala dešavaju na vremenskoj skali ≥ RTprop, tada će biti nepristrasna i efikasna procjena vremena
tj. pokrenuti u vremenskom prozoru (koji je obično od desetina sekundi do minuta).

Za razliku od RTT-a, ništa u TCP specifikacijama ne zahtijeva implementaciju za praćenje protoka uskog grla, ali dobra procjena ovoga može se dobiti praćenjem brzine isporuke. Kada se pošiljaocu vrati potvrda isporuke paketa, ona prikazuje RTT paketa i najavljuje isporuku podataka u letu kada paket ode. Prosječna stopa isporuke između slanja paketa i primanja potvrde je omjer isporučenih podataka i proteklog vremena: . Ova stopa mora biti manja ili jednaka kapacitetu uskog grla (dolazna količina je tačno poznata, tako da je sva nesigurnost u , koja mora biti veća ili jednaka stvarnom intervalu dolaska; prema tome, omjer mora biti manji ili jednak stvarnu stopu isporuke, koja je, zauzvrat, u redu, ograničena odozgo kapacitetom uskog grla). Stoga je okvir maksimalne stope isporuke efikasna, nepristrasna procjena BtlBw:

gdje je vremenski okvir tipično šest do deset RTT-a.

TCP mora zabilježiti vrijeme kada je svaki paket poslan da bi izračunao RTT. BBR popunjava ove zapise ukupnom količinom isporučenih podataka tako da dolazak svake potvrde izvještava i RTT i mjerenje brzine isporuke, koje filteri prevode u procjene RTprop i BtlBw.

Imajte na umu da su ove vrijednosti potpuno nezavisne: RTprop se može promijeniti (na primjer, kada se ruta promijeni), ali ima isto usko grlo, ili se BtlBw može promijeniti (na primjer, kada se promijeni širina bežičnog pojasa) bez promjene rute. (Nezavisnost oba ograničenja je razlog zašto ona moraju biti poznata kako bi se ponašanje transporta povezalo sa rutom otpreme). Budući da je RTprop vidljiv samo na lijevoj strani BDP-a, a BtlBw je vidljiv samo na desnoj strani na slici 1, oni podliježu principu nesigurnosti: kad god se jedno od dva može izmjeriti, drugo se ne može izmjeriti. Intuitivno, ovo se može shvatiti na sljedeći način: da bi se odredio kapacitet kanala, on mora biti preliven, što stvara red koji ne omogućava mjerenje dužine kanala. Na primjer, aplikacija sa protokolom zahtjev/odgovor možda nikada neće poslati dovoljno podataka da popuni kanal i promatra BtlBw. Višesatni prijenos velike količine podataka može provesti svo vrijeme u regiji sa ograničenim propusnim opsegom i primiti samo jedan RTprop uzorak iz RTT-a prvog paketa. Princip inherentne nesigurnosti znači da pored procjena za oporavak dva parametra rute, moraju postojati stanja koja istovremeno prate i ono što se može naučiti u trenutnoj radnoj tački i, kako informacije zastare, kako se premjestiti do radne točke gdje se mogu dobiti noviji podaci.

Mapiranje toka paketa u putanju isporuke

Osnovni BBR algoritam se sastoji od dva dela:

Kada dobijemo potvrdu (ack)

Svaka potvrda pruža nova mjerenja RTT i prosječne brzine isporuke koja ažuriraju procjene RTprop i BtlBw:

Funkcija onAck(packet) rtt = sada - packet.sendtime update_min_filter(RTpropFilter, rtt) isporučeno += packet.size isporučeno_vrijeme = sada Stopa isporuke = (isporučeno - packet.delivered) / (delivered_time - packet.delivered_time) if (deliveryBwF) if (deliveryBwF) currentMax || !packet.app_limited) update_max_filter(BtlBwFilter, stopa isporuke) if (app_limited_until > 0) app_limited_until = app_limited_until - packet.size
Provjera ako je potrebna zbog problema dvosmislenosti o kojem se govori u posljednjem paragrafu: pošiljatelji mogu biti ograničeni na aplikacije, što znači da aplikacija može ostati bez podataka da popuni mrežu. Ovo je prilično tipična situacija zbog prometa zahtjeva/odgovora. Kada postoji prilika za slanje, ali se podaci ne šalju, BBR označava odgovarajuće uzorke protoka kao "ograničeno aplikacijom", tj. app_limited (pogledajte send() pseudo-kod). Ovaj kod određuje koje uzorke treba uključiti u model propusnosti, tako da odražava ograničenja mreže, a ne ograničenja aplikacije. BtlBw je tvrda gornja granica za stopu isporuke, tako da bi izmjerena stopa isporuke veća od trenutne procjene BtlBw trebala ukazivati ​​na nisku procjenu BtlBw, bez obzira da li je uzorak bio ograničen na primjenu ili ne. U suprotnom, uzorci ograničeni primjenom se odbacuju. (Slika 1 pokazuje da je parametar BtlBw niži u regiji koja je ograničena aplikacijom isporuke Rate). Ove provjere sprječavaju da se filter BtlBw popuni niskim vrijednostima, što može usporiti slanje podataka.

Kada se podaci pošalju

Kako bi povezao stopu dolaska paketa sa stopom odlaska iz uskog grla, BBR prati svaki paket podataka. (BBR mora odgovarati stopa usko grlo: to znači da je praćenje sastavni dio arhitekture i fundamentalni dio operacije – dakle pacing_rate je glavni kontrolni parametar. Pomoćni parametar cwnd_gain povezuje inflight sa malim skupom BDP-a za rukovanje tipičnim patologijama mreže i prijemnika (pogledajte poglavlje o odloženim i proširenim potvrdama ispod). Konceptualno, procedura slanja u TCP-u izgleda kao sljedeći kod. (Na Linuxu, slanje podataka koristi efikasnu proceduru čekanja FQ/pacing, koja daje BBR linearne performanse sa jednom vezom preko višegigabitnih veza i rukuje hiljadama veza niže brzine sa zanemarljivim opterećenjem CPU-a.)

Funkcija send(packet) bdp = BtlBwFilter.currentMax × RTpropFilter.currentMin if (inflight >= cwnd_gain × bdp) // čekanje potvrde ili vremensko ograničenje ponovnog prijenosa return if (sada >= nextSendTime) packet = nextPacketToSend() if (!li packet_un) = povratak u letu packet.app_limited = (app_limited_until > 0) packet.sendtime = sada packet.delivered = isporučen packet.delivered_time = isporučeno_vrijeme brod(paket) nextSendTime = sada + packet.size / (pacing_gain × BtlBwMaxt) timer. nextSendTime)
Stabilno ponašanje

Brzina i količina podataka koji se šalju preko BBR-a zavise samo od BtlBw i RTpropa, tako da filteri kontroliraju ne samo procjene ograničenja uskog grla već i njihovu primjenu. Ovo stvara nestandardnu ​​kontrolnu petlju, prikazanu na slici 2, koja prikazuje RTT (plavo), letenje (zeleno) i brzinu isporuke (crveno) preko 700 milisekundi za 10-megabitni tok od 40 ms. Debela siva linija iznad brzine isporuke je status BtlBw max filtera. Trokutasti oblici se dobijaju petljom kroz faktor pacing_gain u BBR da bi se odredilo povećanje BtlBw. Dobitak u svakom dijelu ciklusa je prikazan vremenski usklađen sa podacima na koje je utjecao. Ovaj faktor je radio na RTT-u ranije kada su podaci poslani. To pokazuju horizontalne nepravilnosti u opisu slijeda događaja na lijevoj strani.

Slika 2

BBR minimizira kašnjenje jer se većina vremena provodi sa istim BDP u akciji. Zbog toga se usko grlo pomiče prema pošiljaocu, tako da povećanje BtlBw postaje neprimjetno. Stoga, BBR periodično troši RTprop interval na vrijednosti pacing_gain > 1, što povećava brzinu slanja i količinu podataka poslatih bez potvrde isporuke (u letu). Ako se BtlBw ne promijeni, tada se stvara red ispred uskog grla, povećavajući RTT, što drži stopu isporuke nepromijenjenom. (Red se može eliminisati slanjem podataka sa kompenzujućom vrednošću pacing_gain< 1 для следующего RTprop). Если BtlBw увеличивается, то скорость deliveryRate тоже увеличивается, а новое максимальное значение фильтра немедленно увеличивает базовую скорость отслеживания (pacing_rate). Iz tog razloga, BBR se eksponencijalno brzo prilagođava novoj veličini uskog grla. Slika 3 prikazuje ovaj efekat na 10 Mbps 40 ms stream, koji BtlBw iznenada povećava do 20 Mbps nakon 20 sekundi neprekidnog rada (na lijevoj strani grafikona), a zatim pada na 10 Mbps nakon još 20 sekundi neprekidnog rada na 20 Mbps (desna strana grafikona).

Slika 3

(U suštini BBR je jednostavan primjer "max-plus" kontrolnog sistema, novog pristupa kontrolnim sistemima zasnovanim na nestandardnoj max-plus algebri. Ovaj pristup omogućava prilagođavanje brzine [kontrolisano pojačanjem max] bez obzira na rast reda [kontrolirano povećanjem prosjek]. Primijenjeno na naš problem, ovo se svodi na jednostavnu, bezuvjetnu kontrolnu petlju, gdje se prilagođavanje promjenama fizičkih ograničenja automatski provodi promjenom filtera koji izražavaju ova ograničenja. Tradicionalni sistem bi zahtevao stvaranje mnogih kontrolnih petlji kombinovanih u složeni državni stroj da bi se postigao ovaj rezultat).

Ponašanje pri pokretanju jedne BBR niti

Moderne implementacije upravljaju događajima kao što su pokretanje, gašenje i oporavak od gubitka koristeći algoritame "događaja" s puno linija koda. BBR koristi kod prikazan gore (u prethodnom poglavlju, Mapiranje toka paketa u putanju isporuke), za sve. Obrada događaja se dešava prolaskom kroz niz "stanja". Sama "stanja" definirana su tablicom s jednom ili više fiksnih vrijednosti koeficijenta i izlaznih kriterija. Većina vremena se provodi u stanju ProbeBW, koje je opisano u poglavlju Ponašanje u stabilnom stanju. Stanja Startup i Drain se koriste prilikom pokretanja veze (slika 4). Za rukovanje vezom u kojoj se propusnost povećava za 12 redova veličine, stanje pokretanja implementira binarni algoritam pretraživanja za BtlBw koji koristi pojačanje da udvostruči brzinu prijenosa kada se brzina isporuke poveća. Ovo definira BtlBw u RTT-u, ali u isto vrijeme stvara dodatni red prije . Jednom kada Startup pronađe BtlBw, BBR sistem prelazi u stanje Drain, koje koristi inverzne transfere pokretanja da bi se riješilo viška reda, a zatim u stanje ProbeBW čim inflight padne na BDP liniju.

Slika 4

Slika 4 prikazuje prvu sekundu BBR toka od 10Mbit 40ms. Gornji grafikon prikazuje vrijeme i redoslijed događaja, kao i napredak pošiljaoca (zeleno) i primaoca (plavo): količinu prenesenih i primljenih podataka. Crvena linija prikazuje performanse CUBIC pošiljaoca pod istim uslovima. Vertikalne sive linije predstavljaju prijelazna vremena između BBR stanja. Donji grafikon prikazuje promjenu povratnog vremena (RTT) za obje veze. Napominjemo da vremenska skala za ovaj raspored odgovara vremenu prijema potvrde dolaska (ack). Stoga se može činiti da su grafikoni pomjereni u vremenu, ali u stvari događaji ispod odgovaraju trenucima kada BBR sistem sazna za te događaje i reaguje.

Donji grafikon na slici 4 upoređuje BBR i CUBIC. U početku, njihovo ponašanje je gotovo isto, ali BBR potpuno isprazni red koji je formiran prilikom pokretanja veze, a CUBIC to ne može učiniti. Nema model praćenja koji vam govori koliko je poslanih podataka suvišno. Stoga CUBIC manje agresivno povećava prijenos podataka bez potvrde, ali ovaj rast se nastavlja sve dok se bafer za usko grlo ne prelije i ne počne ispuštati pakete, ili dok primalac ne dostigne ograničenje poslanih podataka bez potvrde (TCP prijemni prozor).

Slika 5 prikazuje ponašanje RTT-a u prvih osam sekundi veze prikazanog na prethodnoj slici 4. CUBIC tehnologija (crveno) ispunjava cijeli raspoloživi bafer, zatim se rotira između 70% i 100% pun svakih nekoliko sekundi. Nakon pokretanja veze, BBR (zeleno) radi sa malo ili bez stvaranja reda.

Slika 5

Ponašanje kada se više BBR tokova susreće na uskom grlu

Slika 6 pokazuje kako se propusnost višestrukih BBR tokova konvergira na poštenom dijelu veze sa uskim grlom od 100 megabita/10 milisekundi. Trokutaste strukture okrenute prema dolje su stanja ProbeRTT veze u kojima samosinhronizacija ubrzava konvergenciju.

Slika 6

Ciklusi pojačanja ProbeBW (slika 2) potiču veće tokove da prepuste propusni opseg manjim tokovima, uzrokujući da svaki stream razumije svoje ispravno stanje. Ovo se dešava prilično brzo (nekoliko ciklusa ProbeBW), iako nepravednost može potrajati ako niti s kasnim pokretanjem precijene RTprop zbog ranog pokretanja niti (privremeno) koje stvaraju red čekanja.

Da bi saznali pravi RTProp, tok se pomiče lijevo od BDP linije koristeći stanje ProbeRTT: ako se procjena RTProp ne ažurira (tj. mjerenjem manjeg RTT-a) mnogo sekundi, tada BBR ulazi u stanje ProbeRTT , smanjuje količinu poslanih podataka (u letu) na četiri paketa za najmanje jedan dvostruki prolaz, a zatim se vraća u prethodno stanje. Kada veliki tokovi uđu u stanje ProbeRTT, mnogi paketi se uklanjaju iz reda tako da više tokova vidi novu RTprop vrijednost (novi minimalni RTT) odjednom. Ovo uzrokuje da njihove RTprop procjene budu nula u isto vrijeme, tako da svi zajedno ulaze u stanje ProbeRTT - a red se još više smanjuje, uzrokujući da više niti vidi novu vrijednost RTpropa, itd. Takva distribuirana koordinacija je ključni faktor za pravednu distribuciju propusnog opsega i istovremeno stabilnost.

BBR sinhronizuje niti oko željenog događaja, koji je prazan red na uskom grlu. Za razliku od ovog pristupa, prigušivanje zagušenja gubitka paketa sinhronizuje tokove oko neželjenih događaja kao što su periodični rast reda čekanja i prelivanje bafera, što povećava kašnjenje i gubitak paketa.

Iskustvo B4 WAN implementacije u Googleu

B4 mreža u Google-u je WAN velike brzine (mreža širokog područja) izgrađena na običnim jeftinim prekidačima. Gubici na ovim malim međuspremnicima su uglavnom uzrokovani slučajnim prilivom malih naleta saobraćaja. Google je 2015. godine počeo premeštati radni saobraćaj sa CUBIC na BBR. Nisu prijavljeni nikakvi problemi ili regresije, a od 2016. sav B4 TCP saobraćaj koristi BBR. Slika 7 ilustruje jedan razlog zašto je to učinjeno: propusnost BBR-a je konstantno 2-25 puta veća od CUBIC-a. Videli smo još veće poboljšanje, ali smo otkrili da je 75% BBR veza ograničeno na TCP prijemni bafer u kernelu, koji je tim za mrežne operacije namerno postavio na nisku vrednost (8 MB) kako bi sprečio CUBIC da preplavi mrežu megabajtima. viška saobraćaja bez potvrde isporuke (ako podijelite 8 MB sa 200 ms interkontinentalni RTT, dobićete maksimalno 335 Mbps). Ručno povećanje bafera za prijem na jednoj ruti SAD-Evropa odmah je povećalo BBR brzinu podataka na 2 Gbps, dok je CUBIC ostao na 15 Mbps - ovo 133-struko povećanje relativne propusnosti predviđali su Mathis i drugi radovi 1997. godine.

Slika 7

Slika 7 pokazuje relativno poboljšanje BBR u odnosu na CUBIC; umetak prikazuje kumulativne funkcije distribucije (CDF) za propusnost. Mjerenja su obavljena pomoću aktivnog sondiranja, koji otvara stalne BBR i CUBIC veze sa udaljenim podatkovnim centrima, a zatim prenosi 8 MB podataka svake minute. Sonde istražuju mnoge B4 rute između Sjeverne Amerike, Evrope i Azije.

Ogroman napredak - direktna posledica činjenice da je BBR ne koristi gubitak paketa kao indikator zagušenja. Da bi se postigla puna propusnost, postojeće tehnike ublažavanja zagušenja gubitaka paketa zahtijevaju stopu gubitka koja je manja od inverznog kvadrata BDP-a (npr. manji od jednog gubitka na 30 miliona paketa za vezu od 10 Gb/s i 100 ms). Slika 8 upoređuje izmjerenu neto propusnost na različitim nivoima gubitka paketa. U CUBIC algoritmu, tolerancija gubitka paketa je strukturno svojstvo algoritma, dok je u BBR konfiguracijski parametar. Kako se nivo gubitka u BBR približava maksimalnom dobitku ProbeBW, vjerovatnoća mjerenja stope isporuke stvarnog BtlBw naglo opada, uzrokujući potcjenjivanje maksimalnog filtera.

Slika 8

Slika 8 upoređuje korisnu propusnost BBR i CUBIC u 60-sekundnom streamu na 100 Mbps i 100 ms konekciju sa slučajnim gubitkom od 0,001% do 50%. Propusnost CUBIC-a se smanjuje za faktor 10 uz gubitak od 0,1% i potpuno se zaustavlja na više od 1%. Maksimalna propusnost je dio širine pojasa minus gubitak paketa (). BBR se zadržava na ovom nivou do nivoa gubitka od 5% i blizu njega do 15%.

Iskustvo implementacije YouTube Edge

BBR je raspoređen na YouTube i Google.com video serverima. Google izvodi mali eksperiment u kojem se mali postotak korisnika slučajno prebaci na BBR ili CUBIC. Reprodukcija videa preko BBR-a pokazuje značajno poboljšanje svih korisničkih ocjena kvaliteta usluge. Možda zato što je BBR-ovo ponašanje dosljednije i predvidljivije. BBR samo neznatno poboljšava propusni opseg veze, jer YouTube već prilagođava brzinu striminga na nivo mnogo niži od BtlBw kako bi minimizirao prekomjerno mrežno baferovanje i ponovno baferovanje. Ali čak i ovdje, BBR smanjuje prosječni srednji RTT za 53% na globalnom nivou i za više od 80% u zemljama u razvoju.

Slika 9 prikazuje srednje poboljšanje u RTT-u u poređenju sa BBR-om i CUBIC-om u odnosu na više od 200 miliona YouTube video pregleda izmjerenih na pet kontinenata tokom jedne sedmice. Više od polovine od 7 milijardi mobilnih konekcija u svijetu povezuje se preko 2,5G pri brzinama između 8 i 114 Kbps, što ima dobro dokumentirane probleme jer metode upravljanja zagušenjem gubitka paketa imaju tendenciju da prepune bafere. Usko grlo u ovim sistemima je obično između SGSN-a (serving GPRS Support Node) i mobilnog uređaja. SGSN softver radi na standardnoj PC platformi sa dovoljno RAM-a, gdje često postoje megabajti bafera između interneta i mobilnog uređaja. Slika 10 upoređuje (emulirano) SGSN kašnjenje između interneta i mobilnog za BBR i CUBIC. Horizontalne linije označavaju jednu od najozbiljnijih posljedica: TCP se prilagođava dugim RTT kašnjenjima osim SYN paketa koji pokreće vezu koja ima fiksno vremensko ograničenje, ovisno o operativnom sistemu. Kada mobilni uređaj primi veliku količinu podataka (na primjer, od automatskih ažuriranja softvera) preko SGSN-a s velikim međuspremnikom, uređaj ne može uspostaviti nikakvu vezu na Internetu sve dok se red ne oslobodi (SYN ACK paket je odgođen za više nego fiksno vremensko ograničenje SYN) .

Slika 9

Slika 10 prikazuje srednje stabilne RTT promjene i ovisnost o veličini bafera za vezu od 128 kbps i 40 ms sa osam BBR (zeleno) ili CUBIC (crveno) tokova. BBR drži red na minimalnim vrijednostima, bez obzira na veličinu bafera uskog grla i broj aktivnih niti. CUBIC niti uvijek ispunjavaju bafer, tako da se latencija linearno povećava s veličinom bafera.

Slika 10

Prilagodljivi pojas u mobilnoj ćeliji

Ćelijski sistemi prilagođavaju propusni opseg za svakog korisnika dijelom ovisno o predviđanju potražnje koje uzima u obzir red paketa koji je namijenjen tom korisniku. Rane verzije BBR-a bile su konfigurisane da stvaraju veoma male redove, što dovodi do zastoja veza pri malim brzinama. Povećanje vršnog pacing_gain za ProbeBW i povećanje redova doveli su do manjeg broja zaustavljenih veza. Ovo pokazuje mogućnost odlične adaptacije za neke mreže. Sa trenutnom vrijednošću vršnog pojačanja, nema degradacije ni u jednoj mreži u odnosu na CUBIC.

Odgođeni i rastegnuti ack paketi

Mobilne, WiFi i širokopojasne mreže često odlažu i gomilaju ack pakete. Kada je let ograničen na jedan BDP, to uzrokuje zastoje koji smanjuju propusnost. Povećanje ProbeBW-ovog cwnd_gain faktora na dva omogućilo je neometani prenos da se nastavi sa predviđenom brzinom isporuke čak i kada su paketi potvrđivanja bili odloženi za jedan RTT. Ovo u velikoj mjeri sprječava kvarove.

Trenutni graničnici kante

Prvo uvođenje BBR-a na YouTube pokazalo je da većina ISP-a u svijetu manipulira prometom sa trenutnim limitatorima brzine. Bucket je obično pun na početku veze, tako da BBR poznaje BtlBw parametar za osnovnu mrežu. Ali kada se bucket isprazni, svi paketi poslani brže od (mnogo sporije od BtlBw) brzine punjenja bucketa se odbacuju. BBR na kraju nauči ovu novu stopu isporuke, ali ciklično pojačanje ProbeBW rezultira konstantnim umjerenim gubitkom. Da bismo smanjili gubitak propusnog opsega uzvodno i povećanje kašnjenja aplikacija zbog ovog gubitka, dodali smo prilagođeni detektor klipera i eksplicitni model klipera u BBR. Također aktivno istražujemo najbolje načine da eliminišemo štetu od ograničenja brzine.

Konkurencija sa metodama upravljanja zagušenjem gubitka paketa

BBR se odnosi na pravično dijeljenje propusnog opsega uskog grla, bilo u konkurenciji sa drugim BBR tokovima ili sa tokovima kojima se upravlja tehnikama ublažavanja zagušenja gubitka paketa. Čak i kada potonji popune dostupni bafer, ProbeBW i dalje pouzdano pomjera BtlBw rezultat prema poštenom podjelu toka, a ProbeRTT smatra da je RTProp rezultat dovoljno visok za konvergenciju tit-za-tat do poštene podjele. Međutim, neupravljani baferi rutera koji premašuju neke BDP-ove uzrokuju naslijeđene konkurente sa smanjenjem zagušenja gubitka paketa da povećaju red čekanja i zgrabe više nego što je to poštena igra. Uklanjanje ovoga je još jedno područje aktivnog istraživanja.

Zaključak

Ponovno promišljanje načina na koji se upravlja zagušenjem donosi ogromne koristi. Umjesto korištenja događaja kao što su gubitak bafera ili zauzetost bafera, koji su slabo povezani sa zagušenjem, BBR počinje s formalnim Kleinrock modelom zagušenja i njegovom povezanom optimalnom radnom točkom. Nesrećni zaključak da je "nemoguće" istovremeno odrediti parametre kritičnog kašnjenja i propusnog opsega zaobilazi se zapažanjem da se oni mogu predvidjeti istovremeno. Najnovija dostignuća u sistemima upravljanja i teoriji procjene se zatim primjenjuju kako bi se stvorila jednostavna distribuirana kontrolna petlja koja se približava optimalnom potpunim korištenjem mreže uz održavanje malog reda. Googleova implementacija BBR-a dostupna je u Linux kernelu otvorenog koda i detaljno je opisana u dodatku ovom članku.

BBR tehnologija se koristi na Google B4 kičmi, poboljšavajući propusni opseg za redove veličine u poređenju sa CUBIC-om. Također se primjenjuje na Google i YouTube web servere, značajno smanjujući kašnjenje na svih pet do sada testiranih kontinenata, a posebno u zemljama u razvoju. BBR tehnologija radi isključivo na strani pošiljaoca i ne zahtijeva promjene u protokolu, primaocu ili mreži, što omogućava postupnu implementaciju. Zavisi samo od RTT i obavještenja o isporuci paketa, tako da se može koristiti u većini Internet transportnih protokola.

Priznanje

Autori su zahvalni Lenu Kleinroku što je ukazao na to kako pravilno upravljati zastojima. Zahvaljujemo Larryju Brakmu za njegov pionirski rad na sistemima upravljanja zagušenjima u Vegasu i New Vegasu koji je predvidio mnoge elemente BBR-a, kao i za njegove savjete i smjernice tokom ranog razvoja BBR-a. Također bismo željeli zahvaliti Eric Dumazet, Nandita Dukkipati, Jana Iyengar, Ian Swett, M. Fitz Nowlan, David Wetherall, Leonidas Leonidas Kontothanassis, Amin Vahdat, i timovima za infrastrukturu Google BwE i YouTube na njihovoj neprocjenjivoj pomoći i podršci.

Aplikacija - detaljan opis

State Machine za sekvencijalno sondiranje

Pacing_gain kontrolira brzinu slanja paketa u odnosu na BtlBw i ključ je za pametnu BBR funkciju. Kada je pacing_gain veći od jedan, inflight se povećava, a interval između pristizanja paketa se smanjuje, što pomiče vezu na desnu stranu na slici 1. Kada je pacing_gain manji od jedan, javlja se suprotan efekat, veza se pomiče ulijevo.

BBR koristi pacing_gain da implementira jednostavnu mašinu za sondiranje stanja koja se izmjenjuje između testiranja visoke propusnosti i kraćeg povratnog testiranja. (Ne morate testirati manji opseg, jer njime automatski rukuje BtlBw msx filter: nova mjerenja odražavaju pad, tako da će BtlBw ispraviti sam sebe čim se posljednje stare promjene uklone iz filtera vremena čekanja. RTprop min filter upravlja povećanjem putanje isporuke na isti način) .

Ako se širina pojasa uskog grla poveća, BBR mora slati podatke brže da bi to otkrio. Slično tome, ako se promijeni stvarno vrijeme povratnog paketa, to mijenja BDP, i stoga BDP mora slati podatke sporije kako bi zadržao let ispod BDP-a kako bi izmjerio novi RTprop. Stoga, jedini način da se otkriju ove promjene je pokretanje eksperimenata, slanje brže radi testiranja povećanja BtlBw ili slanje sporije da se testira smanjenje RTpropa. Učestalost, opseg, trajanje i struktura ovih eksperimenata se razlikuju u zavisnosti od onoga što je već poznato (pokretanje veze naspram stabilnog stanja) i ponašanja aplikacije koja šalje podatke (povremeno naspram postojanog).

Stabilno stanje

BBR niti provode većinu svog vremena u stanju ProbeBW ispitujući opseg koristeći metodu tzv dobiti biciklizam, što pomaže BBR tokovima da postignu visoku propusnost, nisko kašnjenje u čekanju i konvergenciju u priličnom dijelu propusnog opsega. Koristeći dobiti biciklizam, BBR kruži kroz niz vrijednosti za povećanje pacing_gain. Koristi se osam faza ciklusa sa sljedećim vrijednostima: 5/4, 3/4, 1, 1, 1, 1, 1, 1. Svaka faza obično teče unutar predviđenog RTprop. Ovaj dizajn omogućava petlji pojačanja da prvo ispita kanal za veći propusni opseg sa vrijednošću od pacing_gain veći od 1,0, a zatim raspršite bilo koji rezultirajući red s pacing_gain za isti iznos manji od 1,0, a zatim krstarenje s kratkim naletom koeficijenata od tačno 1,0. Prosječna dobit za sve faze je 1,0 jer ProbeBW teži da prosjek odgovara dostupnom propusnom opsegu i stoga održava propusni opseg visokim bez povećanja reda. Imajte na umu da se, iako se ciklusi promjene stope mijenjaju pacing_gain, ali vrijednost cwnd_gain ostaje uvijek jednaka dva jer se odloženi i prošireni paketi potvrde mogu pojaviti u bilo kojem trenutku (pogledajte poglavlje o odloženim i proširenim paketima potvrde).

Štaviše, kako bi se poboljšalo miješanje tokova i pravedno dijeljenje propusnog opsega, te kako bi se smanjili redovi kada više BBR tokova dijeli usko grlo, BBR nasumično mijenja faze ProbeBW ciklusa nasumično birajući prvu fazu među svim vrijednostima osim 3/4. Zašto petlja ne počinje na 3/4? Glavna svrha ove vrijednosti koeficijenta je da rasprši svaki red koji se može formirati tokom primjene koeficijenta 5/4, kada je kanal već pun. Kada proces izađe iz stanja Drain ili ProbeRTT i uđe u ProbeBW, nema reda, tako da faktor 3/4 ne radi svoj posao. Primjena 3/4 u takvom kontekstu ima samo negativan učinak: popunjavanje kanala u ovoj fazi će biti 3/4, a ne 1. Dakle, početak petlje sa 3/4 ima samo negativan učinak, ali ne i pozitivan, i budući da se ulazak u stanje ProbeBW događa na početku bilo koje veze dovoljno dugo da BBR koristi ovu malu optimizaciju.

BBR niti rade zajedno da povremeno isprazne red uskih grla sa stanjem zvanim ProbeRTT. U bilo kojem stanju osim samog ProbeRTT, ako procjena RTProp nije ažurirana (na primjer, mjerenjem manjeg RTT-a) duže od 10 sekundi, tada BBR ulazi u stanje ProbeRTT i smanjuje cwnd na vrlo malu vrijednost (četiri rafala) . Zadržavanjem ovog minimalnog broja paketa u letu najmanje 200 ms i za vrijeme povratnog putovanja jednog paketa, BBR izlazi iz ProbeRTT stanja i ulazi u Startup ili ProbeBW, ovisno o procjeni da li je kanal već pun.

BBR je dizajniran da radi većinu vremena (oko 98%) u stanju ProbeBW, a ostatak vremena u ProbeRTT na osnovu skupa kompromisa. ProbeRTT stanje traje dovoljno dugo (najmanje 200 ms) da dozvoli nitima s različitim RTT-ovima da imaju istodobna ProbeRTT stanja, ali u isto vrijeme traje dovoljno kratko da ograniči degradaciju performansi na oko 2 posto (200 ms / 10 sekundi). Prozor RTprop filtera (10 sekundi) je dovoljno mali da se brzo prilagodi promjeni nivoa prometa ili promjenama ruta, ali dovoljno velik za interaktivne aplikacije. Takve aplikacije (npr. web stranice, daljinski pozivi procedura, video snimci) često pokazuju prirodne periode tišine ili male aktivnosti unutar ovog prozora, gdje je brzina protoka dovoljno spora ili dovoljno duga da rasprši red na uskom grlu. RTprop filter tada oportunistički preuzima ova RTprop mjerenja i RTProp se ažurira bez potrebe za ProbeRTT. Prema tome, tokovi obično trebaju žrtvovati samo 2% propusnog opsega ako više tokova obilno preplavi kanal za cijeli RTProp prozor.

Ponašanje pri pokretanju

Kada se BBR nit pokrene, ona izvodi svoj prvi (i najbrži) sekvencijalni proces provjere/dequeua. Mrežni propusni opseg varira u rasponu od 10 12 - od nekoliko bita do 100 gigabita u sekundi. Da bi saznao vrijednost BtlBw sa takvom ogromnom promjenom raspona, BBR izvodi binarno pretraživanje u prostoru brzina. Vrlo brzo pronalazi BtlBw (dvostruki paketi), ali na račun stvaranja reda u 2BDP u posljednjoj fazi pretrage. Pretraživanje se vrši u Startup stanju u BBR, a pražnjenje kreiranog reda se vrši u stanju Drain.

Prvo, Startup eksponencijalno povećava stopu slanja podataka, udvostručujući je svaki krug. Da bi se postigao ovako brz zvuk na što opušteniji način, pri startovanju vrednosti pojačanja pacing_gain i cwnd_gain su postavljeni na , na minimalnu vrijednost koja vam omogućava da udvostručite brzinu slanja podataka u svakoj rundi. Čim se kanal napuni, koeficijent cwnd_gain ograničava veličinu reda na .

U stanju početka veze, BBR procjenjuje da li je kanal pun tražeći plato u procjeni BtlBw. Ako ustanovi da je prošlo nekoliko (tri) rundi u kojima pokušaj udvostručavanja brzine isporuke zapravo ne daje veliko povećanje brzine (manje od 25%), onda smatra da je dostigao BtlBw, pa izlazi iz Startup stanja i ulazi u stanje Drain. BBR čeka tri runde da dobije uvjerljive dokaze da pošiljaočev plato zapažene stope isporuke nije privremeni efekat perioda prijema. Čekanje u tri kruga omogućava dovoljno vremena za automatsko podešavanje na strani primaoca da otvori prozor za prijem i da BBR pošiljalac otkrije potrebu za povećanjem BtlBw: u prvom krugu, algoritam za automatsko podešavanje prozora prijema povećava prozor prijema; u drugom krugu, pošiljalac ispunjava povećani prozor primanja; u trećem krugu pošiljalac prima uzorke sa povećanom stopom isporuke. Ovo ograničenje od tri kruga se pokazalo u YouTube implementacijama.

U stanju Drain, BBR algoritam ima tendenciju da brzo isprazni red koji je formiran u stanju početka veze prelaskom na pacing_gain sa obrnutim vrijednostima od onih koje se koriste u stanju pokretanja. Kada se broj paketa u letu poklapa sa procjenom BDP-a, to znači da BBR procjenjuje red čekanja kao potpuno prazan, ali je kanal i dalje pun. BBR tada izlazi iz stanja odvoda i ulazi u ProbeBW.

Imajte na umu da pokretanje BBR veze i sporo pokretanje CUBIC-a uče propusnost uskog grla eksponencijalno, udvostručujući brzinu slanja u svakoj rundi. Međutim, oni su fundamentalno različiti. Prvo, BBR pouzdanije određuje dostupnu širinu pojasa, jer ne prestaje da traži u slučaju gubitka paketa ili (kao CUBIC-ov Hystart) povećanja kašnjenja. Drugo, BBR glatko povećava brzinu slanja, dok CUBIC ima rafal paketa u svakoj rundi (čak i sa pejsingom), a zatim period tišine. Slika 4 prikazuje broj paketa u letu i posmatrani RTT za svaku poruku potvrde od BBR i CUBIC.

Reagiranje na tranzicione situacije

Mrežni put i promet koji teče kroz njega mogu doživjeti iznenadne dramatične promjene. Kako bi im se glatko i pouzdano prilagodio, kao i smanjio gubitak paketa u ovim situacijama, BBR koristi niz strategija za implementaciju svog osnovnog modela. Prvo, BBR smatra da je cilj prema kojem je struja cwnd oprezno prilazi odozdo, povećavajući se cwnd svaki put ne više od količine podataka za koju su primljene potvrde isporuke. Drugo, s timeoutom ponovnog prijenosa, što znači da pošiljatelj smatra da su svi paketi u letu izgubljeni, BBR konzervativno smanjuje cwnd na jedan paket i šalje jedan paket (baš kao algoritmi za kontrolu zagušenja gubitka paketa kao što je CUBIC). Na kraju, kada pošiljalac primijeti gubitak paketa, ali još uvijek ima paketa u letu, prvi korak u procesu nadoknade gubitka je da BBR privremeno smanji brzinu slanja na trenutnu brzinu isporuke; u drugom i narednim rundama nadoknade gubitka, provjerava da brzina slanja nikada ne premašuje trenutnu stopu isporuke za više od dva puta. Ovo uvelike smanjuje prolazne troškove kada BBR naiđe na limitatore brzine ili se takmiči sa drugim tokovima u baferu koji je uporediv sa BDP.

Linkovi

1. Abrahamsson, M. 2015. TCP ACK supresija. IETF AQM mailing lista;