Softueri me burim të hapur është bërë një element themelor për disa nga faqet e internetit më të mëdha. Me rritjen e këtyre faqeve të internetit, janë shfaqur praktikat dhe udhëzimet më të mira për arkitekturën e tyre. Ky kapitull synon të mbulojë disa nga çështjet kryesore që duhen marrë parasysh gjatë dizajnimit të faqeve të mëdha të internetit, si dhe disa nga komponentët bazë të përdorur për të arritur këto qëllime.

Ky kapitull fokusohet në analizën e sistemeve të ueb-it, megjithëse një pjesë e materialit mund të ekstrapolohet edhe në sisteme të tjera të shpërndara.

1.1 Parimet e ndërtimit të sistemeve të uebit të shpërndarë

Çfarë do të thotë saktësisht të krijosh dhe menaxhosh një uebsajt ose aplikacion të shkallëzuar? Në një nivel primitiv, ai thjesht lidh përdoruesit me burime të largëta përmes internetit. Dhe burimet, ose qasja në ato burime, të cilat janë të shpërndara nëpër serverë të shumtë, janë lidhja që e bën faqen e internetit të shkallëzueshme.

Ashtu si shumica e gjërave në jetë, marrja e kohës për të planifikuar përpara për të ndërtuar shërbimin tuaj të internetit mund të ndihmojë. të kuptuarit e disa konsideratave dhe kompromiseve pas faqeve të internetit të mëdha mund të shpërblehet në vendime më të zgjuara kur ndërtoni uebsajte më të vogla. Më poshtë janë disa nga parimet kryesore që ndikojnë në hartimin e sistemeve të internetit në shkallë të gjerë:

• Disponueshmëria: Koha e funksionimit të faqes në internet është kritike për reputacionin dhe funksionalitetin e shumë kompanive. Për disa nga dyqanet më të mëdha të shitjes me pakicë në internet, të qenit i padisponueshëm edhe për disa minuta mund të rezultojë në mijëra ose miliona dollarë të ardhura të humbura. Kështu, zhvillimi i sistemeve të tyre që janë gjithmonë të disponueshme dhe elastike ndaj dështimit është gjithashtu një kërkesë themelore e biznesit dhe teknologjisë. Disponueshmëria e lartë në sistemet e shpërndara kërkon shqyrtim të kujdesshëm të tepricës për komponentët kryesorë, rikuperim të shpejtë nga dështimet e pjesshme të sistemit dhe zvogëlim të qetë kur lindin probleme.
• Performanca: Performanca e faqes në internet është bërë një metrikë e rëndësishme për shumicën e sajteve. Shpejtësia e faqes në internet ndikon në përvojën dhe kënaqësinë e përdoruesit, si dhe në renditjen e motorëve të kërkimit - një faktor që ndikon drejtpërdrejt në mbajtjen dhe të ardhurat e audiencës. Si rezultat, çelësi është krijimi i një sistemi që është i optimizuar për përgjigje të shpejta dhe vonesë të ulët.
• Besueshmëria: sistemi duhet të jetë i fortë i tillë që një kërkesë specifike për të dhëna të kthejë të dhëna specifike në mënyrë konsistente. Në rast ndryshimi ose përditësimi të të dhënave, e njëjta kërkesë duhet të kthejë të dhëna të reja. Përdoruesit duhet të dinë nëse diçka është shkruar në sistem ose është ruajtur në të, atëherë ata mund të jenë të sigurt se ajo do të mbetet në vend për mundësinë e rikthimit të të dhënave më vonë.
• Shkallëzueshmëria: Kur bëhet fjalë për çdo sistem të madh të shpërndarë, madhësia është vetëm një nga shumë gjëra që duhet marrë parasysh. Po aq të rëndësishme janë përpjekjet për të rritur xhiron për të trajtuar vëllime të mëdha të ngarkesës së punës, që zakonisht referohet si shkallëzueshmëria e sistemit. Shkallueshmëria mund t'i referohet parametrave të ndryshëm të një sistemi: sasia e trafikut shtesë që mund të përballojë, sa e lehtë është të rritet kapaciteti i ruajtjes ose sa më shumë transaksione të tjera mund të përpunohen.
• Kontrollueshmëria: Projektimi i një sistemi që është i lehtë për t'u përdorur është një tjetër faktor i rëndësishëm. Menaxhimi i sistemit barazohet me shkallëzueshmërinë e operacioneve "mirëmbajtje" dhe "përditësime". Për të siguruar menaxhueshmërinë, është e nevojshme të merren parasysh çështjet e lehtësisë së diagnostikimit dhe të kuptuarit të problemeve të shfaqura, lehtësia e përditësimit ose modifikimit, sistemi i çuditshëm në operacion. (d.m.th., a funksionon siç pritej pa dështime ose përjashtime?)
• Çmimi: Kostoja është një faktor i rëndësishëm. Kjo padyshim mund të përfshijë kostot e harduerit dhe softuerit, por është gjithashtu e rëndësishme të merren parasysh aspekte të tjera të nevojshme për vendosjen dhe mirëmbajtjen e sistemit. Duhet të parashikohen të gjitha sasia e kohës së zhvilluesit që duhet për të ndërtuar sistemin, sasia e përpjekjeve operacionale të nevojshme për të vënë në funksion sistemin dhe madje edhe një nivel të mjaftueshëm trajnimi. Kostoja është kostoja totale e pronësisë.

Secili prej këtyre parimeve është baza për marrjen e vendimeve në hartimin e një arkitekture të shpërndarë ueb. Megjithatë, ato mund të bien ndesh me njëri-tjetrin, sepse arritja e qëllimeve të njërit vjen në kurriz të neglizhimit të të tjerëve. Një shembull i thjeshtë: zgjedhja për të shtuar thjesht serverë të shumtë si një zgjidhje e performancës (shkallëzueshmëria) mund të rrisë kostot e menaxhimit (ju duhet të përdorni një server shtesë) dhe blerjet e serverit.

Kur zhvilloni çdo lloj aplikacioni në internet, është e rëndësishme të merren parasysh këto parime kryesore, edhe nëse konfirmohet se projekti mund të dhurojë një ose më shumë prej tyre.

1.2 Bazat

Kur merret në konsideratë arkitektura e sistemit, ka disa çështje që duhen theksuar, të tilla si cilët komponentë ia vlen të përdoren, si përshtaten së bashku dhe çfarë kompensimesh mund të bëhen. Investimi i parave në shkallëzim pa nevojën e dukshme për to nuk mund të konsiderohet një vendim i zgjuar biznesi. Megjithatë, disa largpamësi në planifikim mund të kursejnë ndjeshëm kohë dhe burime në të ardhmen.

Ky seksion fokusohet në disa nga faktorët bazë që janë kritikë për pothuajse të gjitha aplikacionet e mëdha të uebit: Shërbimet,
tepricë, segmentimi, dhe trajtimi i refuzimit... Secili prej këtyre faktorëve përfshin zgjedhje dhe kompensime, veçanërisht në kontekstin e parimeve të përshkruara në seksionin e mëparshëm. Le të japim një shembull për sqarim.

Shembull: Aplikacioni për pritjen e imazheve

Ju ndoshta keni postuar imazhe në ueb më parë. Për faqet e mëdha që ruajnë dhe shpërndajnë imazhe të shumta, ka sfida në krijimin e një arkitekture me kosto efektive, shumë të besueshme që ka vonesë të ulët të përgjigjes (rikthim i shpejtë).

Imagjinoni një sistem ku përdoruesit mund të ngarkojnë imazhet e tyre në një server qendror dhe imazhet mund të kërkohen përmes një lidhjeje faqeje ose API, të ngjashme me Flickr ose Picasa. Për të thjeshtuar përshkrimin, le të supozojmë se ky aplikacion ka dy detyra kryesore: aftësinë për të ngarkuar (shkruar) imazhe në server dhe për të kërkuar imazhe. Sigurisht, ngarkimi efikas është i rëndësishëm, por shpërndarja e shpejtë do të jetë një përparësi kur përdoruesit e kërkojnë atë (për shembull, imazhet mund të kërkohen të shfaqen në një faqe interneti ose një aplikacion tjetër). Ky funksionalitet është i ngjashëm me atë që mund të ofrojë një server në internet ose një server i skajshëm i Rrjetit të shpërndarjes së përmbajtjes (CDN). Një server CDN zakonisht ruan objektet e të dhënave në shumë vendndodhje, në mënyrë që vendndodhja e tyre gjeografike / fizike të jetë më afër përdoruesve, gjë që çon në performancë më të mirë.

Aspekte të tjera të rëndësishme të sistemit:

• Numri i imazheve të ruajtura mund të jetë i pakufishëm, kështu që shkallëzueshmëria e ruajtjes duhet të merret parasysh nga ky këndvështrim.
• Duhet të ketë vonesë të ulët për shkarkimet/kërkesat e imazheve.
• Nëse një përdorues ngarkon një imazh në server, atëherë të dhënat e tij duhet të mbeten gjithmonë të plota dhe të aksesueshme.
• Sistemi duhet të jetë i lehtë për t'u mirëmbajtur (menaxhimi).
• Meqenëse hostimi i imazheve nuk është shumë fitimprurës, sistemi duhet të jetë me kosto efektive.

Një problem tjetër i mundshëm me këtë dizajn është se një server në internet si Apache ose lighttpd zakonisht ka një kufi të sipërm në numrin e lidhjeve të njëkohshme që mund të trajtojë (parazgjedhja është rreth 500, por mund të jetë shumë më e lartë). dhe me trafik të lartë, shkruan mund ta shfrytëzojë shpejt këtë kufi. Meqenëse leximet mund të jenë asinkrone, ose të përfitojnë nga optimizimet e tjera të performancës si kompresimi ose copëtimi i gzip-it, serveri i uebit mund të ndërrojë leximet e furnizimit më shpejt dhe të kalojë ndërmjet klientëve, duke shërbyer shumë më tepër kërkesa sesa numri maksimal i lidhjeve (me Apache dhe me maksimumin numri i lidhjeve i vendosur në 500, është mjaft e mundur të shërbehen disa mijëra kërkesa leximi në sekondë). Regjistrimet, nga ana tjetër, priren të mbajnë një lidhje të hapur gjatë gjithë kohës së shkarkimit. Për shembull, transferimi i një skedari 1MB në server mund të zgjasë më shumë se 1 sekondë në shumicën e rrjeteve shtëpiake, me rezultat që serveri në internet do të jetë në gjendje të përpunojë vetëm 500 nga këto shkrime të njëkohshme.

Figura 1.2: Ndarja e leximit dhe shkrimit

Parashikimi i këtij problemi të mundshëm sugjeron se ekziston nevoja për të ndarë leximin dhe shkrimin e imazheve nga shërbimet e pavarura të paraqitura në. Kjo do të lejojë jo vetëm shkallëzimin e secilit prej tyre individualisht (pasi ka të ngjarë që ne gjithmonë të bëjmë më shumë lexime sesa shkrime), por edhe të mbajmë krah për krah atë që po ndodh në secilin shërbim. Së fundi, ai do të përcaktojë problemet e ardhshme, duke e bërë më të lehtë diagnostikimin dhe vlerësimin e problemeve të qasjes së ngadaltë të leximit.

Avantazhi i kësaj qasjeje është se ne jemi në gjendje të zgjidhim problemet në mënyrë të pavarur nga njëri-tjetri - pa pasur nevojë të mendojmë për nevojën për të regjistruar dhe përvetësuar imazhe të reja në të njëjtin kontekst. Të dyja këto shërbime ende përdorin korpusin global të imazhit, por kur përdorin metoda të përshtatshme për një shërbim të caktuar, ata janë në gjendje të optimizojnë performancën e tyre (për shembull, duke vendosur kërkesat në radhë ose duke ruajtur imazhe të njohura në memorie - më shumë për këtë më vonë). Për sa i përket mirëmbajtjes dhe kostos, çdo shërbim mund të shkallëzohet në mënyrë të pavarur sipas nevojës. Dhe ky është një faktor pozitiv, pasi kombinimi dhe përzierja e tyre mund të ndikojë pa dashje në performancën e tyre, si në skenarin e përshkruar më sipër.

Natyrisht, modeli i mësipërm do të funksionojë më mirë nëse keni dy pika fundore të ndryshme (në fakt, kjo është shumë e ngjashme me disa implementime të ofruesve të ruajtjes së cloud dhe Rrjeteve të shpërndarjes së përmbajtjes). Ka shumë mënyra për të zgjidhur këto probleme dhe në secilin rast mund të gjendet një kompromis.

Për shembull, Flickr e zgjidh këtë problem leximi-shkrimi duke shpërndarë përdoruesit midis moduleve të ndryshme, në mënyrë që secili modul mund t'i shërbejë vetëm një numri të kufizuar përdoruesish specifikë, dhe ndërsa numri i përdoruesve rritet, më shumë module shtohen në grup (shih prezantimin e shkallëzimit të Flickr .
http://mysqldba.blogspot.com/2008/04/mysql-uc-2007-presentation-file.html). Në shembullin e parë, është më e lehtë të shkallëzohet hardueri bazuar në ngarkesën aktuale të përdorimit (numri i leximeve dhe shkrimeve në të gjithë sistemin), ndërsa Flickr rritet në bazë të bazës së përdoruesve (megjithatë, kjo supozon përdorim të barabartë midis përdoruesve të ndryshëm, kështu që nevojiten kapacitet të planifikohet me marzh). Në të kaluarën, mosdisponueshmëria ose një problem me një nga shërbimet e bënte funksionalitetin e të gjithë sistemit jofunksional (për shembull, askush nuk mund të shkruajë skedarë), atëherë mosdisponueshmëria e një prej moduleve Flickr do të prekë vetëm përdoruesit e lidhur me të. Në shembullin e parë, është më e lehtë të kryhen operacione në një grup të tërë të dhënash - për shembull, përditësimi i shërbimit të shkrimtarit për të përfshirë meta të dhëna të reja, ose kërkimi nëpër të gjitha metadatat e imazhit - ndërsa me arkitekturën Flickr, çdo modul duhej të përditësohej. ose u kërkua (ose shërbimi i kërkimit duhej të krijohej për të renditur meta të dhënat që synohen në të vërtetë për këtë).

Sa i përket këtyre sistemeve, nuk ka ilaç, por duhet të vazhdoni gjithmonë nga parimet e përshkruara në fillim të këtij kapitulli: përcaktoni nevojat e sistemit (ngarkoni me operacione "lexoni" ose "shkruani" ose të gjitha menjëherë, niveli i paralelizmit , pyetje mbi grupet e të dhënave, diapazonin, provat, etj.), kryeni krahasime krahasuese të alternativave të ndryshme, kuptoni kushtet për dështimin e mundshëm të sistemit dhe zhvilloni një plan gjithëpërfshirës të dështimit.

Tepricë

Për të trajtuar dështimin në mënyrë elegante, arkitektura e uebit duhet të ketë tepricë në shërbimet dhe të dhënat e saj. Për shembull, nëse ka vetëm një kopje të një skedari të ruajtur në një server të vetëm, humbja e atij serveri do të nënkuptojë gjithashtu humbjen e skedarit. Kjo situatë vështirë se mund të karakterizohet pozitivisht dhe zakonisht mund të shmanget duke krijuar kopje të shumta ose kopje rezervë.

I njëjti parim vlen edhe për shërbimet. Ju mund të mbroni kundër dështimit të një nyjeje duke ofruar një pjesë integrale të funksionalitetit për një aplikacion për të siguruar që kopjet ose versionet e shumta të një aplikacioni të funksionojnë njëkohësisht.

Duke krijuar tepricë në sistem, ju mund të eliminoni dobësitë dhe të ofroni funksione të tepërta ose të tepërta në rast fatkeqësie. Për shembull, nëse ka dy raste të të njëjtit shërbim që funksionon në "prodhim" dhe njëri prej tyre dështon tërësisht ose pjesërisht, sistemi mund ta kapërcejë dështimin në kurriz të kalimi në një kopje pune.
Ndërrimi mund të ndodhë automatikisht ose të kërkojë ndërhyrje manuale.

Një tjetër rol kyç i tepricës së shërbimit është krijimi arkitekturë jo e përbashkët... Me këtë arkitekturë, çdo nyje është në gjendje të punojë në mënyrë të pavarur dhe, për më tepër, në mungesë të një "truri" qendror që kontrollon gjendjet ose koordinon veprimet e nyjeve të tjera. Promovon shkallëzueshmërinë, pasi shtimi i nyjeve të reja nuk kërkon kushte ose njohuri të veçanta. Më e rëndësishmja, nuk ka asnjë pikë kritike dështimi në këto sisteme, duke i bërë ato shumë më elastike ndaj dështimit.

Për shembull, në aplikacionin tonë të serverit të imazheve, të gjitha imazhet do të kishin kopje të tepërta diku tjetër në harduer (idealisht me një vendndodhje të ndryshme gjeografike në rast të një fatkeqësie si një tërmet ose zjarr në qendrën e të dhënave) dhe shërbimet e aksesit në imazh do të jenë të tepërta , me të gjithë ata që mund të shërbejnë kërkesa. (Cm. .)
Duke parë përpara, balancuesit e ngarkesës janë një mënyrë e shkëlqyer për ta bërë këtë të mundur, por më shumë për këtë më poshtë.

Figura 1.3: Aplikacion i tepërt i pritjes së imazhit

Segmentimi

Grupet e të dhënave mund të jenë aq të mëdha sa nuk mund të vendosen në një server të vetëm. Mund të ndodhë gjithashtu që operacionet llogaritëse të konsumojnë shumë burime kompjuterike, duke ulur performancën dhe duke kërkuar një rritje të fuqisë. Në çdo rast, ju keni dy mundësi: shkallëzim vertikal ose horizontal.

Rritja do të thotë të shtosh më shumë burime në një server të vetëm. Pra, për një grup të dhënash shumë të madhe, kjo do të nënkuptonte shtimin e më shumë (ose më shumë) disqeve të ngurtë, dhe kështu i gjithë grupi i të dhënave mund të përshtatet në një server. Në rastin e operacioneve llogaritëse, kjo do të nënkuptonte zhvendosjen e llogaritjes në një server më të madh me një CPU më të shpejtë ose më shumë memorie. Në çdo rast, shkallëzimi vertikal kryhet për të krijuar një burim të veçantë të sistemit informatik të aftë për përpunim shtesë të të dhënave.

Shkallëzimi horizontal, nga ana tjetër, përfshin shtimin e më shumë nyjeve. Në rastin e një grupi të madh të dhënash, kjo do të nënkuptonte shtimin e një serveri të dytë për të ruajtur një pjesë të të gjithë vëllimit të të dhënave, dhe për një burim llogaritës, kjo do të nënkuptonte ndarjen e punës ose ngarkimin përmes disa nyjeve shtesë. Për të përfituar plotësisht nga potenciali për zvogëlim, ai duhet të zbatohet si një parim i dizajnit të brendshëm për arkitekturën e sistemit. Përndryshe, ndryshimi dhe nënvizimi i kontekstit të kërkuar për shkallëzimin horizontal mund të jetë problematik.

Metoda më e zakonshme për zvogëlimin është duke i ndarë shërbimet në copëza ose module. Ato mund të shpërndahen në atë mënyrë që çdo grup logjik funksionaliteti të funksionojë veçmas. Kjo mund të bëhet nga kufijtë gjeografikë, ose kritere të tjera si p.sh. përdoruesit që paguajnë dhe ata që nuk paguajnë. Avantazhi i këtyre skemave është se ato ofrojnë një shërbim ose dyqan të dhënash me funksionalitet të përmirësuar.

Në shembullin tonë të serverit të imazheve, është e mundur që serveri i vetëm i skedarëve që përdoret për të ruajtur imazhin të zëvendësohet me serverë të shumtë skedarësh, secili që përmban grupin e tij unik të imazheve. (Shih) Kjo arkitekturë do të lejojë që sistemi të mbushë çdo server skedari me imazhe, duke shtuar serverë shtesë ndërsa hapësira në disk mbushet. Dizajni do të kërkojë një skemë emërtimi që lidh emrin e skedarit të imazhit me serverin që përmban. Emri i imazhit mund të gjenerohet nga një skemë e qëndrueshme hashing e lidhur me serverët. Ose si alternativë, çdo imazh mund të ketë një ID në rritje, e cila do të lejonte shërbimin e dorëzimit të përpunojë vetëm gamën e ID-ve të lidhura me secilin server (si indeks) kur kërkon një imazh.

Figura 1.4: Aplikacioni i pritjes së imazheve të tepërta dhe të copëtuara

Sigurisht, ka vështirësi në shpërndarjen e të dhënave ose funksionalitetit nëpër serverë të shumtë. Një nga pyetjet kryesore - vendndodhjen e të dhënave; në sistemet e shpërndara, sa më afër të jenë të dhënat me vendndodhjen e operacioneve ose pikën e llogaritjes, aq më e mirë është performanca e sistemit. Rrjedhimisht, shpërndarja e të dhënave nëpër serverë të shumtë është potencialisht problematike, pasi sa herë që të dhënat nevojiten, ekziston rreziku që ato të mos jenë të disponueshme në vendin e kërkesës, serveri do të duhet të kryejë mostra të kushtueshme të informacionit të nevojshëm në rrjet. .

Një problem tjetër i mundshëm lind në formë
mospërputhje (mospërputhje).Kur shërbime të ndryshme lexojnë dhe shkruajnë në një burim të përbashkët, potencialisht një shërbim tjetër ose dyqan të dhënash, ekziston mundësia e kushteve të garës - ku disa të dhëna konsiderohen të përditësohen në gjendjen e tyre aktuale, por në realitet ato lexohen përpara përditësuar - në këtë rast të dhënat nuk janë konsistente. Për shembull, në një skenar të pritjes së imazhit, një gjendje gare mund të ndodhë nëse një klient dërgoi një kërkesë për të përditësuar imazhin e qenit, duke ndryshuar titullin "Dog" në "Gizmo", ndërsa një klient tjetër po lexonte imazhin. Në një situatë të tillë, nuk është e qartë se cili titull, “Qen” apo “Gizmo”, do të kishte marrë klienti i dytë.

Ka, sigurisht, disa pengesa që lidhen me ndarjen e të dhënave, por ndarjen ju lejon të dalloni secilin nga problemet nga të tjerët: sipas të dhënave, sipas ngarkesës, sipas modeleve të përdorimit, etj. në blloqe të kontrolluara. Kjo mund të ndihmojë me shkallëzueshmërinë dhe menaxhueshmërinë, por rreziku është ende atje. Ka shumë mënyra për të zbutur rrezikun dhe për të trajtuar ndërprerjen; megjithatë, në interes të shkurtësisë, ato nuk janë përfshirë në këtë kapitull. Nëse dëshironi më shumë informacion mbi këtë temë, duhet t'i hidhni një sy postimit të blogut të tolerancës dhe monitorimit të gabimeve.

1.3. Komponentët strukturorë të aksesit të shpejtë dhe të shkallëzuar të të dhënave

Pasi të kemi mbuluar disa nga parimet bazë në hartimin e sistemeve të shpërndara, le të kalojmë tani në një pikë më të vështirë - shkallëzimin e aksesit të të dhënave.

Shumica e aplikacioneve bazë të ueb-it, të tilla si aplikacionet e stivës LAMP, janë të ngjashme me imazhin në.

Figura 1.5: Aplikacione të thjeshta ueb

Ndërsa një aplikacion rritet, ka dy sfida kryesore: shkallëzimi i aksesit në serverin e aplikacionit dhe bazën e të dhënave. Në një dizajn aplikacioni shumë të shkallëzuar, një server në internet ose një server aplikacioni zakonisht minimizohet dhe shpesh zbaton një arkitekturë që nuk ndan burime. Kjo bën që shtresa e serverit të aplikacionit të sistemit të zvogëlohet. Si rezultat i këtij dizajni, puna e vështirë do të lëvizë poshtë raftes te serveri i bazës së të dhënave dhe shërbimet mbështetëse; Këtu hyjnë në lojë çështjet reale të shkallëzimit dhe performancës.

Pjesa tjetër e këtij kapitulli fokusohet në disa nga strategjitë dhe teknikat më të zakonshme për përmirësimin e performancës dhe shkallëzueshmërisë për këto lloje shërbimesh duke ofruar akses të shpejtë në të dhëna.

Figura 1.6: Aplikim Ueb i thjeshtuar

Shumica e sistemeve mund të thjeshtohen në një diagram në,
e cila është një pikënisje e mirë për të filluar të merret në konsideratë. Nëse keni shumë të dhëna, mund të supozoni se dëshironi që ato të jenë aq të lehta dhe të shpejta për t'u aksesuar sa kutia e ëmbëlsirave në sirtarin e sipërm të tavolinës suaj. Ndërsa ky krahasim është tepër i thjeshtuar, ai tregon për dy çështje komplekse: shkallëzueshmërinë e magazinës së të dhënave dhe aksesin e shpejtë të të dhënave.

Për këtë seksion, le të supozojmë se keni shumë terabajt (TB) të dhënash dhe ju lejoni përdoruesit të kenë akses në copa të vogla të atyre të dhënave pa ndonjë renditje të caktuar. (Cm. .)
Një detyrë e ngjashme është gjetja e skedarit të imazhit diku në serverin e skedarëve në aplikacionin e pritjes së imazhit të mostrës.

Figura 1.7: Aksesimi i të dhënave specifike

Kjo është veçanërisht e vështirë sepse ngarkimi i terabajtëve të të dhënave në memorie mund të jetë shumë i shtrenjtë dhe ndikon drejtpërdrejt në numrin e operacioneve të I/O të diskut. Shpejtësia e leximit nga një disk është disa herë më e ulët se shpejtësia e leximit nga RAM - mund të themi se qasja në memorie është aq e shpejtë sa Chuck Norris, ndërsa qasja në një disk është më e ngadaltë se radha në klinikë. Ky ndryshim në shpejtësi është veçanërisht i dukshëm për grupe të dhënash të mëdha; në numrat e thatë, aksesi i memories është 6 herë më i shpejtë se leximi i diskut për lexime të njëpasnjëshme dhe 100,000 herë më i shpejtë për lexime të rastësishme (shih Patologies of Big Data, http://queue.acm.org/detail. cfm? id = 1563874). ). Plus, edhe me identifikues unikë, zgjidhja e problemit të gjetjes së një pjese të vogël të të dhënave mund të jetë po aq e vështirë sa të nxirrni ëmbëlsirën e fundit të mbushur me çokollatë nga një kuti me qindra karamele të tjera pa parë.

Për fat të mirë, ka shumë qasje që mund të përdorni për të thjeshtuar gjërat, nga të cilat katër më të rëndësishmet janë cache, proxies, indekset dhe balancuesit e ngarkesës. Pjesa tjetër e këtij seksioni diskuton se si secili prej këtyre koncepteve mund të përdoret për ta bërë aksesin e të dhënave shumë më të shpejtë.

Memoriet e fshehta

Memoria e memories përfiton nga një parim thelbësor që të dhënat e kërkuara së fundi ka të ngjarë të kërkohen përsëri. Memoriet e fshehta përdoren pothuajse në çdo shtresë kompjuterike: harduer, sisteme operative, shfletues ueb, aplikacione ueb dhe më shumë. Një cache është si memoria afatshkurtër: e kufizuar në madhësi, por më e shpejtë se burimi origjinal i të dhënave dhe përmban artikuj të aksesuar së fundi. Memoriet e fshehta mund të ekzistojnë në të gjitha nivelet në arkitekturë, por shpesh janë në nivelin më të afërt me pjesën e përparme, ku ato zbatohen për të kthyer të dhënat shpejt pa ngarkesë të konsiderueshme në fund.

Pra, si mund të përdoret cache për të shpejtuar aksesin e të dhënave në API-në tonë të mostrës? Në këtë rast, ka disa lokacione të përshtatshme të cache. Si një nga opsionet e mundshme të vendosjes, ju mund të zgjidhni nyjet në nivelin e pyetjes, siç tregohet në
.

Figura 1.8: Vendosja e një cache në një nyje të nivelit të pyetjes

Vendosja e memories direkt në nyjen e nivelit të kërkesës lejon ruajtjen lokale të të dhënave të përgjigjes. Sa herë që bëhet një kërkesë shërbimi, hosti do të kthejë shpejt të dhënat lokale, të ruajtura në memorie, nëse ka. Nëse nuk është në cache, atëherë nyja e kërkesës do të kërkojë të dhëna nga disku. Cache në një nyje të vetme në nivelin e kërkesës gjithashtu mund të vendoset si në memorie (që është shumë e shpejtë) ashtu edhe në diskun lokal të nyjes (më shpejt sesa të përpiqesh të hysh në NAS).

Figura 1.9: Sistemet e cache

Çfarë ndodh kur përhapni caching në nyje të shumta? Siç mund ta shihni, nëse shtresa e pyetjes do të përfshijë shumë nyje, atëherë ka të ngjarë që çdo nyje të ketë cache-in e vet. Megjithatë, nëse balancuesi juaj i ngarkesës shpërndan rastësisht kërkesat midis nyjeve, atëherë e njëjta kërkesë do të shkojë në nyje të ndryshme, duke rritur kështu dështimet e cache-it. Memoria e fshehtë globale dhe e shpërndarë janë dy mënyra për të kapërcyer këtë pengesë.

Cache globale

Kuptimi i cache-it global është i qartë nga emri: të gjitha nyjet përdorin një hapësirë ​​të vetme cache. Në këtë rast, shtohet një server ose dyqan skedarësh i një lloji që është më i shpejtë se dyqani juaj origjinal dhe që do të jetë i disponueshëm për të gjitha nyjet e nivelit të pyetjes. Secila prej nyjeve të kërkesës kërkon cache në të njëjtën mënyrë sikur të ishte lokale. Kjo lloj skeme memorie mund të shkaktojë konfuzion, pasi është shumë e lehtë të mbingarkosh një memorie të vetme ndërsa numri i klientëve dhe kërkesave rritet. Në të njëjtën kohë, një skemë e tillë është shumë efektive për arkitektura të caktuara (veçanërisht kur bëhet fjalë për pajisje të specializuara që e bëjnë këtë memorie të fshehtë globale shumë të shpejtë, ose që kanë një grup fiks të dhënash që duhen ruajtur në memorie).

Ekzistojnë dy forma standarde të memories globale, të përshkruara në diagrame. Situata përshkruhet kur një përgjigje e memories nuk gjendet në cache, vetë cache bëhet përgjegjëse për marrjen e pjesës së munguar të të dhënave nga ruajtja themelore. Ai ilustron përgjegjësinë e nyjeve të kërkesës për të tërhequr çdo të dhënë që nuk gjendet në cache.

Figura 1.10: Cache Global, ku cache është përgjegjëse për marrjen

Figura 1.11: Cache globale ku nyjet e kërkesës janë përgjegjëse për marrjen

Shumica e aplikacioneve globale të forcimit të cache-it priren të përdorin llojin e parë, ku vetë cache menaxhon zëvendësimin dhe marrjen e të dhënave për të parandaluar klientët nga vërshimi i kërkesave për të njëjtat të dhëna. Megjithatë, ka disa raste kur zbatimi i dytë ka më shumë kuptim. Për shembull, nëse cache-ja përdoret për skedarë shumë të mëdhenj, një shkallë e ulët e goditjes së cache-it do të mbingarkojë cache-në e tamponit me dështime të cache-it; në këtë situatë ndihmon që të kemi një përqindje të madhe të të dhënave totale (ose të dhënash të nxehtë) në cache. Një shembull tjetër është një arkitekturë ku skedarët e ruajtur në cache janë statike dhe nuk duhet të fshihen. (Kjo mund të jetë për shkak të karakteristikave themelore të performancës së kësaj vonese - ndoshta pjesë të caktuara të të dhënave duhet të jenë shumë të shpejta për grupe të dhënash të mëdha - kur logjika e aplikacionit e kupton strategjinë e zëvendësimit ose pikat e nxehta më mirë se cache.)

Cache e shpërndarë

Këto indekse shpesh ruhen në memorie ose diku shumë lokale për kërkesën e klientit në hyrje. Berkeley DB (BDB) dhe strukturat e të dhënave të pemës, të cilat zakonisht përdoren për të ruajtur të dhënat në lista të renditura, janë ideale për akses të indeksuar.

Shpesh ka shumë nivele indeksesh që shërbejnë si një hartë, duke ju lëvizur nga një vend në tjetrin, e kështu me radhë, derisa të merrni pjesën e të dhënave që dëshironi. (Cm.)

Figura 1.17: Indekset me shumë nivele

Indekset mund të përdoren gjithashtu për të krijuar disa pamje të tjera të të njëjtave të dhëna. Për grupe të dhënash të mëdha, kjo është një mënyrë e shkëlqyer për të përcaktuar filtra dhe pamje të ndryshme pa pasur nevojë të krijoni shumë kopje shtesë të të dhënave.

Për shembull, supozoni se sistemi i mbajtjes së imazheve të përmendur më lart pret në të vërtetë imazhet e faqeve të librave dhe shërbimi mundëson pyetjet e klientëve mbi tekstin në ato imazhe, duke kërkuar të gjithë përmbajtjen e tekstit në një temë të caktuar, ashtu si motorët e kërkimit ju lejojnë të kërkoni për HTML Përmbajtja. Në këtë rast, të gjitha këto imazhe librash përdorin shumë serverë për të ruajtur skedarët, dhe gjetja e një faqeje për t'ia paraqitur përdoruesit mund të jetë mjaft e vështirë. Fillimisht, indekset e anasjellta për kërkimin e fjalëve arbitrare dhe grupeve të fjalëve duhet të jenë lehtësisht të disponueshme; pastaj ekziston sfida e lundrimit në faqen dhe vendndodhjen e saktë në atë libër dhe nxjerrjen e imazhit të saktë për rezultatet e kërkimit. Kështu, në këtë rast, indeksi i përmbysur do të hartohej në një vendndodhje (siç është libri B), dhe më pas B mund të përmbajë një indeks me të gjitha fjalët, vendndodhjet dhe numrin e dukurive në secilën pjesë.

Indeksi i përmbysur që Index1 mund të shfaqë në diagramin e mësipërm do të duket diçka si kjo: Çdo fjalë ose grup fjalësh shërben si një indeks për librat që i përmbajnë ato.

Indeksi i ndërmjetëm do të duket i ngjashëm, por do të përmbajë vetëm fjalët, vendndodhjen dhe informacionin për Librin B. Kjo arkitekturë me shumë shtresa i lejon secilit prej indekseve të zërë më pak hapësirë ​​sesa nëse i gjithë ky informacion do të ruhej në një indeks të madh të përmbysur .

Dhe kjo është një pikë kyçe në sistemet në shkallë të gjerë, sepse edhe kur janë të ngjeshur, këto indekse mund të jenë mjaft të mëdha dhe të shtrenjta për t'u ruajtur. Supozoni se kemi shumë libra nga e gjithë bota në këtë sistem - 100 000 000 (shih postimin në blog "Brenda librave të Google") - dhe se çdo libër është vetëm 10 faqe (për të thjeshtuar llogaritjet) me 250 fjalë për faqe : Kjo na jep një gjithsej 250 miliardë fjalë. Nëse marrim numrin mesatar të karaktereve në një fjalë si 5, dhe kodojmë çdo karakter në 8 bit (ose 1 bajt, edhe pse disa karaktere marrin 2 bajt), duke shpenzuar kështu 5 bajt për fjalë, atëherë indeksi që përmban vetëm çdo fjalë një herë do të kërkojë më shumë se 1 terabajt ruajtje. Kështu që ju mund të shihni se indekset që përmbajnë informacione të tjera, si grupet e fjalëve, vendndodhjet e të dhënave dhe numri i përdorimit, mund të rriten në vëllim shumë shpejt.

Krijimi i këtyre indekseve të ndërmjetme dhe prezantimi i të dhënave në copa më të vogla e bën më të lehtë zgjidhjen e problemit të të dhënave të mëdha. Të dhënat mund të shpërndahen nëpër serverë të shumtë dhe në të njëjtën kohë të jenë të disponueshme shpejt. Indekset janë gurthemeli i gjetjes së informacionit dhe themeli për motorët modernë të kërkimit. Sigurisht, ky seksion është vetëm i përgjithshëm për temën e indeksimit dhe janë bërë shumë kërkime se si t'i bëni indekset më të vogla, më të shpejta, të përmbajnë më shumë informacion (si p.sh. rëndësia) dhe të përditësohen pa probleme. (Ka disa probleme me menaxhueshmërinë e kushteve konkurruese dhe numrin e përditësimeve të kërkuara për të shtuar të dhëna të reja ose për të ndryshuar të dhënat ekzistuese, veçanërisht kur përfshihet rëndësia ose vlerësimi.)

Të jesh në gjendje të gjesh të dhënat e tua shpejt dhe me lehtësi është thelbësore, dhe indekset janë mjeti më i thjeshtë dhe më efektiv për ta arritur këtë.

Balancuesit e ngarkesës

Së fundi, një pjesë tjetër kritike e çdo sistemi të shpërndarë është balancuesi i ngarkesës. Balancuesit e ngarkesës janë një pjesë thelbësore e çdo arkitekture sepse roli i tyre është të shpërndajnë ngarkesën midis nyjeve përgjegjëse për shërbimin e kërkesave. Kjo lejon që nyjet e shumta të shërbejnë në mënyrë transparente të njëjtin funksion në sistem. (Shih) Qëllimi i tyre kryesor është të trajtojnë shumë lidhje të njëkohshme dhe t'i drejtojnë ato lidhje në një nga nyjet e kërkuara, duke lejuar sistemin të zvogëlohet duke shtuar thjesht nyje për të shërbyer më shumë kërkesa.

Figura 1.18: Balancuesi i ngarkesës

Ka shumë algoritme të ndryshme për shërbimin e kërkesave, duke përfshirë zgjedhjen e rastësishme të nyjeve, zgjedhjen e rrumbullakët, apo edhe zgjedhjen e nyjeve bazuar në kritere të caktuara si përdorimi i CPU ose RAM. Balancuesit e ngarkesës mund të zbatohen si pajisje harduerike ose softuer. HAProxy është balancuesi më i gjerë i ngarkesës me burim të hapur.

Në një sistem të shpërndarë, balancuesit e ngarkesës janë shpesh në pjesën e përparme të sistemit në mënyrë që të gjitha kërkesat hyrëse të kalojnë drejtpërdrejt përmes tyre. Ka shumë të ngjarë që në një sistem kompleks të shpërndarë, kërkesa do të duhet të kalojë nëpër disa balancues të ngarkesës, siç tregohet në
.

Figura 1.19: Balancues të shumëfishtë të ngarkesës

Ashtu si përfaqësuesit, disa balancues të ngarkesës gjithashtu mund t'i drejtojnë kërkesat ndryshe, në varësi të llojit të kërkesës. Ata njihen gjithashtu si përfaqësues të kundërt.

Menaxhimi i të dhënave specifike për një sesion specifik përdoruesi është një nga sfidat kur përdoren balancuesit e ngarkesës. Në një faqe të tregtisë elektronike, kur keni vetëm një klient, është shumë e lehtë për përdoruesit që të vendosin gjërat në shportën e tyre dhe të ruajnë përmbajtjen e saj ndërmjet vizitave (kjo është e rëndësishme, pasi gjasat që një produkt të shitet rritet ndjeshëm nëse, pas përdoruesi kthehet në faqe, produkti është ende në shportën e tij). Megjithatë, nëse një përdorues drejtohet në një sajt për sesionin e parë dhe më pas në një sajt tjetër në vizitën e tij të radhës, atëherë mund të lindin mospërputhje sepse faqja e re mund të mos ketë të dhëna në lidhje me përmbajtjen e karrocës së blerjeve të atij përdoruesi. (A nuk do të mërziteshit nëse vendosni një paketë me vesë malore në shportën tuaj dhe kur të ktheheni nuk do të jetë aty?) Një zgjidhje mund të jetë t'i bëni seancat "ngjitëse" në mënyrë që përdoruesi të drejtohet gjithmonë te e njëjta nyje. Megjithatë, përfitimi i disa prej veçorive të besueshmërisë, si dështimi automatik, do të jetë shumë i vështirë. Në këtë rast, karroca e përdoruesit do të ketë gjithmonë përmbajtje, por nëse nyja e tyre ngjitëse bëhet e padisponueshme, atëherë do të nevojitet një qasje e veçantë dhe supozimi për përmbajtjen e karrocës nuk do të jetë më i vërtetë (edhe pse, shpresojmë, ky supozim nuk do të jetë i integruar në aplikacion). Natyrisht, ky problem mund të zgjidhet me strategji dhe mjete të tjera siç përshkruhen në këtë kapitull, si shërbimet dhe shumë të tjera (si memoriet e shfletuesit, kukit dhe rishkrimi i URL-së).

Nëse sistemi ka vetëm disa nyje, atëherë teknikat si një karusel DNS kanë më shumë gjasa të jenë më praktike sesa balancuesit e ngarkesës, të cilat mund të jenë të shtrenjta dhe të shtojnë një shtresë të panevojshme në kompleksitetin e sistemit. Sigurisht, sistemet e mëdha kanë të gjitha llojet e algoritmeve të ndryshme të planifikimit dhe balancimit të ngarkesës, duke përfshirë ato të thjeshta si përzgjedhja e rastësishme ose algoritmet e karuselit, si dhe mekanizma më komplekse që marrin parasysh veçoritë e performancës së modeleve të përdorimit të sistemit. Të gjithë këta algoritme shpërndajnë trafikun dhe kërkesat, dhe mund të ofrojnë mjete të dobishme besueshmërie, si p.sh. dështimi automatik ose heqja automatike e një nyje të dëmtuar (për shembull, kur ajo bëhet e papërgjegjshme). Megjithatë, këto veçori të avancuara mund ta bëjnë të rëndë diagnostikimin e problemeve. Për shembull, në situata të ngarkesës së lartë, balancuesit e ngarkesës do të heqin nyjet që mund të jenë të ngadalta ose të skadojnë (për shkak të një morie kërkesash), gjë që vetëm sa do ta përkeqësojë situatën për nyjet e tjera. Në këto raste, kontrolli i gjerë është i rëndësishëm sepse edhe nëse trafiku dhe ngarkesa e përgjithshme e sistemit duket se zvogëlohet (pasi nyjet po shërbejnë më pak kërkesa), nyjet individuale mund të mbingarkohen.

Balancuesit e ngarkesës janë një mënyrë e thjeshtë për të shtuar kapacitet në sistemin tuaj. Ashtu si teknikat e tjera të përshkruara në këtë artikull, ajo luan një rol thelbësor në arkitekturën e një sistemi të shpërndarë. Balancuesit e ngarkesës ofrojnë gjithashtu një funksion kritik për verifikimin e shëndetit të nyjeve. Nëse, si rezultat i një kontrolli të tillë, një nyje nuk përgjigjet ose është e mbingarkuar, atëherë ajo mund të hiqet nga grupi i përpunimit të kërkesave dhe, për shkak të tepricës së sistemit tuaj, ngarkesa do të rishpërndahet midis nyjeve të mbetura të punës. .

Radhët

Deri më tani, ne kemi parë shumë mënyra për të lexuar shpejt të dhënat. Në të njëjtën kohë, menaxhimi efikas i të dhënave është një tjetër pjesë e rëndësishme e shkallëzimit të nivelit të të dhënave. Kur sistemet janë të thjeshta me ngarkesa minimale të përpunimit dhe baza të të dhënave të vogla, shkrimet mund të jenë shumë të shpejta. Megjithatë, në sistemet më komplekse, ky proces mund të zgjasë një kohë të pacaktuar. Kështu, për shembull, të dhënat mund të kenë nevojë të shkruhen në shumë vendndodhje në serverë ose indekse të ndryshëm, ose sistemi mund të jetë thjesht nën ngarkesë të madhe. Në rastet kur shkrimi apo edhe çdo detyrë kërkon shumë kohë, arritja e performancës dhe disponueshmërisë kërkon ndërtimin e asinkronisë në sistem. Një mënyrë e zakonshme për ta bërë këtë është të vendosni kërkesat në radhë.

Figura 1.20: Kërkesë sinkrone

Imagjinoni një sistem ku çdo klient kërkon një detyrë shërbimi në distancë. Secili prej këtyre klientëve dërgon kërkesën e tij në server, i cili përfundon detyrat sa më shpejt që të jetë e mundur dhe ia kthen rezultatet e tyre klientëve të duhur. Në sistemet e vogla, ku një server i vetëm (ose shërbim logjik) mund t'u shërbejë klientëve në hyrje aq shpejt sa ata arrijnë, kjo lloj situate duhet të funksionojë mirë. Megjithatë, kur serveri merr më shumë kërkesa sesa mund të trajtojë, atëherë çdo klient detyrohet të presë që klientët e tjerë të përfundojnë përpunimin përpara se të gjenerohet një përgjigje ndaj kërkesës së tij. Ky është një shembull i një kërkese sinkrone të përshkruar në.

Kjo lloj sjelljeje sinkrone mund të degradojë ndjeshëm performancën e klientit; në fakt, i papunë, klienti detyrohet të presë derisa të marrë përgjigjen e kërkesës. Shtimi i serverëve shtesë për të përballuar ngarkesën e sistemit, në fakt, nuk e zgjidh problemin; edhe me balancimin efektiv të ngarkesës në vend, është jashtëzakonisht e vështirë të sigurohet shpërndarje e barabartë dhe e barabartë e ngarkesës që kërkohet për të maksimizuar produktivitetin e klientit. Për më tepër, nëse serveri nuk është i disponueshëm për të përpunuar këtë kërkesë (ose ka dështuar), atëherë klienti i lidhur me të gjithashtu do të ndalojë së punuari. Një zgjidhje efektive për këtë problem kërkon një abstragim midis kërkesës së klientit dhe punës aktuale që po bëhet për ta shërbyer atë.

Figura 1.21: Përdorimi i radhëve për të menaxhuar kërkesat

Radhët e hyrjes. Mekanizmi i radhës është shumë i thjeshtë: një detyrë hyn, futet në radhë dhe më pas “punëtorët” pranojnë detyrën tjetër sapo të kenë mundësi ta përpunojnë. (Shih) Këto detyra mund të jenë aq të thjeshta sa shkrimi në një bazë të dhënash, ose aq komplekse sa krijimi i një imazhi paraprak për një dokument. Kur një klient paraqet kërkesa për detyrat në radhë, ai nuk ka më nevojë të presë për rezultatet e ekzekutimit; në vend të kësaj, kërkesat vetëm duhet të pranohen siç duhet. Ky konfirmim mund të shërbejë më vonë si referencë për rezultatet e punës kur klienti i kërkon ato.

Radhët i lejojnë klientët të punojnë në një mënyrë asinkrone duke ofruar një abstraksion strategjik për kërkesën dhe përgjigjen e një klienti. Nga ana tjetër, në një sistem sinkron, nuk ka dallim ndërmjet kërkesës dhe përgjigjes dhe për këtë arsye nuk mund të kontrollohet veçmas. Në një sistem asinkron, klienti vendos një detyrë, shërbimi përgjigjet me një mesazh që konfirmon që detyra është marrë dhe më pas klienti mund të kontrollojë periodikisht statusin e detyrës, duke kërkuar vetëm rezultatin sapo të ketë përfunduar. Ndërsa klienti bën një kërkesë asinkrone, ai është i lirë të bëjë punë të tjera, madje edhe të bëjë kërkesa asinkrone për shërbime të tjera. Ky i fundit është një shembull se si funksionojnë radhët dhe mesazhet në sistemet e shpërndara.

Radhët ofrojnë gjithashtu një mbrojtje kundër ndërprerjeve dhe refuzimeve të shërbimit. Për shembull, është mjaft e lehtë të krijosh një radhë shumë të vazhdueshme që mund të përsërisë kërkesat e shërbimit që kanë ndaluar së funksionuari për shkak të ndërprerjeve kalimtare të serverit. Është më e preferueshme të përdoret një radhë për të zbatuar garancitë QoS sesa të ekspozohen klientët ndaj ndërprerjeve të përkohshme të shërbimit, që kërkojnë trajtim kompleks dhe shpesh jokonsistent të gabimeve nga ana e klientit.

1.4. konkluzioni

Projektimi i sistemeve efikase me akses të shpejtë në sasi të mëdha të të dhënave është një temë shumë interesante dhe ka ende një numër të konsiderueshëm mjetesh të mira që lejojnë përshtatjen e të gjitha llojeve të aplikacioneve të reja. Ky kapitull ka prekur vetëm disa shembuj, por në realitet ka shumë të tjerë - dhe krijimi i risive të reja në këtë fushë vetëm do të vazhdojë.

Kjo vepër shpërndahet nën licencën e pandryshuar Creative Commons Attribution 3.0. Shikoni detajet në

Në këtë artikull, ne do të përshkruajmë disa koncepte që duhet të përdorni kur zgjidhni një ventilator dhe do t'ju tregojmë për veçoritë tipike për lloje të ndryshme tifozësh. Për më tepër, ne do të testojmë tifozin 120 mm akasa Amber AK-183-L2B, i cili shërben si një element aktiv i sistemit të ftohjes së procesorit Thermaltake Sonic Tower për më shumë se një vit tani, i cili përdoret në testimin e procesorëve dhe kartave video. . Dhe duhet të theksohet se ai meritonte plotësisht të drejtën për t'u bërë heroi i parë në një seri rishikimesh kushtuar fansave në burimin tonë.

Pyetjet që do të përpiqemi t'u përgjigjemi do të jenë...

Cilat janë kërkesat për një ventilator kuti?

1. Niveli i performancës.
2. Niveli i zhurmes.
3. Pamja (prania dhe lloji i ndriçimit).
4. Karakteristika shtesë (mbështetje për furnizimin me energji PWM, prania e një kontrolluesi të shpejtësisë, i kompletuar me montim kundër dridhjeve).

Cilat janë ndryshimet kryesore midis tifozëve të rastit?

1.Dimensionet- madhësia e shtytësit.

Për të krijuar ventilim të brendshëm në rast, në shumicën e rasteve, përdoren tifozë me madhësi standarde të barabartë me 80 mm, 92 mm ose 120 mm, pasi fillimisht sigurohen vrimat e montimit për instalimin e tyre në kuti. Është mjaft e qartë se sa më e madhe të jetë madhësia e shtytësit të ventilatorit, aq më e lartë është aftësia e tij për të pompuar rrjedhën e ajrit. Prandaj, një tifoz më i vogël do të duhet të rrotullohet me një shpejtësi më të lartë për të arritur vlerat e efikasitetit të modeleve më të mëdha, dhe për këtë arsye të gjenerojë dukshëm më shumë zhurmë. Për këtë arsye, janë tifozët e mëdhenj 120 mm ata që janë të njohur.

Për të ilustruar këto veti, mund të krahasoni karakteristikat e modeleve të ventilatorit të së njëjtës seri të Xinruilian Science & Technology Co. me madhësi të ndryshme:

Madhësia, mm
Shpejtësia rpm
Fluksi i ajrit CFM
Niveli i zhurmës, dB
Presioni, mm H 2 0

Duke gjykuar nga karakteristikat e dhëna të modeleve, mund të konkludojmë se me të njëjtën shpejtësi rrotullimi prej 92 mm, ventilatori do të jetë 1.65 herë më efikas se ai 80 mm, dhe ventilatori 120 mm do të jetë dy herë më efikas se modeli 92 mm. duke marrë parasysh që të gjithë tifozët kanë një lloj shtytëse.

Përveç diametrave të ndryshëm të shtytësit, madhësia e profilit ose thellësia e ventilatorit është po aq e rëndësishme. Profili 25 mm është "klasik" për rrethimet konvencionale. Tifozët me një profil më të vogël quhen profil të ulët, dhe me një profil më të madh quhen profil të lartë. Forca e rrjedhës së ajrit varet drejtpërdrejt nga madhësia e profilit, e cila karakterizohet në specifikim nga vlera maksimale e presionit.

Për shembull, le të krahasojmë karakteristikat e dy modeleve 120 mm - me një profil të rregullt dhe një profil të lartë, që funksionojnë me të njëjtën shpejtësi rrotullimi.

Madhësia, mm
Shpejtësia rpm
Fluksi i ajrit CFM
Niveli i zhurmës, dB
Presioni, mm H20

Nga tabela mund të shihet se tifozi i profilit të lartë ndryshon vetëm në treguesin më të mirë të presionit maksimal të rrjedhës së ajrit. Sistemet kompjuterike konvencionale nuk kanë nevojë të jenë nën presion, kështu që këta tifozë nuk përdoren në to. Në shumicën e rasteve, tifozët e profilit të lartë përdoren në serverë; përveç kësaj, ata kanë një shpejtësi rrotulluese të rritur dhe, si rezultat, një zhurmë mjaft të lartë funksionimi.

2. Lloji i kushinetave.

Ekzistojnë tre lloje kryesore të kushinetave të përdorura në ventilatorë: të thjeshtë, të kombinuar me rrëshqitje dhe rrotullime, dhe dy kushineta rrotulluese. Përveç këtyre llojeve të kushinetave, ekzistojnë lloje hidrodinamike dukshëm më pak të shpeshta, të cilat janë zhvilluar posaçërisht nga disa prodhues.

Më shpesh, lloji i kushinetës mund të përcaktohet nga prania e treguesve të mëposhtëm në emër të modelit të ventilatorit, megjithëse gjithmonë këshillohet të kontrolloni me specifikimin zyrtar:

S (mëngë) - një kushinetë mëngë, e cila në thelb është një mëngë;
ME (kombinim) - një kushinetë topash dhe tufë të shkurtër;
B (top) ose 2B (2 top)- dy kushineta topash.

Më e thjeshta dhe më e lira, por, për fat të keq, jo veçanërisht e qëndrueshme, është kushinetja e mëngës. Ky kushinetë ka formën e një tufa të vogël bakri, brenda së cilës boshti i shtytësit (shkopi) rrëshqet gjatë rrotullimit. Një tifoz i ri me një kushinetë të mëngës të lubrifikuar mund të jetë plotësisht i heshtur, por kjo pronë mund të humbet me kalimin e kohës. Në mungesë të nivelit të duhur të lubrifikimit, tufa "shteron" mjaft shpejt, gjë që bën që tifozi të bëjë zhurmë. Përveç kësaj, në mungesë të lubrifikimit, duke punuar në një zonë me temperaturë të lartë, tifozi mund të bllokohet plotësisht. Ky fakt tregohet veçanërisht qartë nga rastet me furnizime me energji të lira kineze, në të cilat shpesh ka pasur raste të ndalimit të një tifozi në një kushinetë të mëngës, i cili siguron ftohje të elementëve gjysmëpërçues të energjisë. Si rezultat, furnizimi me energji elektrike dështoi.

Versioni i kombinuar i kushinetës ka një jetë relativisht më të gjatë mbajtëse.

Një kushinetë me dy kushineta topash është opsioni më i shtrenjtë, por në të njëjtën kohë, më i qëndrueshëm. Ky lloj kushinetë mund të funksionojë lirshëm në një zonë me temperaturë të lartë. Por në të njëjtën kohë, midis tifozëve të tillë shpesh mund të gjeni ekzemplarë që lëshojnë një zhurmë mjaft të lartë dhe të pakëndshme. Një pamje e ngjashme është veçanërisht karakteristike për tifozët e lirë, sepse karakteristikat e zhurmës së të gjithë strukturës varen drejtpërdrejt nga cilësia e prodhimit të një kushinete miniaturë. Prandaj, nëse zgjidhni një produkt me kushineta topash, në asnjë rast mos e ndiqni lirësinë e tij, sepse modelet edhe më të shtrenjta rrallëherë janë të qetë.

3. Klasa e motorit.

Të gjithë tifozët e kutisë mundësohen nga motorë DC me 4 pole. Për sa i përket shpejtësisë, të gjitha ato klasifikohen në tre kategori: shpejtësi të ulët deri në 2000 rpm, shpejtësi mesatare nga 2000 deri në 3000 rpm dhe shpejtësi të lartë mbi 3000 rpm. Shpesh mund të zbuloni klasën e motorit të ventilatorit me indeksin në emrin e tij, i cili shpesh tregohet në afishe:

L (të ulëta) - lëvizje e ngadaltë ( deri në vitin 2000 rpm);
M (e mesme) - mesatare ( nga 2000 në 3000 rpm);
H (lartë) - shpejtësi e lartë ( mbi 3000 rpm).

Cilat janë karakteristikat e të dhënave të dhëna në specifikimet e prodhuesit?

Shpejtësia e ventilatorit matet në numrin e rrotullimeve në minutë (RPM - rrotullime për minutë). Meqenëse shpejtësia e ventilatorit në vetvete mund të ndryshojë pothuajse në proporcion të drejtpërdrejtë me tensionin e furnizimit, vlera e dhënë në specifikim korrespondon me tensionin nominal të furnizimit. Sa më e lartë të jetë shpejtësia e rrotullimit, aq më efikas është ventilatori, por zakonisht edhe më i zhurmshëm.

Rrjedha e ajrit mund të specifikohet në CFM (këmbë kub për minutë, CFM) - këmbë kub për minutë ose në metra kub në orë (m 3 / orë). Në këtë rast, 1 CFM ≈ 1,7 m 3 / orë. Kjo vlerë pasqyron sasinë e ajrit të "pompuar" për një periudhë të caktuar kohore, me kusht që të mos ketë rezistencë ndaj rrjedhës së ajrit, domethënë me presion të barabartë të ajrit në të dy anët e ventilatorit. Natyrisht, sa më e madhe kjo vlerë, aq më mirë.

Presioni statik i rrjedhës së ajrit Ventilatori zakonisht jepet në mm kolonë uji dhe karakterizon forcën e rrjedhës së ajrit që mund të gjenerojë ventilatori.

Kujtojmë që presioni llogaritet me formulën P = F / S. Kjo do të thotë, presioni është raporti i forcës së rrjedhës së ajrit me zonën në të cilën ai vepron. Specifikimi tregon vlerën maksimale të rrjedhës së ajrit që krijon ventilatori kur nuk mund të krijojë fluks ajri për shkak të rezistencës.

E gjithë karakteristika e ventilatorit mund të shihet në grafikun "Korba e Performancës".

Kurba e performancës përfaqëson marrëdhënien midis rrjedhës së ajrit dhe presionit. Pika më e lartë e kurbës, e vendosur në bosht, nuk është asgjë më shumë se presioni maksimal që është dhënë në specifikim. Pika e poshtme e kurbës, e shtrirë në boshtin tjetër, korrespondon me rrjedhën maksimale të ajrit të ventilatorit kur nuk duhet të krijojë presion. Në kushte reale, përkatësisht në rast, rrjedha e ajrit duhet të kapërcejë njëfarë rezistence. Çdo trup ka shkallën e vet të rezistencës individualisht. Rezistenca e sistemit do të shprehet si e pjerrët në grafik, dhe pika e kryqëzimit të vijës së drejtë dhe kurbës nuk është gjë tjetër veçse pika e funksionimit të ventilatorit në sistemin tonë të kushtëzuar.

Burimi i tifozëve matet me numrin e mijë orëve gjatë të cilave ventilatori duhet të punojë dhe të sigurojë karakteristikat e deklaruara. Autori i artikullit nuk është plotësisht i vetëdijshëm për kushtet e funksionimit në të cilat arrihen vlerat e cituara, pasi jeta e shërbimit varet drejtpërdrejt nga kushtet e funksionimit. Supozohet se tifozi është i aftë të funksionojë për numrin e caktuar të orëve pa humbur cilësitë e tij të zhurmës. Burimi varet kryesisht nga lloji dhe cilësia e kushinetës. Për kushinetat e thjeshta, zakonisht raportohen 30,000 orë, për kushinetat e kombinuara, 45,000 orë, dhe për kushinetat e dyfishta, vlerat raportohen për 60,000 orë ose më shumë.

Në shumicën e rasteve, një tifoz në një kushinetë mëngë mund të funksionojë mjaft i qetë për rreth një vit, megjithëse prodhuesit deklarojnë një shifër prej 30 mijë. Prandaj, nuk duhet të jeni të njëanshëm për këto shifra - ato janë mjaft relative. Dhe nëse gërmoni përreth, rezulton se prodhuesi nënkuptonte edhe mirëmbajtjen periodike të tifozëve, d.m.th. një lubrifikant që përdoruesit e zakonshëm e prodhojnë rrallë.

Tani le të kthehemi te heroi i rishikimit tonë të fansave. akasa AK-183-L2B dhe shikoni specifikimet e tij:

	akasaAK-183-L2B
Madhësia, mm
Shpejtësia e rrotullimit, rpm
Fluksi i ajrit CFM
Presioni, mm H20
Burimi, h
Lloji i kushinetave	dy rrotulluese
	3-pin
Niveli i zhurmës, dB
Tensioni i furnizimit, V
Faqja e internetit e produkteve
çmim mesatar

Ventilatori akasa AK-183-L2B është i paketuar në një qese plastike transparente. Pjesa e pasme e paketimit përmban një fletë kartoni blu që thekson kutinë transparente dhe shtytësin e tejdukshëm ngjyrë të verdhë qelibar të ventilatorit. Në përgjithësi, gjithçka është zbukuruar në ngjyrën e zakonshme të korporatës blu-verdhë të Grupit Akasa.

Në pjesën e pasme të kartonit ka një fletë specifikimi në pesë gjuhë të ndryshme.

Përveç ventilatorit, në fund të paketës ka një kuti të vogël kartoni të zezë me një mbishkrim të përkthyer si "Përshtatës 3-4-pin".

Prandaj, nuk është aspak për t'u habitur që kutia përmbante të njëjtin përshtatës që ju lejon të lidhni tifozin nga lidhësit e pajisjeve periferike, dhe përveç kësaj, të keni gjithashtu një lidhës 3-pin për të kontrolluar shpejtësinë e rrotullimit të ventilatorit. Gjithashtu në kutinë e vogël të zezë kishte katër vida për instalimin e ventilatorit në kasë.

Kutia e ventilatorit akasa AK-183-L2B është bërë nga plastika e bardhë transparente, dhe shtytësi i saj është prej plastike të tejdukshme të verdhë qelibar. Në fakt, nëse marrim parasysh të gjithë gamën e produkteve të kompanisë akasa, atëherë disa zgjidhje të thjeshta dhe standarde rrallë hasen në të, sepse kompania është e angazhuar në shpërndarjen e mallrave në pjesën më të madhe të krijuar posaçërisht për modifikim. Por kjo nuk do të thotë aspak se nëse nuk i përkisni kastës së modderëve dhe jeni mësuar ta vlerësoni produktin vetëm për arsye praktike, atëherë ky tifoz dhe pjesa tjetër e produktit të ngjashëm nuk do t'ju përshtaten. Në fakt, në prodhimin e produkteve për të ashtuquajturit përdoruesit e vështirë, modderët ose mbimbyllësit, kjo nënkupton gjithmonë vëmendje të shtuar, para së gjithash, për cilësinë e punimit dhe vetitë e saj disi më të larta. Prandaj, nuk është aspak për t'u habitur që cilësitë konsumatore të produkteve të tilla janë pothuajse gjithmonë më të larta se ato të produkteve të thjeshta.

Nga pamja e jashtme, tifozi padyshim dallohet kryesisht për kombinimin e tij të bukur të verdhë dhe të bardhë, dhe duket se një tifoz i tillë thjesht duhet të ketë një dritë prapa, por në fakt nuk është kështu. Nga pikëpamja aerodinamike, asnjë risi ose njohuri nuk është zbatuar në ventilator - një shtytës i thjeshtë me shtatë tehe.

Ventilatori akasa AK-183-L2B i përket modeleve me shpejtësi të ulët, shpejtësia e vlerësuar e rrotullimit të tij është 1400 rpm, ndërsa fluksi maksimal i ajrit mund të arrijë 44,8 CFM, dhe presioni statik është 1,1 mm kolonë uji. Specifikat nuk janë as super të larta dhe as krejt të zakonshme, por kjo nuk është për t'u habitur, pasi për tifozët e një sistemi shtëpiak, kërkesat më të larta për zhurmë vihen në radhë të parë.

Dhe në këtë drejtim, specifikimi tregon një nivel mjaft të ulët zhurme prej 18 dB. Duhet të theksohet se tifozi akasa AK-183-L2B bazohet në dy kushineta topi, dhe burimi i tij sipas të dhënave të prodhuesit është 80,000 orë. Vlera e zakonshme për kushinetat e topit është 60,000 orë, kështu që një vlerë paksa e rritur jep arsye për të shpresuar për një qasje më të mirë për prodhimin e tyre, sepse siç e kemi vërejtur tashmë, është cilësia e prodhimit të një kushinete topi që përcakton karakteristikat e tij të zhurmës. .

Ventilatori mundësohet nga një lidhës rryme me 3 pin që nuk mbështet furnizimin me energji PWM.

Duke testuar

Pjesa praktike e testit përbëhet nga dy faza të testimit të rrjedhës së ajrit të krijuar të ventilatorit me shpejtësinë nominale, si dhe vlerësimit të zërit të tij me vesh.

Testi numër 1

Në provën e parë, ventilatori do të veprojë si një element aktiv i ftohësit Thermalright SI-128. Testimi kryhet në një rast të hapur, dhe parametri kryesor i kontrolluar është temperatura e ngrohjes së procesorit Intel Core 2 Duo E6300 të mbingarkuar në 2.8 GHz dhe temperatura e motherboard.

Testi numër 2

Në provën e dytë, ventilatori do të përdoret për qëllimin e tij të synuar si një ventilator kuti i instaluar në panelin e pasmë dhe që punon për fryrje. Gjatë testimit, rasti do të mbyllet dhe nuk do të ketë asnjë tifoz tjetër të ndezur në të. Parametri kryesor i kontrolluar do të jetë gjithashtu temperatura e ngrohjes së procesorit Intel Core 2 Duo E6300, por tani pa mbingarkesë, mbi të cilën është instaluar sistemi pasiv i ftohjes Thermaltake Sonic Tower (CL-P0071) dhe temperatura e motherboard. Rezultati i testit regjistrohet pas një "vrapimi" 10 minutash të testit të stresit të procesorit në aplikacionin Everest.

Konfigurimi i testimit të platformës së procesorit Intel përbëhet nga komponentët e mëposhtëm:

Motherboard	Gigabyte GA-965P-DS4 (Intel P965 Express)
CPU	Intel Core 2 Duo E6300 (LGA775, 1.86 GHz, L2 2MB) @ 2.8 GHz
RAM	2 х DDR2-800 1024 MB Apacer PC6400
Kartë video	EVGA GeForce 8600GTS 256 MB DDR3 PCI-E
HDD	Samsung HD080HJ 80 GB SATA-300
Disk optik	ASUS DRW-1814BLT SATA
Furnizimi me energji elektrike	Ventilator Chieftec CFT-500-A12S 500W 120 mm
	CODEGEN M603 MidiTower

Tifozja akasa AK-183-L2B demonstron performancë të mirë në të njëjtin nivel me konkurrentët e tjerë. Nivelin mjaft të ulët të deklaruar të zhurmës prej 18 dB mund ta konfirmojmë vetëm me mendimin tonë subjektiv. Vlera e treguar është me të vërtetë mjaft në përputhje me nivelin real të zhurmës - me shpejtësi maksimale lëshon një zhurmë të vogël.

konkluzione.

Tifozja akasa AK-183-L2B nuk është një dekorim i bukur ekskluzivisht i modifikuar, siç mund t'i duket blerësit menjëherë. Mund të krijojë një rrjedhë mjaft të madhe ajri dhe, më e rëndësishmja, lëshon një nivel mjaft të ulët zhurme. Nëse marrim parasysh koston e pranueshme të tij si për një model me cilësi të lartë të ventilatorit me kushineta, atëherë në këtë kategori mallrash për sa i përket çmimit / cilësive të konsumatorit do të jetë një nga më të mirët. Le të përsërisim se në laboratorin tonë të provës tifozi akasa AK-183-L2B ka funksionuar për më shumë se një vit, dhe cilësitë e tij të zhurmës praktikisht nuk kanë ndryshuar gjatë kësaj kohe.

Përparësitë:

• krijon një rrjedhë të madhe ajri;
• niveli i ulët i zhurmës;
• raport i mirë çmim / cilësi konsumator.

Disavantazhet përfshijnë:

• mungesa e mbështetjes PWM.

Ne shprehim mirënjohjen tonë për kompaninë PF Service LLC (Dnepropetrovsk) për pajisjet e ofruara për testim.

Artikulli është lexuar 4669 herë

Abonohuni në kanalet tona

Ju lutemi aktivizoni Javascript për të përdorur konvertuesin e njësisë

›› Më shumë informacion nga konverteri i njësisë

Sa cfm në 1 metër kub / minutë? Përgjigja është 35.314666212661.
Ne supozojmë se jeni duke u kthyer në mes këmbë kub / minutë dhe metër kub / minutë.
Mund të shikoni më shumë detaje për secilën njësi matjeje:
cfm ose metër kub / minutë
Njësia e nxjerrë nga SI për shpejtësia e rrjedhës së vëllimitështë metër kub / sekondë.
1 metër kub / sekondë është e barabartë me 2118.8799727597 cfm, ose 60 metër kub / minutë.
Vini re se mund të ndodhin gabime rrumbullakimi, prandaj kontrolloni gjithmonë rezultatet.
Përdorni këtë faqe për të mësuar se si të konvertoni midis këmbëve kub / minutë dhe metra kub / minutë.
Shkruani numrat tuaj në formular për të kthyer njësitë!

›› Grafiku i konvertimit të shpejtë të cfm në metër kub / minutë

1 cfm në metër kub / minutë = 0,02832 metër kub / minutë

10 cfm në metër kub / minutë = 0,28317 metër kub / minutë

20 cfm në metër kub / minutë = 0,56634 metër kub / minutë

30 cfm në metër kub / minutë = 0,84951 metër kub / minutë

40 cfm në metër kub / minutë = 1,13267 metër kub / minutë

50 cfm në metër kub / minutë = 1,41584 metër kub / minutë

100 cfm në metër kub / minutë = 2,83168 metër kub / minutë

200 cfm në metër kub / minutë = 5,66337 metër kub / minutë

›› Dëshironi njësi të tjera?

›› Përkufizimi: Këmbë kub / minutë

Këmbët kub për minutë (CFM) është një masë e përdorur në higjienën industriale dhe inxhinierinë e ventilimit. Ai përshkruan shpejtësinë e rrjedhjes së një vëllimi gazi ose ajri brenda ose jashtë një hapësire.

Një matje standarde e rrjedhës së ajrit që tregon se sa metra kub ajër kalojnë nga një pikë e palëvizshme në një minutë. Sa më i madh të jetë numri, aq më shumë ajër po kalon nëpër sistem. Shkalla vëllimore e rrjedhës së një lëngu ose gazi në këmbë kub në minutë. 1 CFM është afërsisht 0,47 litra në sekondë.

›› Konvertimet metrike dhe më shumë

faqe ofron një kalkulator konvertimi në internet për të gjitha llojet e njësive matëse. Mund të gjeni tabela të konvertimit metrikë për njësitë SI, si dhe njësitë angleze, monedhën dhe të dhëna të tjera. Shkruani simbolet e njësive, shkurtesat ose emrat e plotë për njësitë e gjatësisë, sipërfaqes, masës, presionit dhe llojeve të tjera. Shembujt përfshijnë mm, inç, 100 kg, ons lëngu amerikan, 6 "3", 10 gurë 4, cm kub, metra në katror, ​​gram, nishan, këmbë në sekondë dhe shumë të tjera!

• Përkthimi

Matja e pengesave të xhiros sipas kohës së kalimit të dyfishtë të paketave

Nga të gjitha llogaritë, interneti i sotëm nuk mund të lëvizë të dhënat aq shpejt sa duhet. Shumica e përdoruesve celularë në mbarë botën përjetojnë vonesa që variojnë nga disa sekonda në disa minuta: pikat e nxehta publike WiFi në aeroporte dhe konferenca janë edhe më të këqija. Fizikanët dhe klimatologët duhet të shkëmbejnë petabajtë të dhëna me kolegët në mbarë botën, por zbulojnë se infrastruktura e tyre e përpunuar shumë-gigabit shpesh shtyn vetëm disa megabit për sekondë në lidhjet transkontinentale.

Këto probleme lindën nga zgjedhja e arkitekturës që u bë gjatë krijimit të kontrollit të kongjestionit TCP në vitet '80 - atëherë humbja e paketave u vendos të interpretohej si "ngjeshur". Ekuivalenca e këtyre koncepteve ishte e vërtetë për atë kohë, por vetëm për shkak të kufizimeve të teknologjisë, dhe jo sipas përkufizimit. Kur NIC-të (kontrolluesit e ndërfaqes së rrjetit) u përmirësuan nga megabit në gigabit dhe çipat e memories nga kilobajt në gigabajt, lidhja midis humbjes së paketave dhe mbingarkesës u bë më pak e dukshme.

Në TCP moderne, kontrolli i mbingarkesës së humbjes së paketave - madje edhe në teknologjinë më të avancuar të këtij lloji, CUBIC - është shkaku kryesor i këtyre problemeve. Nëse buferët e bllokimit janë shumë të mëdhenj, kontrolli i mbingarkesës së humbjes së paketave i mban ato plot, duke shkaktuar buferim të panevojshëm të rrjetit. Nëse buferët janë shumë të vegjël, kontrolli i mbingarkesës së humbjes së paketave do ta keqinterpretojë humbjen e paketave si një sinjal mbingarkese, duke çuar në reduktimin e xhiros. Zgjidhja e këtyre problemeve kërkon një alternativë ndaj frenimit të humbjes së paketave. Për të gjetur këtë alternativë, duhet të kuptoni se ku dhe si ndodh bllokimi.

Bllokim dhe pengesë

Ekziston vetëm një lidhje më e ngadaltë në një lidhje TCP (të plotë dupleks) në çdo kohë të caktuar, ose ngushtica në çdo drejtim. Gryka e ngushtë është e rëndësishme për arsyet e mëposhtme:

• Ai përcakton shpejtësinë maksimale të transferimit të të dhënave në lidhje. Kjo është vetia kryesore e një rryme të dhënash të pakompresuara (për shembull, imagjinoni një autostradë me gjashtë korsi gjatë orës së pikut, nëse një aksident shkakton që një pjesë e vogël e rrugës të kufizohet në vetëm një korsi. Trafiku përpara vendit të përplasjes do të lëvizni jo më shpejt se trafiku nëpër atë korsi.
• Këtu formohen vazhdimisht radhë. Ato zvogëlohen vetëm nëse intensiteti i rrjedhës dalëse nga ngushtica e kalon intensitetin e rrjedhës hyrëse. Për lidhjet që funksionojnë me shpejtësinë më të lartë të biteve, të gjitha flukset dalëse në bllokun e ngushtë kanë gjithmonë një normë më të lartë dalëse, kështu që radhët lëvizin në bllokun e ngushtë.

Pavarësisht se sa lidhje janë në lidhje dhe cilat janë shpejtësitë e tyre individuale, nga pikëpamja e TCP, një rrugë arbitrare komplekse përfaqësohet si një lidhje e vetme me të njëjtin RTT (koha e dyfishtë e një pakete, d.m.th. koha vajtje-ardhje) dhe gjerësia e brezit të bllokut ... Dy kufizime fizike RTprop(koha e përhapjes vajtje-ardhje) dhe BtlBw(gjerësia e brezit të bllokut) ndikojnë në performancën e transmetimit. (Nëse shtegu i rrjetit do të ishte një tub material, RTprop do të ishte gjatësia e tubit dhe BtlBw do të ishte diametri i tij).

Figura 1 tregon kombinime të ndryshme të RTT dhe shpejtësisë së bitit me vëllimin e të dhënave. në fluturim, domethënë gjatë fluturimit (të dhënat e dërguara, por pa konfirmim të dorëzimit). Vijat blu tregojnë kufirin RTprop, vijat e gjelbra tregojnë kufirin BtlBw dhe vijat e kuqe tregojnë tamponin e bllokimit. Operacionet në zonat gri nuk janë të mundshme sepse ato kundërshtojnë të paktën një kufizim. Kalimet midis kufizimeve çuan në formimin e tre rajoneve (të kufizuara nga aplikacioni, me gjerësinë e brezit të kufizuar dhe të kufizuar në buffer) me sjellje cilësisht të ndryshme.

Foto 1

Kur nuk ka të dhëna të mjaftueshme gjatë fluturimit për të mbushur tubin, RTprop përcakton sjelljen; përndryshe dominon BtlBw. Linjat kufizuese kryqëzohen në pikën, e cila është edhe tubi BDP (produkti i gjerësisë së brezit-vonesë, derivati ​​i gjerësisë së brezit dhe vonesës). Meqenëse tubi është plot pas kësaj pike, teprica krijon një radhë në bllokun e ngushtë, duke rezultuar në një marrëdhënie lineare midis RTT dhe të dhënave gjatë fluturimit, të paraqitura në grafikun e sipërm. Paketat hidhen kur teprica tejkalon kapacitetin buferik. Bllokimiështë vetëm një vendndodhje e vazhdueshme në të djathtë të linjës BDP, dhe kontrolli i mbingarkesës- një lloj skeme për vendosjen e një kufiri se sa larg në të djathtë të linjës BDP, mesatarisht, bëhet transferimi i të dhënave.

Kontrolli i mbingarkesës së humbjeve funksionon në skajin e djathtë të rajonit të kufizuar me gjerësi brezi, duke siguruar gjerësinë e plotë të brezit të bllokimit në kurriz të vonesës së lartë dhe humbjes së shpeshtë të paketave. Në ditët kur memoria ishte e shtrenjtë, madhësitë e tamponit ishin vetëm pak më të mëdha se BDP, gjë që minimizoi vonesën e tepërt të kontrollit të mbingarkesës me humbje. Uljet e mëvonshme të çmimit të memories rezultuan në rritjen e buferimit të rrjetit dhe rritjen e RTT në sekonda në vend të milisekondave.

Në skajin e majtë të zonës me kapacitet të kufizuar, ka një pikë funksionimi me kushte më të mira se në të djathtë. Në 1979, Leonard Kleinrock tregoi se kjo pikë operimi është optimale, ajo maksimizon xhiron aktuale duke minimizuar vonesën dhe humbjen, si për lidhjet individuale ashtu edhe për rrjetin në tërësi. Fatkeqësisht, në të njëjtën kohë, Jeffrey Yaffe vërtetoi se ishte e pamundur të krijohej një algoritëm i shpërndarë që konvergjon në këtë pikë operimi. Ky zbulim ndryshoi drejtimin e hulumtimit. Në vend që të kërkonin një algoritëm të shpërndarë që kërkon pikën optimale të funksionimit të Kleinrock, studiuesit filluan të eksplorojnë qasje alternative për kontrollin e mbingarkesës.

Grupi ynë në Google shpenzon orë të tëra çdo ditë duke studiuar regjistrat me përgjime të titujve të paketave TCP nga e gjithë bota, duke kuptuar anomalitë dhe patologjitë e sjelljes. Zakonisht, gjëja e parë që kërkojmë janë karakteristikat kryesore të rrugës, RTprop dhe BtlBw. Fakti që ato mund të rrjedhin nga gjurmët e rrjetit sugjeron se përfundimi i Jaffe mund të mos jetë aq i drejtpërdrejtë sa dukej dikur. Përfundimi i tij mbështetet në pasigurinë themelore të matjes (për shembull, nëse rritja e matur në RTT është për shkak të një ndryshimi në gjatësinë e rrugës, një ulje në xhiron e bllokut ose një rritje në vonesën e radhës për shkak të trafikut nga një lidhje tjetër). Ndërsa është e pamundur të eliminohet pasiguria e çdo matjeje të veçantë, sjellja e përbërjes me kalimin e kohës ofron një pamje më të qartë, duke sugjeruar mundësinë e aplikimit të strategjive matëse të dizajnuara për të eliminuar pasigurinë.

Duke i kombinuar këto matje me një qark të besueshëm gjurmimi dhe duke aplikuar përparimet më të fundit në sistemet e kontrollit, shpresa është që të zhvillohet një protokoll i shpërndarë i kontrollit të mbipopullimit që i përgjigjet mbingarkesës aktuale dhe jo humbjes së paketave ose vonesave të shkurtra në radhë. Dhe do të konvergojë me një probabilitet të lartë në pikën optimale të funksionimit të Kleinrock. Kështu filloi projekti ynë tre-vjeçar për të zhvilluar një sistem të menaxhimit të mbipopullimit të bazuar në matjen e dy parametrave që karakterizojnë një rrugë: xhiroja e bllokimit dhe koha e kalimit të dyfishtë të paketave, ose BBR.

Karakteristikë e ngushticës

Lidhja funksionon me shpejtësi maksimale dhe vonesë minimale kur (balanca e shpejtësisë) shkalla me të cilën paketat arrijnë në bllokun e ngushtë është e barabartë me BtlBw dhe (kanali i plotë) sasia totale e të dhënave në fluturim është e barabartë me BDP ().

Kushti i parë siguron që pengesa të përdoret 100%. E dyta siguron që ne kemi të dhëna të mjaftueshme për të parandaluar një bllokim të thjeshtë, por jo për të tejmbushur kanalin. Vetë gjendja e bilancit të shpejtësisë jo garanton që nuk ka radhë, por vetëm madhësia e saj e pandryshuar (për shembull, nëse një lidhje fillon duke dërguar një dritare fillestare me 10 pako te një BDP me pesë pako, më pas funksionon saktësisht me të njëjtën shpejtësi bllokimi, pastaj pesë nga dhjetë paketat fillestare do të mbushë kanalin, dhe teprica do të formojë një radhë në këmbë në një vend të ngushtë që nuk mund të shpërndahet). Po kështu, një kusht i kanalit të plotë nuk garanton asnjë radhë (për shembull, një lidhje dërgon BDP në breshëri mbi BDP / 2 dhe shfrytëzon plotësisht bllokimin, por radha mesatare është BDP / 4). Mënyra e vetme për të minimizuar radhën në bllokun e ngushtë dhe në të gjithë kanalin është të përmbushni të dy kushtet në të njëjtën kohë.

Vlerat BtlBw dhe RTprop ndryshojnë gjatë jetës së lidhjes, kështu që ato duhet të vlerësohen vazhdimisht. Aktualisht, TCP monitoron RTT (intervali kohor midis dërgimit të një pakete të dhënash në mesazhin që është dorëzuar), sepse kërkohet për të përcaktuar humbjen. Në çdo kohë të caktuar,

ku është "zhurma" nga radhët përgjatë rrugës, strategjia e marrësit me vonesën e njohjeve, akumulimi i mirënjohjeve etj. RTprop është një karakteristikë fizike e lidhjes dhe ndryshon vetëm kur ndryshon vetë kanali. Meqenëse ndryshimet e kanalit ndodhin në një shkallë kohe ≥ RTprop, atëherë do të bëhet një vlerësim i paanshëm dhe efektiv i kohës
domethënë, nisja në një dritare kohore (e cila zakonisht është nga dhjetëra sekonda në minuta).

Ndryshe nga RTT, asgjë në specifikimet TCP nuk kërkon një zbatim për të gjurmuar xhiron e ngushta, por një vlerësim i mirë i kësaj mund të merret nga gjurmimi i shpejtësisë së dorëzimit. Kur konfirmimi i dorëzimit të një pakete i kthehet dërguesit, ai tregon RTT-në e paketës dhe njofton dërgimin e të dhënave në fluturim kur paketa largohet. Shpejtësia mesatare e dorëzimit ndërmjet dërgimit të një pakete dhe marrjes së një konfirmimi është raporti i të dhënave të dorëzuara me kohën e kaluar:. Kjo shpejtësi duhet të jetë më e vogël ose e barabartë me xhiron e bllokut (sasia në mbërritje dihet saktësisht, kështu që e gjithë pasiguria qëndron në të cilën duhet të jetë më e madhe ose e barabartë me intervalin aktual të mbërritjes; prandaj, raporti duhet të jetë më i vogël se ose e barabartë me shpejtësinë reale të dorëzimit, e cila, në radhën e saj, kufizohet nga lart nga kapaciteti i fytit të ngushtë). Prandaj, dritarja maksimale e normës së dorëzimit është një vlerësim efikas dhe jo i veçantë i BtlBw:

ku dritarja kohore është zakonisht gjashtë deri në dhjetë RTT.

TCP duhet të regjistrojë kohën e dërgimit të secilës paketë për të llogaritur RTT. BBR i plotëson këto regjistrime me sasinë totale të të dhënave të dorëzuara në mënyrë që mbërritja e çdo konfirmimi të raportojë si matjen e RTT ashtu edhe atë të shkallës së dorëzimit, të cilat filtrat i konvertojnë në vlerësime RTprop dhe BtlBw.

Vini re se këto vlera janë plotësisht të pavarura: RTprop mund të ndryshojë (për shembull, kur ndryshohet rruga), por ka të njëjtën pengesë, ose BtlBw mund të ndryshojë (për shembull, kur ndryshon gjerësia e brezit pa tel) pa ndryshuar rrugën. (Pavarësia e të dy kufizimeve është arsyeja pse ato duhet të njihen për të lidhur sjelljen e transportit me rrugën e dorëzimit). Meqenëse RTprop është i dukshëm vetëm në anën e majtë të BDP, dhe BtlBw është i dukshëm vetëm në anën e djathtë në Figurën 1, ato i binden parimit të pasigurisë: sa herë që mund të matet njëra nga të dyja, tjetra nuk mund të matet. Në mënyrë intuitive, kjo mund të kuptohet si më poshtë: për të përcaktuar kapacitetin e një kanali, ai duhet të mbimbushet, gjë që krijon një radhë që nuk bën të mundur matjen e gjatësisë së kanalit. Për shembull, një aplikacion me një protokoll kërkesë/përgjigje nuk mund të dërgojë kurrë të dhëna të mjaftueshme për të mbushur kanalin dhe për të vëzhguar BtlBw. Shumë orë të transferimit të një sasie të madhe të dhënash mund të kalojë gjithë kohën e saj në një zonë me gjerësi bande të kufizuar dhe të marrë vetëm një mostër të vetme RTprop nga RTT nga paketa e parë. Parimi i qenësishëm i pasigurisë do të thotë që përveç vlerësimeve për rindërtimin e dy parametrave të rrugës, duhet të ketë gjendje që gjurmohen njëkohësisht dhe çfarë mund të mësohet në pikën aktuale të funksionimit dhe, pasi informacioni humbet freskinë, si të shkohet në funksionim. pika ku mund të merret.të dhëna më të fundit.

Harta e një rryme pakete në një shteg shpërndarjeje

Algoritmi kryesor BBR ka dy pjesë:

Kur marrim konfirmimin (pranim)

Çdo konfirmim ofron një RTT të ri dhe matje mesatare të shkallës së dorëzimit që përditësojnë vlerësimet e RTprop dhe BtlBw:

Funksioni onAck (paketë) rtt = tani - packet.sendtime update_min_filter (RTpropFilter, rtt) dorëzuar + = packet.size dorëzuar_kohë = tani deliveryRate = (dorëzuar - packet.dorëzohet) / (koha e dorëzimit - packet.dorëzohet_koha e paketës. aktualMax ||! packet.app_limited) update_max_filter (BtlBwFilter, deliveryRate) if (app_limited_deri> 0) app_limited_deri = app_limited_deri - packet.size
Kontrolli nëse nevojitet për shkak të problemit të paqartësisë së diskutuar në paragrafin e fundit: dërguesit mund të kufizohen nga aplikimi, domethënë, aplikacionit mund t'i mbarojnë të dhënat për të mbushur rrjetin. Kjo është një situatë mjaft e zakonshme për shkak të trafikut të kërkesave / përgjigjeve. Kur ka një mundësi për të dërguar, por nuk dërgohen të dhëna, BBR shënon mostrat përkatëse të gjerësisë së brezit si "app limited", domethënë app_limited (shih pseudokodin e dërgimit ()). Ky kod përcakton se cilat modele duhet të përfshihen në modelin e gjerësisë së brezit, kështu që pasqyron kufijtë e rrjetit, jo kufijtë e aplikacionit. BtlBw është një kufi i sipërm i vendosur në shkallën e dorëzimit, kështu që një normë e matur e dorëzimit më e madhe se vlerësimi aktual BtlBw duhet të nënvlerësojë BtlBw, pavarësisht nëse kampioni ishte i kufizuar nga aplikimi apo jo. Përndryshe, modelet e kufizuara nga aplikimi hidhen poshtë. (Figura 1 tregon se në rajonin me kufizimin e aplikimit Rate ofrimit, parametri BtlBw është nënvlerësuar). Këto kontrolle parandalojnë që filtri BtlBw të mbushet me vlera të nënvlerësuara, gjë që mund të ngadalësojë dërgimin e të dhënave.

Kur të dhënat dërgohen

Për të lidhur shkallën e mbërritjes së paketave me shkallën e largimit nga blloku, BBR monitoron çdo paketë të dhënash. (BBR duhet të përputhet norma pengesë: Kjo do të thotë që gjurmimi është një pjesë integrale e arkitekturës dhe një pjesë themelore e punës - prandaj ritmi_ritmiështë parametri kryesor i kontrollit. Parametri ndihmës cwnd_gain lidh gjatë fluturimit me një grup të vogël BDP-sh për të trajtuar patologjitë tipike të rrjetit dhe të marrësve (shih kapitullin mbi njohjet e vonuara dhe të zgjeruara më poshtë). Konceptualisht, një procedurë e dërgimit të TCP duket si kodi i mëposhtëm. (Në Linux, dërgimi i të dhënave përdor radhë efikase FQ / ritëm, e cila i jep BBR performancën lineare të një lidhjeje të vetme në lidhje me shumë gigabit dhe trajton mijëra lidhje më të ngadalta me kosto të papërfillshme të CPU.)

Funksioni dërgo (paketë) bdp = BtlBwFilter.currentMax × RTpropFilter.currentMin if (inflight> = cwnd_gain × bdp) // presim për ack ose ritransmetim të kthimit të afatit të ritransmetimit nëse (tani> = nextSendTime) paketa = nextPacketToSend (appe_limited) = kthim gjatë fluturimit packet.app_limited = (app_limited_deri> 0) packet.sendtime = tani packet.delivered = dorëzuar packet.delivered_time = dërgesë_kohë anije (paketë) NextSendTime = tani + madhësia e paketës / (pacing_gain × BtlcurrBwFtt Ora e ardhshmeSend)
Sjellja në gjendje të qëndrueshme

Shpejtësia dhe sasia e të dhënave të dërguara përmes BBR varet vetëm nga BtlBw dhe RTprop, kështu që filtrat kontrollojnë jo vetëm vlerësimet e kufizimeve të ngushta, por edhe aplikimin e tyre. Kjo krijon qarkun e kontrollit të personalizuar të paraqitur në figurën 2, i cili tregon RTT (blu), në fluturim (jeshile) dhe shpejtësinë e dorëzimit (e kuqe) mbi 700ms për një transmetim 10Mbit 40ms. Vija gri e theksuar mbi normën e dorëzimit është gjendja e filtrit maksimal BtlBw. Format trekëndore përftohen duke aplikuar në mënyrë ciklike koeficientin e rritjes së ritmit në BBR për të përcaktuar rritjen e BtlBw. Fitimi në secilën pjesë të ciklit tregohet në përputhje kohore me të dhënat që ka ndikuar. Ky faktor funksionoi në RTT më herët kur u dërguan të dhënat. Kjo tregohet nga parregullsitë horizontale në përshkrimin e sekuencës së ngjarjeve në anën e majtë.

Foto 2

BBR minimizon vonesën sepse shumica e kohës kalon me të njëjtin BDP në veprim. Për shkak të kësaj, pengesa lëviz tek dërguesi, në mënyrë që rritja në BtlBw të bëhet e padukshme. Prandaj, BBR shpenzon periodikisht intervalin RTprop në pacing_gain> 1, gjë që rrit shpejtësinë e dërgimit dhe sasinë e të dhënave të dërguara pa konfirmim të dorëzimit (inflight). Nëse BtlBw nuk ndryshon, atëherë radha krijohet përballë bottleneck, duke rritur RTT, e cila mban konstante normën e dorëzimit. (Radha mund të eliminohet duke dërguar të dhënat me vlerën kompensuese pacing_gain< 1 для следующего RTprop). Если BtlBw увеличивается, то скорость deliveryRate тоже увеличивается, а новое максимальное значение фильтра немедленно увеличивает базовую скорость отслеживания (ritmi_ritmi). Për këtë arsye, BBR përshtatet me madhësinë e re të ngushtë në mënyrë eksponenciale. Figura 3 tregon këtë efekt në një transmetim 10 Mbps 40 ms, i cili BtlBw papritmas rritet deri në 20 Mbps pas 20 sekondash funksionimi të qëndrueshëm (në të majtë të grafikut), më pas bie në 10 Mbps pas 20 sekondash të tjera funksionimi të qëndrueshëm me 20 Mbps (ana e djathtë e grafikut).

Figura 3

(Në thelb, BBR është një shembull i thjeshtë i një sistemi kontrolli "max-plus", një qasje e re ndaj sistemeve të kontrollit të bazuar në algjebër jo standarde max-plus. Kjo qasje lejon përshtatjen e shpejtësisë [e kontrolluar nga raporti i marsheve maksimumi] pavarësisht nga rritja e radhës [e kontrolluar nga raporti i transmetimit mesatare]. Siç zbatohet për problemin tonë, ai zbret në një qark të thjeshtë kontrolli të pakushtëzuar, ku përshtatja ndaj ndryshimeve në kufizimet fizike kryhet automatikisht duke ndryshuar filtrat që shprehin këto kufizime. Një sistem tradicional do të kërkonte krijimin e shumë sytheve të kontrollit të kombinuara në një makinë komplekse shtetërore për të arritur këtë rezultat.)

Sjellja kur fillon një transmetim të vetëm BBR

Implementimet moderne trajtojnë ngjarje si fillimi, mbyllja dhe rikuperimi i humbjeve me algoritme "ngjarje" me shumë rreshta kodi. BBR përdor kodin e mësipërm (në kapitullin e mëparshëm "Përputhja e një transmetimi pakete me një rrugë dërgese") për gjithçka. Ngjarjet trajtohen duke përshkuar një sekuencë "gjendjesh". Vetë "shtetet" përcaktohen nga një tabelë me një ose më shumë vlera fikse të koeficientëve dhe kritereve të daljes. Pjesa më e madhe e kohës shpenzohet në gjendjen ProbeBW, e cila përshkruhet në kapitullin "Sjellja e gjendjes së qëndrueshme". Gjendjet Startup dhe Drain përdoren gjatë fillimit të lidhjes (Figura 4). Për të trajtuar një lidhje ku xhiroja rritet me 12 rend të madhësisë, gjendja e fillimit zbaton një algoritëm kërkimi binar për BtlBw, i cili përdor një faktor transmetimi për të dyfishuar shpejtësinë e transmetimit kur rritet shkalla e dërgimit. Kjo përcakton BtlBw në RTT, por në të njëjtën kohë krijon një radhë të panevojshme përpara. Sapo Startup gjen BtlBw, sistemi BBR kalon në gjendjen Drain, i cili përdor raportet inverse të ingranazheve të Startup-it për të hequr qafe radhën e tepërt dhe më pas në gjendjen ProbeBW sapo fluturimi zbret në linjën BDP.

Figura 4

Figura 4 tregon sekondën e parë të një rryme 10 Mbit 40ms BBR. Grafiku i sipërm tregon kohën dhe sekuencën e ngjarjeve, si dhe përparimin e dërguesit (jeshile) dhe marrësit (blu): sasinë e të dhënave të dërguara dhe të marra. Vija e kuqe tregon performancën e dërguesit duke përdorur teknologjinë CUBIC në të njëjtat kushte. Vijat vertikale gri tregojnë kohën e tranzicionit midis gjendjeve BBR. Grafiku i poshtëm tregon ndryshimin në kohën e udhëtimit vajtje-ardhje (RTT) të të dy lidhjeve. Ju lutemi vini re se afati kohor për këtë orar korrespondon me kohën e marrjes së konfirmimit të mbërritjes (ack). Prandaj, mund të duket se grafikët duket se janë zhvendosur në kohë, por në fakt ngjarjet më poshtë korrespondojnë me ato momente kur sistemi BBR mëson për këto ngjarje dhe reagon.

Grafiku i poshtëm në figurën 4 krahason BBR dhe CUBIC. Në fillim, sjellja e tyre është pothuajse e njëjtë, por BBR zbraz plotësisht radhën e formuar në fillim të lidhjes dhe CUBIC nuk mund ta bëjë këtë. Nuk ka një model gjurmësh për t'ju treguar se sa nga të dhënat e dërguara janë të tepërta. Prandaj, CUBIC po rrit më pak në mënyrë agresive transmetimin e të dhënave pa konfirmimin e dorëzimit, por kjo rritje vazhdon derisa tamponi i bllokimit të tejmbushet dhe të fillojë të hedhë paketat, ose derisa marrësi të arrijë kufirin për të dhënat e dërguara pa konfirmim (dritarja e marrjes së TCP).

Figura 5 tregon sjelljen RTT në tetë sekondat e parë të lidhjes të përshkruar në figurën e mëparshme 4. Teknologjia CUBIC (me të kuqe) mbush të gjithë buferin e disponueshëm, më pas rrotullohet midis 70% dhe 100% mbushje çdo disa sekonda. Pasi të fillojë lidhja, BBR (e gjelbër) funksionon me pak ose aspak radhë.

Figura 5

Sjellja kur rryma të shumta BBR takohen në një pengesë

Figura 6 tregon se si xhiroja e rrymave të shumta BBR konvergon në një seksion të sinqertë prej 100 megabitësh / 10 milisekonda të ngushta. Strukturat trekëndore të kthyera nga poshtë janë gjendje të lidhjeve ProbeRTT në të cilat vetësinkronizimi përshpejton konvergjencën përfundimtare.

Figura 6

Ciklet e fitimit të ProbeBW (Figura 2) stimulojnë rryma më të mëdha për të dhënë gjerësi brezi në rrjedhat më të vogla, si rezultat i të cilave çdo rrjedhë kupton gjendjen e tij të sinqertë. Kjo ndodh mjaft shpejt (disa cikle ProbeBW), megjithëse padrejtësia mund të vazhdojë nëse thread-et me vonesë në fillim të rishpërndarjes mbivlerësojnë RTprop për shkak të faktit se temat që kanë filluar më herët (përkohësisht) krijojnë një radhë.

Për të zbuluar RTProp-in e vërtetë, rryma lëviz në të majtë të linjës BDP duke përdorur gjendjen ProbeRTT: nëse vlerësimi RTProp nuk përditësohet (d.m.th., duke matur një RTT më të vogël) për shumë sekonda, atëherë BBR hyn në gjendjen ProbeRTT , duke reduktuar sasinë e të dhënave të dërguara (në fluturim) në katër pako për të paktën një kalim të dyfishtë dhe më pas kthehet në gjendjen e mëparshme. Kur threads të mëdhenj hyjnë në gjendjen ProbeRTT, shumë paketa hiqen nga radha, në mënyrë që disa thread të shohin vlerën e re RTprop (minimumi i ri RTT). Falë kësaj, vlerësimet e tyre RTprop rivendosen në zero në të njëjtën kohë, në mënyrë që të gjithë të hyjnë në gjendjen ProbeRTT së bashku - dhe radha ulet edhe më shumë, si rezultat i së cilës edhe më shumë fije shohin vlerën e re RTprop, etj. . Ky koordinim i shpërndarë është çelësi për gjerësinë e drejtë të brezit dhe stabilitetin.

BBR sinkronizon threads rreth ngjarjes së dëshiruar, e cila është një radhë bosh në një bllokim. Në kontrast me këtë qasje, frenimi i mbingarkesës së humbjes së paketave sinkronizon flukset rreth ngjarjeve të padëshiruara si rritja periodike e radhëve dhe tejmbushjet e buferit, gjë që rrit vonesën dhe humbjen e paketave.

Përvojë e zbatimit të B4 WAN në Google

B4 i Google është një WAN (rrjet me zonë të gjerë) me shpejtësi të lartë, i ndërtuar mbi ndërprerës konvencionalë me kosto të ulët. Humbjet në këta ndërprerës të cekët të tamponit janë kryesisht për shkak të rritjes së rastësishme të shpërthimeve të vogla të trafikut. Në vitin 2015, Google filloi të zhvendoste trafikun e punës nga CUBIC në BBR. Asnjë problem apo regresion nuk është raportuar dhe që nga viti 2016 i gjithë trafiku B4 TCP përdor BBR. Figura 7 ilustron një arsye për këtë: xhiroja e BBR është vazhdimisht 2-25 herë më e madhe se ajo e CUBIC. Ne pamë një përmirësim edhe më të madh, por zbuluam se 75% e lidhjeve BBR janë të kufizuara nga buferi i marrjes së TCP në kernel, të cilin stafi i operacioneve të rrjetit e vendos qëllimisht në një vlerë të ulët (8MB) për të parandaluar CUBIC nga vërshimi i rrjetit me megabajt trafik të tepërt. pa konfirmim të dorëzimit (nëse ndani 8 MB me 200 ms RTT ndërkontinentale, merrni maksimum 335 Mbps). Rritja manuale e tamponit të marrjes në një rrugë të vetme SHBA-Evropë rriti menjëherë shpejtësinë e të dhënave BBR në 2 Gbps, ndërsa CUBIC mbeti në 15 Mbps - një rritje relative 133-fish në xhiros e parashikuar nga puna e Matis et al. në 1997.

Figura 7

Figura 7 tregon përmirësimin relativ në BBR mbi CUBIC; Shiriti anësor tregon funksionet kumulative të shpërndarjes (CDF) për xhiros. Matjet u morën duke përdorur shërbimin e sensorit aktiv, i cili hap lidhje të përhershme BBR dhe CUBIC në qendrat e largëta të të dhënave, më pas transferon 8 MB të dhëna çdo minutë. Sondat eksplorojnë shumë rrugë B4 midis Amerikës së Veriut, Evropës dhe Azisë.

Përmirësimi i madh është një pasojë e drejtpërdrejtë e BBR jo përdor humbjen e paketave si tregues të mbingarkesës. Për të arritur xhiron e plotë, teknikat ekzistuese të kontrollit të mbipopullimit të humbjeve të paketave kërkojnë që shkalla e humbjes të jetë më e vogël se katrori i anasjelltë i BDP-së (p.sh., më pak se një humbje për 30 milionë paketa për një lidhje 10 Gbps / 100 ms). Figura 8 krahason xhiron e matur të përdorshëm në nivele të ndryshme të humbjes së paketave. Në CUBIC, toleranca e humbjes së paketës është një veti strukturore e algoritmit, dhe në BBR është një parametër konfigurimi. Ndërsa humbja në BBR i afrohet fitimit maksimal të ProbeBW, probabiliteti i matjes së shpejtësisë së shpërndarjes së BtlBw real bie ndjeshëm, gjë që çon në një nënvlerësim nga ana e filtrit maksimal.

Figura 8

Figura 8 krahason gjerësinë e brezit të përdorshëm të BBR dhe CUBIC në një transmetim 60 sekondash në një lidhje 100 Mbps dhe 100 ms me humbje të rastësishme që variojnë nga 0.001% në 50%. Shpejtësia e CUBIC zvogëlohet 10 herë me një humbje prej 0.1% dhe ngec plotësisht në më shumë se 1%. Gjerësia maksimale e brezit është fraksioni i gjerësisë së brezit minus humbjen e paketës (). BBR po mbahet në këtë nivel në nivelin e humbjeve prej 5% dhe afër tij deri në 15%.

Përvojë në zbatimin e YouTube Edge

BBR është vendosur në serverët e videove YouTube dhe Google.com. Google po kryen një eksperiment të vogël në të cilin një përqindje e vogël e përdoruesve transferohen aksidentalisht në BBR ose CUBIC. Riprodhimi i videos BBR tregon një përmirësim të ndjeshëm në të gjitha vlerësimet e përdoruesve për cilësinë e shërbimit. Ndoshta sepse sjellja e BBR është më e qëndrueshme dhe e parashikueshme. BBR vetëm pak përmirëson gjerësinë e brezit të lidhjes sepse YouTube tashmë po përshtat shpejtësinë e transmetimit shumë më poshtë BtlBw për të minimizuar buferimin dhe ri-buferimin e panevojshëm të rrjetit. Por edhe këtu, BBR ul mesataren mesatare të RTT me 53% globalisht dhe më shumë se 80% në vendet në zhvillim.

Figura 9 tregon përmirësimin mesatar në RTT kundrejt BBR dhe CUBIC mbi 200 milionë shikime të videove në YouTube të matura në pesë kontinente gjatë një jave. Më shumë se gjysma e 7 miliardë lidhjeve celulare në botë janë 2.5G me 8Kbps deri në 114Kbps, me probleme të mirëdokumentuara me teknikat e kontrollit të mbingarkesës së humbjes së paketave që priren të tejmbushin buferët. Gryka e ngushtë në këto sisteme është zakonisht midis SGSN (Serving GPRS Support Node) dhe pajisjes celulare. Softueri SGSN funksionon në një platformë standarde PC me RAM të bollshëm, shpesh me megabajt bufer midis internetit dhe pajisjes celulare. Figura 10 krahason vonesën (emuluar) SGSN ndërmjet internetit dhe celularit për BBR dhe CUBIC. Linjat horizontale shënojnë një nga pasojat më të rënda: TCP përshtatet me vonesat e gjata RTT me përjashtim të paketës SYN që nis lidhjen, e cila ka një afat kohor të caktuar, në varësi të sistemit operativ. Kur një pajisje celulare merr një sasi të madhe të dhënash (për shembull, nga përditësimet automatike të softuerit) përmes një buferi të madh SGSN, pajisja nuk mund të krijojë asnjë lidhje në internet derisa radha të jetë e lirë (SYN ACK vonohet më shumë se SYN fikse timeout) ...

Figura 9

Figura 10 tregon ndryshimet mesatare të RTT në gjendje të qëndrueshme dhe kundrejt madhësisë së tamponit në një lidhje 128 Kbps dhe 40 ms me tetë transmetime BBR (jeshile) ose CUBIC (të kuqe). BBR e mban radhën në vlerat minimale, pavarësisht nga madhësia e tamponit të bllokut dhe numri i thread-ve aktive. Rrjedhat CUBIC gjithmonë mbushin buferin, kështu që vonesa rritet në mënyrë lineare me madhësinë e tamponit.

Figura 10

Brez përshtatës në celularin celular

Sistemet celulare përshtatin gjerësinë e brezit për çdo përdorues pjesërisht bazuar në parashikimin e kërkesës, i cili merr parasysh radhën e paketave të destinuara për atë përdorues. BBR-të e hershme u akorduan për të krijuar radhë shumë të vogla, duke bërë që lidhjet të bllokoheshin me shpejtësi të ulët. Rritja e pikut pacing_gain për ProbeBW dhe rritja e radhëve rezultoi në më pak lidhje të bllokuara. Kjo tregon përshtatshmëri të madhe për disa rrjete. Me vlerën aktuale të fitimit të pikut, nuk ka degradim në asnjë rrjet në krahasim me CUBIC.

Paketat e vonuara dhe të zgjatura

Rrjetet celulare, WiFi dhe me brez të gjerë shpesh vonojnë dhe grumbullojnë paketa ack. Kur fluturimi është i kufizuar në një BDP, ai shkakton ngecje, duke reduktuar gjerësinë e brezit. Rritja e faktorit cwnd_gain të ProbeBW në dy lejoi që transmetimi i qetë të vazhdonte me shpejtësinë e parashikuar të dërgesës, edhe kur paketat ack vonoheshin me një RTT. Kjo parandalon në masë të madhe prishjet.

Kufizuesit aktual të kovës

Shpërndarja fillestare e BBR në YouTube tregoi se shumica e ISP-ve në botë po anulojnë trafikun me kufizuesit aktualë të tarifave të kovës. Kova është zakonisht plot në fillim të lidhjes, kështu që BBR njeh parametrin BtlBw për rrjetin themelor. Por sapo kova të zbrazet, atëherë të gjitha paketat e dërguara më shpejt se shkalla e mbushjes së kovës (shumë më e ulët se BtlBw) hidhen poshtë. BBR përfundimisht mëson këtë normë të re shpërndarjeje, por çiklizmi i fitimit të ProbeBW rezulton në humbje të moderuara të vazhdueshme. Për të minimizuar humbjen e gjerësisë së brezit në rrjedhën e sipërme dhe rritjen e vonesës së aplikimit nga kjo humbje, ne kemi shtuar një detektor të dedikuar gërshërë dhe një model të qartë gërshërë në BBR. Ne po eksplorojmë gjithashtu në mënyrë aktive mënyrat më të mira për të eliminuar dëmin nga kufizuesit e shpejtësisë.

Konkurrenca me metodat e kontrollit të mbingarkesës së humbjes së paketave

BBR zbret në ndarjen e ndershme të gjerësisë së brezit të një blloku të ngushtë, qoftë në konkurrencë me prurjet e tjera BBR ose rrjedhat e drejtuara nga teknikat e kontrollit të mbingarkesës së humbjes së paketave. Edhe kur këto të fundit mbushin buferin e disponueshëm, ProbeBW ende anon në mënyrë të besueshme vlerësimin BtlBw drejt ndarjes së drejtë dhe ProbeRTT e konsideron vlerësimin RTProp mjaft të lartë për të konverguar tit për tat në ndarje të drejtë. Megjithatë, buferët e pamenaxhuar të ruterit që tejkalojnë disa BDP po i detyrojnë konkurrentët e vjetër të kontrollit të mbipopullimit të fryjnë radhën dhe të kapin më shumë se pjesa e tyre e drejtë. Eliminimi i kësaj është një fushë tjetër e kërkimit aktiv.

konkluzioni

Rimendimi i menaxhimit të mbipopullimit është një përfitim i madh. Në vend që të përdorë ngjarje të tilla si humbja e tamponit ose kapja e tamponit që lidhen vetëm dobët me mbingarkesën, BBR fillon me modelin formal të kongjestionit të Kleinrock dhe pikën optimale të funksionimit të lidhur. Konkluzioni i bezdisshëm se është "e pamundur" të përcaktohet njëkohësisht vonesa kritike dhe gjerësia e brezit, anashkalohet duke vëzhguar se ato mund të parashikohen njëkohësisht. Përparimet më të fundit në sistemet e kontrollit dhe teorinë e vlerësimit aplikohen më pas për të krijuar një qark të thjeshtë kontrolli të shpërndarë që i afrohet optimales duke përdorur plotësisht rrjetin duke mbajtur një radhë të vogël. Zbatimi BBR i Google është i disponueshëm në kernelin Linux me burim të hapur dhe është i detajuar në shtojcën e këtij artikulli.

Teknologjia BBR përdoret në shtyllën kurrizore të Google B4, duke përmirësuar gjerësinë e brezit me urdhra të madhësisë mbi CUBIC. Ai është vendosur gjithashtu në serverët e uebit të Google dhe YouTube, duke reduktuar ndjeshëm vonesën në të pesë kontinentet e testuar deri më tani, me një fokus të fortë në vendet në zhvillim. Teknologjia BBR funksionon ekskluzivisht në anën e dërguesit dhe nuk kërkon ndryshime në protokoll, marrës ose rrjet, gjë që lejon që ajo të vendoset në mënyrë graduale. Varet vetëm nga RTT dhe njoftimet e dorëzimit të paketave, kështu që mund të përdoret në shumicën e protokolleve të transportit në internet.

Mirënjohje

Autorët i janë mirënjohës Len Kleinrock për udhëzimet se si të trajtohet siç duhet bllokimi. I jemi borxhli Larry Brakmo për punën pioniere në sistemet e menaxhimit të mbipopullimit në Vegas dhe New Vegas që parashikuan shumë nga elementët e BBR, dhe për këshillat dhe udhëzimet e tij gjatë zhvillimit të hershëm të BBR. Dëshirojmë të falënderojmë gjithashtu Eric Dumazet, Nandita Dukkipati, Jana Iyengar, Ian Swett, M. Fitz Nowlan, David Wetherall, Leonid Leonidas Kontothanassis, Amin Vahdat dhe ekipin e Google BwE dhe YouTube Infrastructure për ndihmën dhe mbështetjen e tyre të paçmuar.

Shtojca - përshkrim i detajuar

Makinë shtetërore për hetimin sekuencial

Pacing_gain kontrollon se sa shpejt dërgohen paketat në lidhje me BtlBw dhe ky është çelësi i veçorisë inteligjente BBR. Kur pacing_gain është më i madh se një, rritet gjatë fluturimit dhe hendeku midis paketave zvogëlohet, gjë që e zhvendos lidhjen në anën e djathtë në figurën 1. Kur pacing_gain është më pak se një, ndodh efekti i kundërt, lidhja lëviz majtas.

BBR përdor pacing_gain për të zbatuar një makineri të thjeshtë ndijuese sekuenciale të gjendjes që alternon mes testimit për më shumë gjerësi brezi dhe testimit për më pak kohë të kalimit të dyfishtë. (Nuk është e nevojshme të testohet për një gjerësi bande më të ulët, sepse përpunohet automatikisht nga filtri BtlBw msx: matjet e reja pasqyrojnë rënien, kështu që BtlBw do të korrigjohet vetë sapo të hiqen ndryshimet e fundit të vjetra nga filtri sipas afatit. Filtri RTprop min trajton rritjen në rrugën e dorëzimit në të njëjtën mënyrë) ...

Nëse gjerësia e brezit të bllokimit rritet, BBR duhet të dërgojë të dhëna më shpejt në mënyrë që t'i zbulojë ato. Po kështu, nëse koha aktuale e kalimit të dyfishtë të paketës ndryshon, kjo ndryshon BDP-në dhe për këtë arsye BDP-ja duhet të dërgojë të dhëna më ngadalë për të mbajtur fluturimin poshtë BDP-së për të matur RTprop-in e ri. Prandaj, mënyra e vetme për të zbuluar këto ndryshime është të eksperimentoni duke dërguar më shpejt për të kontrolluar një rritje në BtlBw, ose duke dërguar më ngadalë për të kontrolluar për një ulje të RTprop. Frekuenca, shtrirja, kohëzgjatja dhe struktura e këtyre eksperimenteve ndryshojnë në varësi të asaj që dihet tashmë (fillimi i lidhjes ose gjendja e qëndrueshme) dhe nga sjellja e aplikacionit që dërgon të dhëna (me ndërprerje ose të vazhdueshme).

Gjendje e qëndrueshme

Rrjedhat BBR kalojnë shumicën e kohës në gjendjen ProbeBW, duke hetuar brezin duke përdorur një metodë të quajtur fitojnë çiklizmit Kjo i ndihmon transmetimet BBR të arrijnë xhiro të lartë, vonesë të ulët në radhë dhe konvergjencë të drejtë të ndarjes. Duke përdorur fitojnë çiklizmit BBR provon në mënyrë ciklike një sërë vlerash për fitimin pacing_gain... Përdoren tetë faza të ciklit me vlerat e mëposhtme: 5/4, 3/4, 1, 1, 1, 1, 1, 1. Çdo fazë zakonisht zgjat për RTprop-in e parashikuar. Ky dizajn lejon ciklin e koeficientit që së pari të hetojë kanalin për një gjerësi bande më të lartë me një vlerë pacing_gain më i madh se 1.0, dhe më pas shpërndani çdo radhë që rezulton me pacing_gain me të njëjtën sasi më pak se 1.0, dhe më pas lëvizni me shpejtësi lundrimi me një shpërthim të shkurtër koeficientësh saktësisht 1.0. Fitimi mesatar për të gjitha fazat është 1.0 sepse ProbeBW tenton të arrijë mesataren për të barazuar gjerësinë e brezit të disponueshëm dhe për këtë arsye ruan përdorimin e lartë të gjerësisë së brezit pa rritur radhën. Vini re se edhe pse ciklet e raportit ndryshojnë pacing_gain por vlera cwnd_gain mbetet gjithmonë e barabartë me dy, pasi paketat ack të vonuara dhe të zgjatura mund të shfaqen në çdo kohë (shih kapitullin mbi paketat e vonuara dhe të zgjatura të ack).

Për më tepër, për të përmirësuar përzierjen e rrjedhës dhe ndarjen e drejtë të gjerësisë së brezit, dhe për të reduktuar radhët kur shumë BBR ndajnë një pengesë, BBR ndryshon rastësisht fazat e ciklit ProbeBW, duke zgjedhur në mënyrë të rastësishme fazën e parë nga të gjitha, përveç 3/4. Pse cikli nuk fillon me 3/4? Qëllimi kryesor i kësaj vlere raporti është të shpërndajë çdo radhë që mund të krijohet gjatë aplikimit të raportit 5/4, kur kanali është tashmë plot. Kur një proces del nga gjendja Drain ose ProbeRTT dhe hyn në ProbeBW, nuk ka radhë, kështu që faktori 3/4 nuk po bën punën e tij. Përdorimi i 3/4 në një kontekst të tillë ka vetëm një efekt negativ: mbushja e kanalit në këtë fazë do të jetë 3/4, jo 1. Kështu, fillimi i ciklit nga 3/4 ka vetëm një efekt negativ. por nuk ka efekt pozitiv, dhe meqenëse hyrja në gjendjen ProbeBW kërkon një kohë mjaft të gjatë në fillimin e çdo lidhjeje, atëherë BBR përdor këtë optimizim të vogël.

Fijet BBR punojnë së bashku për të zbrazur periodikisht radhën e bllokut duke përdorur një gjendje të quajtur ProbeRTT. Në çdo gjendje tjetër përveç vetë ProbeRTT, nëse vlerësimi RTProp nuk është përditësuar (për shembull, duke matur një RTT më të ulët) për më shumë se 10 sekonda, atëherë BBR hyn në gjendjen ProbeRTT dhe ul cwnd në një vlerë shumë të vogël (katër pako ). Duke mbajtur një numër të tillë minimal paketash gjatë fluturimit prej të paktën 200 ms dhe për një kohë kalimi të dyfishtë me shpërthim, BBR del nga gjendja ProbeRTT dhe hyn në Startup ose ProbeBW, në varësi të faktit nëse kanali është tashmë i mbushur apo jo.

BBR është projektuar për të operuar shumicën e kohës (rreth 98%) në gjendjen ProbeBW dhe pjesën tjetër të kohës në ProbeRTT, bazuar në një grup kompensimesh. Gjendja ProbeRTT zgjat mjaftueshëm (të paktën 200 ms) për të lejuar që temat me RTT të ndryshme të kenë gjendje ProbeRTT të njëkohshme, por në të njëjtën kohë zgjat një kohë mjaft të shkurtër për të kufizuar degradimin e performancës në rreth dy përqind (200 ms / 10 sekonda ). Dritarja e filtrit RTprop (10 sekonda) është mjaft e vogël për të akomoduar shpejt ndryshimet në nivelet e trafikut ose ridrejtimin, por mjaft e madhe për aplikacione ndërvepruese. Aplikacione të tilla (për shembull, faqet e internetit, thirrjet e procedurave në distancë, videoklipet) shpesh shfaqin periudha të natyrshme heshtjeje ose aktiviteti të ulët në dritaret e kësaj dritareje, ku shpejtësia e rrjedhës është mjaft e ngadaltë ose mjaft e gjatë për të shpërndarë radhën në një pengesë. Filtri RTprop më pas i rregullon në mënyrë oportuniste këto matje RTprop dhe RTProp përditësohet pa pasur nevojë të përdoret ProbeRTT. Kështu, transmetimet zakonisht duhet të sakrifikojnë vetëm 2% të gjerësisë së brezit nëse transmetime të shumta mbushin kanalin me bollëk në një dritare të tërë RTProp.

Sjellja e fillimit

Kur fillon një fill BBR, ai kryen procesin e parë (dhe më të shpejtë) sekuencial të kërkimit / zbrazjes së radhës. Gjerësia e brezit të rrjetit ndryshon në intervalin 10 12 - nga disa bit në 100 gigabit për sekondë. Për të kuptuar vlerën e BtlBw për një ndryshim kaq gjigant të diapazonit, BBR kryen një kërkim binar në hapësirën e shpejtësisë. Ai gjen shumë shpejt BtlBw (kalime të dyfishta të paketave), por në kurriz të krijimit të një radhe në 2BDP në fazën e fundit të kërkimit. Kërkimi kryhet në gjendjen Startup në BBR, dhe zbrazja e radhës së krijuar kryhet në gjendjen Drain.

Së pari, Startup rrit në mënyrë eksponenciale shpejtësinë e dërgimit të të dhënave, duke e dyfishuar atë çdo raund. Për të arritur këtë ndjeshmëri të shpejtë në mënyrën më të relaksuar, kur filloni vlerat e fitimit pacing_gain dhe cwnd_gain janë vendosur në vlerën minimale që ju lejon të dyfishoni shpejtësinë e ngarkimit për çdo raund. Sapo kanali të jetë i mbushur, koeficienti cwnd_gain kufizon madhësinë e radhës në një vlerë.

Në gjendjen fillestare të lidhjes, BBR gjykon nëse kanali është plot duke kërkuar një pllajë në vlerësimin BtlBw. Nëse konstatohet se kanë kaluar disa (tre) raunde, ku përpjekjet për të dyfishuar shpejtësinë e dorëzimit realisht nuk japin një rritje të madhe të shpejtësisë (më pak se 25%), atëherë ai konsideron se ka arritur BtlBw, kështu që del nga Startup. gjendjen dhe hyn në gjendjen Drain. BBR pret tre raunde për të marrë prova bindëse se rrafshnalta e normës së dërgesës së vëzhguar nga dërguesi nuk është një efekt kalimtar për shkak të dritares së marrjes. Pritja për tre raunde jep kohë të mjaftueshme për sintonizimin automatik nga ana e marrësit për të hapur dritaren marrëse dhe që dërguesi nga BBR të zbulojë nevojën për të rritur BtlBw: në raundin e parë, algoritmi për rregullimin automatik të dritares marrëse rrit dritaren e marrjes. ; në raundin e dytë, dërguesi plotëson dritaren e zmadhuar të pritjes; në raundin e tretë, dërguesi merr mostra me një shpejtësi të shtuar të dorëzimit. Ky kufi me tre raunde e ka provuar veten në zbatimin e YouTube.

Në gjendjen Drain, algoritmi BBR kërkon të zbrazë shpejt radhën që u formua në gjendjen e fillimit të lidhjes duke kaluar në pacing_gain me vlera të kundërta nga ato të përdorura në gjendjen e fillimit. Kur numri i paketave gjatë fluturimit përputhet me vlerësimin e BDP-së, kjo do të thotë që BBR e konsideron radhën të jetë plotësisht bosh, por kanali është ende plot. Pastaj BBR largohet nga gjendja Drain dhe hyn në ProbeBW.

Vini re se fillimi i një lidhjeje BBR dhe një CUBIC me nisje të ngadaltë të dyja mësojnë xhiron e ngushta në mënyrë eksponenciale, duke dyfishuar shkallën e dërgimit në çdo raund. Megjithatë, ato janë thelbësisht të ndryshme. Së pari, BBR është më i besueshëm në përcaktimin e gjerësisë së brezit të disponueshëm, pasi nuk ndalon kërkimin në rast të humbjes së paketës ose (si Hystart i CUBIC) në rritje të vonesës. Së dyti, BBR rrit gradualisht shpejtësinë e dërgimit, ndërsa CUBIC ka një breshëri paketash në çdo raund (madje edhe me ritmin), dhe më pas një periudhë heshtjeje. Figura 4 tregon numrin e paketave në fluturim dhe vëzhgon RTT për çdo mesazh konfirmimi nga BBR dhe CUBIC.

Reagimi ndaj situatave kalimtare

Rruga e rrjetit dhe fluksi i trafikut përgjatë tij mund të pësojnë ndryshime të papritura dramatike. Për t'u përshtatur pa probleme dhe me besueshmëri me to, si dhe për të zvogëluar humbjen e paketave në këto situata, BBR përdor një sërë strategjish për të zbatuar modelin e saj bazë. Së pari, BBR e konsideron si objektivin në të cilin rryma cwnd afrohet me kujdes nga poshtë, duke u rritur cwndçdo herë jo më shumë se sasia e të dhënave për të cilat është marrë konfirmimi i dorëzimit. Së dyti, me një afat të ritransmetimit, që do të thotë se dërguesi i konsideron të gjitha paketat në fluturim si të humbura, BBR redukton në mënyrë konservative cwnd deri në një pako dhe dërgon një paketë të vetme (ashtu si algoritmet e kontrollit të kongjestionit të humbjes së paketave si CUBIC). Në fund të fundit, kur dërguesi vëren se një paketë ka humbur, por ka ende paketa në fluturim, në hapin e parë të procesit të rikuperimit të humbjeve, BBR ul përkohësisht shkallën e dërgimit në nivelin e shkallës aktuale të dërgesës; në raundin e dytë dhe të mëpasshëm të rikuperimit të humbjeve, ai verifikon që norma e dërgimit nuk e kalon kurrë më shumë se dyfishin e normës aktuale të dorëzimit. Kjo redukton ndjeshëm humbjet kalimtare kur BBR ndeshet me kufizues të shpejtësisë ose konkurron me rryma të tjera në një tampon të madhësisë së BDP-së.

Lidhjet

1. Abrahamsson, M. 2015. Shtypja e TCP ACK. Lista e postimeve IETF AQM;