Software-ul open source a devenit un element de bază în crearea unora dintre cele mai mari site-uri web din lume. Odată cu creșterea acestor site-uri web, au apărut cele mai bune practici și linii directoare pentru arhitectura lor. Acest capitol își propune să acopere câteva dintre aspectele cheie de luat în considerare atunci când proiectați site-uri web mari, precum și câteva dintre componentele de bază utilizate pentru atingerea acestor obiective.

Accentul acestui capitol este pe analiza sistemelor bazate pe web, deși o parte din material poate fi extrapolată la alte sisteme distribuite.

1.1 Principii de construire a sistemelor web distribuite

Ce înseamnă exact să creezi și să gestionezi un site web sau o aplicație scalabilă? La un nivel primitiv, este pur și simplu conectarea utilizatorilor la resurse de la distanță prin Internet. Și resurse sau acces la aceste resurse, care sunt distribuite pe mai multe servere și sunt linkul care asigură scalabilitatea site-ului.

La fel ca majoritatea lucrurilor din viață, timpul petrecut în avans pentru planificarea construirii unui serviciu web poate ajuta mai târziu; Înțelegerea unora dintre considerentele și compromisurile din spatele site-urilor web mari poate aduce decizii mai inteligente atunci când construiți site-uri web mai mici. Mai jos sunt câteva principii cheie care influențează proiectarea sistemelor web la scară largă:

• Disponibilitate: Durata de funcționare a site-ului este esențială pentru reputația și funcționalitatea multor companii. Pentru unii comercianți online mai mari, indisponibilitatea chiar și pentru câteva minute poate duce la pierderi de venituri de mii sau milioane de dolari. Astfel, dezvoltarea sistemelor lor pentru a fi întotdeauna disponibile și rezistente la eșec este atât o cerință fundamentală de afaceri, cât și de tehnologie. Disponibilitatea ridicată în sistemele distribuite necesită o luare în considerare atentă a redundanței componentelor cheie, recuperarea rapidă după defecțiuni parțiale ale sistemului și reducerea fără probleme a capabilităților atunci când apar probleme.
• Performanţă: Performanța site-urilor web a devenit o măsură importantă pentru majoritatea site-urilor web. Viteza site-ului are un impact asupra experienței și satisfacției utilizatorilor, precum și a clasamentului în motoarele de căutare – un factor care afectează direct retenția publicului și veniturile. Ca rezultat, cheia este de a crea un sistem care este optimizat pentru răspunsuri rapide și latență scăzută.
• Fiabilitate: sistemul trebuie să fie fiabil astfel încât o cerere de date dată să returneze în mod constant date specificate. În cazul modificării sau actualizării datelor, aceeași solicitare ar trebui să returneze date noi. Utilizatorii trebuie să știe că, dacă ceva este înregistrat sau stocat în sistem, pot fi încrezători că va rămâne pe loc pentru recuperarea ulterioară.
• Scalabilitate: Când vine vorba de orice sistem distribuit mare, dimensiunea este doar un element dintr-o listă care trebuie luat în considerare. La fel de importante sunt eforturile de a crește debitul pentru a gestiona volume mari de sarcină de lucru, care este de obicei denumită scalabilitate a sistemului. Scalabilitatea se poate referi la diferiți parametri ai unui sistem: cantitatea de trafic suplimentar pe care îl poate gestiona, cât de ușor este să adăugați capacitate de stocare sau cât de multe alte tranzacții pot fi procesate.
• Controlabilitate: Proiectarea unui sistem care este ușor de operat este un alt factor important. Gestionabilitatea sistemului echivalează cu scalabilitatea operațiunilor de „întreținere” și „actualizare”. Pentru a asigura gestionabilitatea, este necesar să se ia în considerare ușurința de diagnosticare și înțelegere a problemelor emergente, ușurința de actualizare sau modificare și ușurința de utilizare a sistemului. (Adică funcționează așa cum era de așteptat, fără eșecuri sau excepții?)
• Preț: Costul este un factor important. Acest lucru poate include, evident, costurile hardware și software, dar este important să se ia în considerare și alte aspecte necesare pentru implementarea și întreținerea sistemului. Trebuie asigurat timpul necesar dezvoltatorului pentru a construi sistemul, cantitatea de efort operațional necesar pentru a pune sistemul în funcțiune și chiar și nivelul adecvat de instruire. Costul reprezintă costul total de proprietate.

Fiecare dintre aceste principii oferă o bază pentru luarea deciziilor în proiectarea unei arhitecturi web distribuite. Cu toate acestea, ele pot fi, de asemenea, în conflict între ele, deoarece atingerea obiectivelor unuia vine în detrimentul neglijării celuilalt. Un exemplu simplu: alegerea de a adăuga pur și simplu mai multe servere ca soluție de performanță (scalabilitate) poate crește costul de gestionare (trebuie să rulați un server suplimentar) și achizițiile de servere.

Atunci când dezvoltați orice fel de aplicație web, este important să luați în considerare aceste principii cheie, chiar dacă este pentru a confirma că proiectul poate sacrifica unul sau mai multe dintre ele.

1.2 Elemente de bază

Când luăm în considerare arhitectura sistemului, există mai multe probleme care trebuie abordate, cum ar fi ce componente merită folosite, cum se potrivesc împreună și ce compromisuri pot fi făcute. Investirea banilor în extindere fără o nevoie clară de aceasta nu este o decizie de afaceri inteligentă. Cu toate acestea, o anumită gândire în planificare poate economisi timp și resurse semnificative în viitor.

Această secțiune se concentrează pe câțiva factori de bază care sunt critici pentru aproape toate aplicațiile web mari: Servicii,
redundanţă, segmentare, Și tratarea eșecului. Fiecare dintre acești factori implică alegeri și compromisuri, mai ales în contextul principiilor descrise în secțiunea anterioară. Pentru a clarifica, hai sa dam un exemplu.

Exemplu: Aplicație de găzduire a imaginilor

Probabil ați mai postat imagini online. Pentru site-urile mari care stochează și livrează multe imagini, există provocări în crearea unei arhitecturi rentabile, extrem de fiabile, care are latențe scăzute de răspuns (recuperare rapidă).

Imaginați-vă un sistem în care utilizatorii au posibilitatea de a-și încărca imaginile pe un server central și în care imaginile pot fi solicitate printr-un link de site sau API, similar cu Flickr sau Picasa. Pentru a simplifica descrierea, să presupunem că această aplicație are două sarcini principale: capacitatea de a încărca (scrie) imagini pe server și de a solicita imagini. Desigur, încărcarea eficientă este un criteriu important, dar livrarea rapidă atunci când este solicitată de utilizatori (de exemplu, imaginile pot fi solicitate pentru afișare pe o pagină web sau de către o altă aplicație) va fi o prioritate. Această funcționalitate este similară cu ceea ce poate oferi un server web sau un server edge Content Delivery Network (CDN). Un server CDN stochează, de obicei, obiectele de date în mai multe locații, aducându-le astfel mai aproape geografic/fizic de utilizatori, rezultând performanțe îmbunătățite.

Alte aspecte importante ale sistemului:

• Numărul de imagini stocate poate fi nelimitat, astfel încât scalabilitatea stocării trebuie luată în considerare din acest punct de vedere.
• Ar trebui să existe o latență scăzută pentru descărcări/cereri de imagini.
• Dacă un utilizator încarcă o imagine pe server, datele acesteia trebuie să rămână întotdeauna intacte și accesibile.
• Sistemul trebuie să fie ușor de întreținut (gestionabilitate).
• Deoarece găzduirea imaginilor nu generează prea mult profit, sistemul trebuie să fie rentabil.

O altă problemă potențială a acestui design este că un server web precum Apache sau lighttpd are, de obicei, o limită superioară a numărului de conexiuni simultane pe care le poate deservi (valoarea implicită este de aproximativ 500, dar poate fi mult mai mare) și cu trafic ridicat. , înregistrările pot utiliza rapid această limită. Deoarece citirile pot fi asincrone sau pot profita de alte optimizări de performanță, cum ar fi compresia gzip sau chunking, serverul web poate comuta mai repede citirile de feed și poate comuta între clienți în timp ce deservește mult mai multe solicitări decât numărul maxim de conexiuni (cu Apache și cu un număr maxim de conexiuni setate la 500, este foarte posibil să deserviți câteva mii de solicitări de citire pe secundă). Înregistrările, pe de altă parte, tind să mențină conexiunea deschisă pe toată durata descărcării. Astfel, transferul unui fișier de 1 MB pe server ar putea dura mai mult de 1 secundă pe majoritatea rețelelor de acasă, ceea ce înseamnă că serverul web poate procesa doar 500 dintre aceste intrări simultane.

Figura 1.2: Separarea citire/scriere

Anticiparea acestei probleme potențiale sugerează necesitatea de a separa citirea și scrierea imaginilor în servicii independente, prezentate în . Acest lucru ne va permite nu numai să le extindem pe fiecare dintre ele individual (din moment ce este probabil să facem întotdeauna mai multe citiri decât scrieri), ci și să fim conștienți de ceea ce se întâmplă în fiecare serviciu. În cele din urmă, va diferenția problemele care pot apărea în viitor, facilitând diagnosticarea și evaluarea problemei accesului lent la citire.

Avantajul acestei abordări este că suntem capabili să rezolvăm probleme independent unul de celălalt - fără a fi nevoie să ne facem griji cu privire la înregistrarea și preluarea de noi imagini în același context. Ambele servicii încă folosesc un corpus global de imagini, dar prin utilizarea tehnicilor specifice serviciului, ele sunt capabile să își optimizeze propria performanță (de exemplu, prin punerea în așteptare a cererilor sau prin memorarea în cache a imaginilor populare - mai multe despre asta mai târziu). Atât din perspectiva serviciilor, cât și a costurilor, fiecare serviciu poate fi scalat independent, după cum este necesar. Și acesta este un lucru pozitiv, deoarece combinarea și amestecarea acestora le-ar putea afecta din neatenție performanța, ca în scenariul descris mai sus.

Desigur, modelul de mai sus va funcționa optim dacă există două puncte finale diferite (de fapt, acesta este foarte asemănător cu mai multe implementări ale furnizorilor de stocare în cloud și ale rețelelor de livrare de conținut). Există multe modalități de a rezolva astfel de probleme și în fiecare caz se poate găsi un compromis.

De exemplu, Flickr rezolvă această problemă de citire-scriere prin distribuirea utilizatorilor în diferite poduri, astfel încât fiecare pod să poată servi doar un număr limitat de utilizatori anumiți și, pe măsură ce numărul de utilizatori crește, mai multe poduri sunt adăugate la cluster (consultați prezentarea de scalare a Flickr ,
http://mysqldba.blogspot.com/2008/04/mysql-uc-2007-presentation-file.html). În primul exemplu, este mai ușor să scalați hardware-ul în funcție de sarcina reală de utilizare (numărul de citiri și scrieri în întregul sistem), în timp ce Flickr se scalează pe baza bazei de utilizatori (cu toate acestea, aceasta presupune o utilizare egală între utilizatori, deci capacitatea trebuie planificat în funcție de stoc). În trecut, o indisponibilitate sau o problemă cu unul dintre servicii ar sparge funcționalitatea întregului sistem (de exemplu, nimeni nu putea scrie fișiere), apoi indisponibilitatea unuia dintre modulele Flickr ar afecta doar utilizatorii asociați acestuia. În primul exemplu, este mai ușor să efectuați operațiuni pe întregul set de date - de exemplu, actualizarea serviciului de înregistrare pentru a include metadate noi sau căutarea tuturor metadatelor imaginii - în timp ce cu arhitectura Flickr, fiecare modul trebuia actualizat sau căutat ( sau a trebuit creat serviciul de căutare pentru a sorta metadatele care sunt de fapt destinate acestui scop).

În ceea ce privește aceste sisteme, nu există panaceu, dar ar trebui să porniți întotdeauna de la principiile descrise la începutul acestui capitol: determinați nevoile sistemului (sarcină de citire sau scriere sau ambele, nivel de paralelism, interogări pe seturi de date, intervale, sortare, etc.), să efectueze teste comparative de referință ale diferitelor alternative, să înțeleagă condițiile potențiale de defecțiune a sistemului și să elaboreze un plan cuprinzător în cazul în care apare o defecțiune.

Redundanţă

Pentru a gestiona cu grație eșecul, arhitectura web trebuie să aibă redundanță în serviciile și datele sale. De exemplu, dacă există o singură copie a unui fișier stocată pe un singur server, pierderea acelui server va însemna pierderea fișierului. Este puțin probabil să fie o situație pozitivă și, de obicei, poate fi evitată prin crearea mai multor copii sau copii de rezervă.

Același principiu se aplică serviciilor. Vă puteți proteja împotriva defecțiunii unui singur nod oferind o parte integrantă a funcționalității aplicației, pentru a vă asigura că mai multe copii sau versiuni ale acesteia pot rula simultan.

Crearea redundanței în sistem vă permite să scăpați de punctele slabe și să oferiți funcționalități de rezervă sau redundante în caz de urgență. De exemplu, dacă există două instanțe ale aceluiași serviciu care rulează în producție și una dintre ele eșuează complet sau parțial, sistemul poate depăși eșecul prin trecerea la o copie de lucru.
Comutarea poate avea loc automat sau poate necesita intervenție manuală.

Un alt rol cheie al redundanței serviciului este de a crea arhitectură care nu prevede partajarea resurselor. Cu această arhitectură, fiecare nod este capabil să opereze independent și, mai mult, în absența unui „creier” central care să gestioneze stările sau să coordoneze acțiunile altor noduri. Promovează scalabilitatea deoarece adăugarea de noi noduri nu necesită condiții sau cunoștințe speciale. Și, cel mai important, nu există niciun punct critic de defecțiune în aceste sisteme, ceea ce le face mult mai rezistente la defecțiuni.

De exemplu, în aplicația noastră de server de imagini, toate imaginile ar avea copii redundante undeva într-o altă piesă hardware (în mod ideal, într-o locație geografică diferită în cazul unui dezastru, cum ar fi un cutremur sau un incendiu în centrul de date), iar serviciile ar accesa imaginile vor fi redundante, având în vedere că toate vor putea servi cererile. (Cm. .)
Privind în viitor, balansoarele de încărcare sunt o modalitate excelentă de a face acest lucru posibil, dar mai multe despre asta mai jos.

Figura 1.3: Aplicație redundantă de găzduire a imaginilor

Segmentarea

Seturile de date pot fi atât de mari încât nu pot fi găzduite pe un singur server. De asemenea, se poate întâmpla ca operațiunile de calcul să necesite prea multe resurse computerizate, reducând performanța și necesitând o putere crescută. În orice caz, aveți două opțiuni: scalare verticală sau orizontală.

Scalare verticală implică adăugarea mai multor resurse la un singur server. Deci, pentru un set de date foarte mare, aceasta ar însemna adăugarea mai multor hard disk-uri (sau mai mari), astfel încât întregul set de date să poată încadra pe un singur server. În cazul operațiunilor de calcul, aceasta ar însemna mutarea calculului pe un server mai mare, cu un procesor mai rapid sau mai multă memorie. În orice caz, scalarea verticală se face pentru a face o singură resursă de sistem de calcul capabilă de procesare suplimentară a datelor.

Scalare orizontală, pe de altă parte, implică adăugarea mai multor noduri. În cazul unui set mare de date, aceasta ar însemna adăugarea unui al doilea server pentru a stoca o parte din volumul total de date, iar pentru o resursă de calcul, aceasta ar însemna împărțirea muncii sau a încărcăturii pe câteva noduri suplimentare. Pentru a profita din plin de potențialul de scalare orizontală, aceasta trebuie implementată ca principiu de proiectare intern al arhitecturii sistemului. În caz contrar, schimbarea și izolarea contextului necesar pentru scalarea orizontală poate fi problematică.

Cea mai comună metodă de scalare orizontală este împărțirea serviciilor în segmente sau module. Ele pot fi distribuite în așa fel încât fiecare set logic de funcționalități să funcționeze separat. Acest lucru se poate face în funcție de limitele geografice sau de alte criterii, cum ar fi utilizatorii plătitori și neplătitori. Avantajul acestor scheme este că oferă un serviciu sau un depozit de date cu funcționalitate îmbunătățită.

În exemplul nostru de server de imagini, este posibil ca un singur server de fișiere folosit pentru a stoca imaginea să fie înlocuit cu mai multe servere de fișiere, fiecare conținând propriul set unic de imagini. (Vezi.) Această arhitectură ar permite sistemului să umple fiecare server de fișiere cu imagini, adăugând servere suplimentare pe măsură ce spațiul pe disc devine plin. Designul va necesita o schemă de denumire care asociază numele fișierului imagine cu serverul care îl conține. Numele imaginii poate fi generat dintr-o schemă de hashing consecventă legată de servere. Sau, alternativ, fiecare imagine ar putea avea un ID incremental, care ar permite serviciului de livrare, atunci când solicită o imagine, să proceseze doar gama de ID-uri asociate fiecărui server (ca index).

Figura 1.4: Aplicație de găzduire a imaginilor cu redundanță și segmentare

Desigur, există dificultăți în distribuirea datelor sau a funcționalității pe multe servere. Una dintre întrebările cheie este locația datelor; În sistemele distribuite, cu cât datele sunt mai aproape de punctul de operare sau de calcul, cu atât performanța sistemului este mai bună. În consecință, distribuirea datelor pe mai multe servere este potențial problematică, deoarece în orice moment datele pot fi necesare, există riscul ca acestea să nu fie disponibile în locația dorită, serverul va trebui să efectueze o recuperare costisitoare a informațiilor necesare peste rețeaua.

O altă problemă potențială apare în formă
inconsecvență (incoerență) Atunci când diferite servicii citesc și scriu într-o resursă partajată, eventual un alt serviciu sau un depozit de date, este posibil să apară o „condiție de cursă” - unde se crede că unele date sunt actualizate la cea mai recentă stare, dar sunt de fapt citite înainte de a fi actualizat - caz în care datele sunt inconsecvente. De exemplu, într-un scenariu de găzduire a imaginilor, poate apărea o condiție de cursă dacă un client a trimis o solicitare de actualizare a unei imagini a unui câine, schimbând titlul „Câine” în „Gizmo” în timp ce un alt client citea imaginea. Într-o astfel de situație, nu este clar ce titlu, „Câine” sau „Gizmo”, ar fi primit al doilea client.

Există, desigur, unele obstacole asociate cu segmentarea datelor, dar segmentarea vă permite să izolați fiecare problemă de celelalte: după date, după încărcare, după modele de utilizare etc. în blocuri gestionate. Acest lucru poate ajuta la scalabilitate și gestionabilitate, dar există totuși riscuri. Există multe modalități de a reduce riscul și de a gestiona eșecurile; cu toate acestea, din motive de concizie, acestea nu sunt tratate în acest capitol. Dacă doriți mai multe informații despre acest subiect, ar trebui să aruncați o privire la postarea de blog despre toleranța la erori și monitorizarea.

1.3. Elemente de bază pentru acces rapid și scalabil la date

După ce am analizat câteva principii de bază în dezvoltarea sistemelor distribuite, să trecem acum la o problemă mai complexă - scalarea accesului la date.

Cele mai simple aplicații web, cum ar fi aplicațiile LAMP stack, sunt similare cu imaginea din .

Figura 1.5: Aplicații web simple

Pe măsură ce o aplicație crește, apar două provocări principale: scalarea accesului la serverul de aplicații și la baza de date. Într-un design de aplicație extrem de scalabil, serverul web sau de aplicații este de obicei minimizat și adesea implementează o arhitectură de partajare a resurselor. Acest lucru face ca stratul de server de aplicații al sistemului să fie scalabil pe orizontală. Ca rezultat al acestui design, sarcinile grele vor muta în jos stiva către serverul de baze de date și serviciile de asistență; Acest strat este locul în care intră în joc problemele reale de scalare și performanță.

Restul acestui capitol acoperă unele dintre cele mai comune strategii și tehnici pentru îmbunătățirea performanței și scalabilității acestor tipuri de servicii prin furnizarea de acces rapid la date.

Figura 1.6: Aplicație web simplificată

Majoritatea sistemelor pot fi simplificate la un circuit în
care este un loc bun pentru a începe să cauți. Dacă aveți o mulțime de date, este sigur să presupuneți că doriți să fie la fel de ușor și rapid de accesat ca și cutia de bomboane din sertarul de sus al biroului. Deși această comparație este prea simplistă, evidențiază două probleme complexe: scalabilitatea stocării datelor și accesul rapid la date.

În scopul acestei secțiuni, să presupunem că aveți mulți teraocteți (TB) de date și le permiteți utilizatorilor să acceseze porțiuni mici din acele date în ordine aleatorie. (Cm. .)
O sarcină similară este de a determina locația unui fișier imagine undeva pe un server de fișiere într-un exemplu de aplicație de găzduire a imaginilor.

Figura 1.7: Acces la date specifice

Acest lucru este deosebit de dificil deoarece încărcarea terabytelor de date în memorie poate fi foarte costisitoare și are un impact direct asupra I/O-ului pe disc. Viteza de citire de pe un disc este de câteva ori mai mică decât viteza de citire de pe RAM - putem spune că accesarea memoriei este la fel de rapidă ca Chuck Norris, în timp ce accesarea unui disc este mai lentă decât coada de la clinică. Această diferență de viteză este vizibilă în special pentru seturi mari de date; În numere brute, accesul la memorie este de 6 ori mai rapid decât citirile pe disc pentru citirile secvențiale și de 100.000 de ori mai rapid pentru citirile aleatorii (vezi Pathologies of Big Data, http://queue.acm.org/detail. cfm?id=1563874). ). Mai mult decât atât, chiar și cu identificatori unici, rezolvarea problemei de a localiza o mică bucată de date poate fi la fel de dificilă precum încercarea de a alege ultima bomboană umplută cu ciocolată dintr-o cutie cu sute de alte bomboane fără să te uiți.

Din fericire, există multe abordări care pot fi luate pentru a simplifica lucrurile, cele mai importante patru abordări fiind utilizarea cache-urilor, proxy-urilor, indexurilor și echilibratorilor de încărcare. Restul acestei secțiuni discută modul în care fiecare dintre aceste concepte poate fi utilizat pentru a face accesul la date mult mai rapid.

Cache-urile

Memorarea în cache beneficiază de o caracteristică a principiului de bază: datele solicitate recent este probabil să fie din nou necesare. Cache-urile sunt folosite la aproape toate nivelurile de calcul: hardware, sisteme de operare, browsere web, aplicații web și multe altele. Un cache este ca memoria pe termen scurt: limitat ca dimensiune, dar mai rapid decât sursa de date originală și conține elemente care au fost accesate recent. Cache-urile pot exista la toate nivelurile din arhitectură, dar sunt adesea găsite la nivelul cel mai apropiat de front end, unde sunt implementate pentru a returna datele rapid, fără încărcare semnificativă a backend-ului.

Deci, cum poate fi folosit un cache pentru a accelera accesul la date în exemplul nostru de API? În acest caz, există mai multe locații cache adecvate. O posibilă opțiune de plasare este selectarea nodurilor la nivel de interogare, așa cum se arată în
.

Figura 1.8: Plasarea în cache pe un nod la nivel de interogare

Plasarea cache-ului direct pe nodul la nivel de cerere permite stocarea locală a datelor de răspuns. De fiecare dată când se face o solicitare de serviciu, nodul va returna rapid date locale, stocate în cache, dacă există. Dacă nu este în cache, nodul de solicitare va solicita datele de pe disc. Cache-ul de pe un singur nod la nivel de interogare ar putea fi, de asemenea, localizat fie în memorie (care este foarte rapidă), fie pe discul local al nodului (mai rapid decât încercarea de a accesa stocarea în rețea).

Figura 1.9: Sisteme de cache

Ce se întâmplă când distribuiți memoria cache pe mai multe noduri? După cum puteți vedea, dacă nivelul de solicitare include multe noduri, atunci este probabil ca fiecare nod să aibă propriul cache. Cu toate acestea, dacă echilibratorul dvs. de încărcare distribuie aleatoriu solicitările între noduri, atunci aceeași solicitare va merge la diferite noduri, crescând astfel ratele de cache. Două moduri de a depăși acest obstacol sunt cache-urile globale și distribuite.

Cache global

Semnificația unui cache global este clar din nume: toate nodurile împărtășesc un singur spațiu cache. În acest caz, adăugați un server sau stocare de fișiere de un fel care este mai rapid decât spațiul de stocare original și care va fi disponibil pentru toate nodurile la nivel de solicitare. Fiecare dintre nodurile de solicitare interogează memoria cache în același mod ca și cum ar fi local. Acest tip de schemă de stocare în cache poate cauza unele probleme, deoarece un singur cache poate fi foarte ușor supraîncărcat dacă numărul de clienți și cereri crește. În același timp, această schemă este foarte eficientă pe anumite arhitecturi (în special cele asociate cu hardware specializat care face ca acest cache global să fie foarte rapid, sau care are un set fix de date care trebuie să fie stocat în cache).

Există două forme standard de cache globale prezentate în diagrame. Situația arătată este că atunci când răspunsul din cache nu este găsit în cache, memoria cache în sine devine responsabilă pentru recuperarea părții lipsă a datelor din stocarea de bază. Ilustrat este responsabilitatea nodurilor de solicitare de a prelua orice date care nu se găsesc în cache.

Figura 1.10: Cache-ul global, unde memoria cache este responsabilă pentru recuperare

Figura 1.11: Cache global, unde nodurile de solicitare sunt responsabile pentru extragere

Majoritatea aplicațiilor care folosesc cache-urile globale tind să folosească primul tip, unde memoria cache în sine gestionează înlocuirea și preluarea datelor pentru a preveni clienții să inunde cererile pentru aceleași date. Cu toate acestea, există unele cazuri în care a doua implementare are mai mult sens. De exemplu, dacă memoria cache este utilizată pentru fișiere foarte mari, o rată scăzută de accesare a memoriei cache va face ca cache-ul tampon să devină supraîncărcat cu erori de cache; în această situație ajută să aveți un procent mare din setul total de date (sau setul de date fierbinte) în cache. Un alt exemplu este o arhitectură în care fișierele stocate în cache sunt statice și nu trebuie șterse. (Acest lucru se poate întâmpla din cauza caracteristicilor de performanță subiacente referitoare la o astfel de latență a datelor - poate că anumite părți ale datelor trebuie să fie foarte rapide pentru seturi mari de date - în care logica aplicației înțelege strategia de înlocuire sau hotspot-urile mai bine decât memoria cache.)

Cache distribuită

Acești indecși sunt adesea stocați în memorie sau undeva foarte local la cererea clientului primit. Berkeley DB (BDB) și structurile de date arborescente, care sunt utilizate de obicei pentru a stoca date în liste ordonate, sunt ideale pentru accesul indexat.

Există adesea multe straturi de indici care acționează ca o hartă, deplasându-vă dintr-o locație în alta și așa mai departe, până când aveți datele de care aveți nevoie. (Cm. )

Figura 1.17: Indici multinivel

Indecșii pot fi, de asemenea, utilizați pentru a crea mai multe alte vizualizări ale acelorași date. Pentru seturi mari de date, aceasta este o modalitate excelentă de a defini filtre și vizualizări diferite fără a fi nevoie să creați multe copii suplimentare ale datelor.

De exemplu, să presupunem că sistemul de găzduire a imaginilor menționat mai sus găzduiește de fapt imagini ale paginilor cărților, iar serviciul permite clienților să interogheze textul din acele imagini, căutând tot conținutul text pe un anumit subiect în același mod în care îți permit motoarele de căutare. pentru a căuta HTML.conținut. În acest caz, toate aceste imagini de cărți folosesc atât de multe servere pentru a stoca fișiere, iar găsirea unei singure pagini pe care să o prezinte utilizatorului poate fi destul de dificilă. Inițial, indexurile inverse pentru interogarea cuvintelor arbitrare și seturi de cuvinte ar trebui să fie ușor disponibile; apoi există sarcina de a naviga la pagina și locația exactă din acea carte și de a prelua imaginea corectă pentru rezultatele căutării. Deci, în acest caz, indexul inversat s-ar mapa la locație (cum ar fi cartea B), iar apoi B ar putea conține indexul cu toate cuvintele, locațiile și numărul de apariții din fiecare parte.

Un index inversat, pe care Index1 l-ar putea afișa în diagrama de mai sus, ar arăta cam așa: Fiecare cuvânt sau set de cuvinte servește ca index pentru acele cărți care le conțin.

Indexul intermediar va arăta similar, dar va conține doar cuvintele, locația și informațiile pentru cartea B. Această arhitectură stratificată permite fiecărui index să ocupe mai puțin spațiu decât dacă toate aceste informații ar fi stocate într-un index mare inversat.

Și acesta este un punct cheie în sistemele la scară largă, deoarece chiar și atunci când sunt comprimați, acești indici pot fi destul de mari și costisitoare de stocat. Să presupunem că avem multe cărți din toată lumea în acest sistem - 100.000.000 (vezi postarea de blog „În interiorul cărților Google”) - și că fiecare carte are doar 10 pagini (pentru a simplifica calculele) cu 250 de cuvinte pe pagină: Aceasta oferă ne un total de 250 de miliarde de cuvinte. Dacă luăm că numărul mediu de caractere dintr-un cuvânt este 5 și codificăm fiecare caracter cu 8 biți (sau 1 octet, chiar dacă unele caractere ocupă de fapt 2 octeți), cheltuind astfel 5 octeți pe cuvânt, atunci indexul care îi conține pe fiecare Cuvântul o singură dată ar necesita mai mult de 1 terabyte de stocare. Așadar, puteți vedea că indexurile care conțin și alte informații, cum ar fi seturile de cuvinte, locațiile de date și numărul de utilizare, pot crește în dimensiune foarte rapid.

Crearea unor astfel de indici intermediari și prezentarea datelor în bucăți mai mici face ca problema datelor mari să fie mai ușor de rezolvat. Datele pot fi distribuite pe mai multe servere și, în același timp, pot fi accesibile rapid. Indexurile sunt piatra de temelie a regăsării informațiilor și baza pentru motoarele de căutare moderne de astăzi. Desigur, această secțiune doar zgârie suprafața subiectului de indexare și au existat o mulțime de cercetări despre cum să faci indici mai mici, mai rapid, să conțină mai multe informații (cum ar fi relevanța) și să fie ușor de actualizat. (Există unele probleme legate de gestionarea condițiilor concurente, precum și de numărul de actualizări necesare pentru a adăuga date noi sau a modifica datele existente, mai ales atunci când este vorba de relevanță sau punctaj).

Este important să vă găsiți datele rapid și ușor, iar indexurile sunt cel mai simplu și mai eficient instrument pentru atingerea acestui obiectiv.

Echilibratoare de sarcină

În cele din urmă, o altă parte critică a oricărui sistem distribuit este echilibrul de încărcare. Echilibratoarele de încărcare sunt o parte esențială a oricărei arhitecturi, deoarece rolul lor este de a distribui sarcina între nodurile responsabile cu deservirea cererilor. Acest lucru permite ca mai multe noduri să servească în mod transparent aceeași funcție în sistem. (Vezi.) Scopul lor principal este să gestioneze multe conexiuni simultane și să direcționeze acele conexiuni către unul dintre nodurile solicitate, permițând sistemului să se scaleze prin simpla adăugare de noduri pentru a servi mai multe solicitări.

Figura 1.18: Load Balancer

Există mulți algoritmi diferiți pentru solicitările de service, inclusiv selecția aleatorie a nodurilor, round robin sau chiar selectarea nodurilor pe baza anumitor criterii, cum ar fi utilizarea CPU sau RAM. Echilibratoarele de sarcină pot fi implementate ca dispozitive hardware sau software. Printre instrumentele de echilibrare a încărcăturii software open source, HAProxy este cel mai utilizat.

Într-un sistem distribuit, echilibratoarele de încărcare sunt adesea amplasate la „marginea din față” a sistemului, astfel încât toate cererile primite trec direct prin ele. Este foarte probabil ca într-un sistem complex distribuit o solicitare să treacă prin mai multe balansoare, așa cum se arată în
.

Figura 1.19: Echilibratoare de sarcină multiple

La fel ca proxy-urile, unii echilibratori de încărcare pot, de asemenea, direcționa cererile diferit, în funcție de tipul de solicitare. Ele sunt cunoscute și sub numele de proxy inverse.

Gestionarea datelor specifice unei anumite sesiuni de utilizator este una dintre provocările atunci când se utilizează echilibratori de încărcare. Pe un site de comerț electronic, atunci când aveți un singur client, este foarte ușor să permiteți utilizatorilor să plaseze articole în coșul lor și să salveze conținutul între vizite (acest lucru este important deoarece probabilitatea de a vinde un articol crește semnificativ dacă, atunci când utilizatorul revine pe site, produsul este încă în coș). Cu toate acestea, dacă un utilizator este direcționat către un nod pentru prima sesiune și apoi către un alt nod la următoarea sa vizită, pot apărea inconsecvențe deoarece noul nod este posibil să nu cunoască conținutul coșului de cumpărături al utilizatorului respectiv. (Nu te-ai supăra dacă ai pune un pachet de Mountain Dew în cărucior și când te întorci nu e acolo?) O soluție ar putea fi să faci sesiunile „lipicioase” astfel încât utilizatorul să fie întotdeauna direcționat către același nod. Cu toate acestea, profitarea unor caracteristici de fiabilitate, cum ar fi failover-ul automat, va fi semnificativ dificilă. În acest caz, coșul utilizatorului va avea întotdeauna conținut, dar dacă nodul lor lipicios devine inaccesibil, atunci va fi necesară o abordare specială și presupunerea despre conținutul coșului nu va mai fi adevărată (deși sperăm că această presupunere nu va fi inclusă în aplicația). Desigur, această problemă poate fi rezolvată folosind alte strategii și instrumente, cum ar fi cele descrise în acest capitol, cum ar fi serviciile și multe altele (cum ar fi cache-urile browserului, cookie-urile și rescrierea URL-urilor).

Dacă sistemul are doar câteva noduri, atunci tehnici precum caruselul DNS vor fi probabil mai practice decât echilibratoarele de încărcare, care pot fi costisitoare și pot adăuga un strat inutil de complexitate sistemului. Desigur, în sistemele mari există tot felul de algoritmi diferiți de programare și echilibrare a sarcinii, inclusiv ceva la fel de simplu precum randomizarea sau caruselul, până la mecanisme mai complexe care țin cont de caracteristicile de performanță ale modelului de utilizare a sistemului. Toți acești algoritmi permit distribuirea traficului și a cererilor și pot oferi instrumente utile de fiabilitate, cum ar fi toleranța automată la erori sau eliminarea automată a unui nod eșuat (de exemplu, atunci când nu mai răspunde la solicitări). Cu toate acestea, aceste caracteristici avansate pot face diagnosticarea problemelor greoaie. De exemplu, în situații de încărcare mare, echilibratoarele de încărcare vor elimina nodurile care pot rula lent sau pot expira (din cauza unui val de solicitări), ceea ce va înrăutăți lucrurile pentru alte noduri. Monitorizarea extinsă este importantă în aceste cazuri, deoarece chiar dacă traficul și încărcarea generală a sistemului par să scadă (deoarece nodurile deservesc mai puține solicitări), nodurile individuale pot fi extinse la limitele lor.

Echilibratoarele de sarcină sunt o modalitate ușoară de a crește capacitatea sistemului. Ca și celelalte metode descrise în acest articol, joacă un rol esențial în arhitectura sistemului distribuit. Echilibratoarele de sarcină oferă, de asemenea, funcția critică de verificare a stării de sănătate a nodurilor. Dacă, în urma unei astfel de verificări, un nod nu răspunde sau este supraîncărcat, atunci acesta poate fi eliminat din pool-ul de procesare a cererilor și, datorită redundanței sistemului dvs., sarcina va fi redistribuită între nodurile de lucru rămase. .

Cozile

Până acum am analizat multe moduri de a citi rapid datele. În același timp, o altă parte importantă a scalării stratului de date este gestionarea eficientă a înregistrărilor. Când sistemele sunt simple și au sarcini minime de procesare și baze de date mici, scrierea poate fi rapid rapid. Cu toate acestea, în sistemele mai complexe, acest proces poate dura pe termen nelimitat. De exemplu, este posibil ca datele să fie scrise în mai multe locuri pe servere sau indici diferiți, sau sistemul poate fi pur și simplu sub încărcare mare. În cazurile în care scrierile, sau chiar orice sarcină, durează mult timp, obținerea performanței și a disponibilității necesită construirea asincroniei în sistem. O modalitate obișnuită de a face acest lucru este de a organiza o coadă de solicitări.

Figura 1.20: Cerere sincronă

Imaginați-vă un sistem în care fiecare client solicită o sarcină de service la distanță. Fiecare dintre acești clienți își trimite cererea către server, care efectuează sarcinile cât mai repede posibil și returnează rezultatele acestora clienților corespunzători. În sistemele mici în care un singur server (sau serviciu logic) poate servi clienții care sosesc imediat ce ajung, situațiile de această natură ar trebui să funcționeze bine. Cu toate acestea, atunci când serverul primește mai multe cereri decât poate gestiona, atunci fiecare client este forțat să aștepte ca cererile celorlalți clienți să finalizeze procesarea înainte de a genera un răspuns la propria sa cerere. Acesta este un exemplu de solicitare sincronă, prezentată în .

Acest tip de comportament sincron poate degrada semnificativ performanța clientului; de fapt, fiind inactiv, clientul este forțat să aștepte până primește un răspuns la cerere. Adăugarea de servere suplimentare pentru a face față încărcării sistemului nu rezolvă de fapt problema; Chiar și cu echilibrarea eficientă a sarcinii, este extrem de dificil să se ofere distribuția uniformă și echitabilă a sarcinii necesară pentru a maximiza productivitatea clientului. Mai mult, dacă serverul de procesare a acestei solicitări nu este disponibil (sau s-a prăbușit), atunci și clientul conectat la acesta nu va mai funcționa. O soluție eficientă la această problemă necesită o abstractizare între cererea clientului și munca efectivă efectuată pentru a o servi.

Figura 1.21: Utilizarea cozilor pentru a gestiona cererile

Cozi de intrare. Modul în care funcționează coada este foarte simplu: o sarcină sosește, intră în coadă, iar apoi „lucrătorii” acceptă următoarea sarcină de îndată ce au posibilitatea de a o procesa. (Vezi.) Aceste sarcini pot fi simple intrări în baza de date sau ceva la fel de complex precum generarea unei imagini de previzualizare pentru un document. Când un client trimite cereri de sarcini la o coadă, nu mai trebuie să aștepte rezultatele execuției; în schimb, cererile au nevoie doar de confirmarea faptului că au fost primite corect. Această confirmare poate servi ulterior ca referință la rezultatele muncii atunci când clientul le solicită.

Cozile permit clienților să lucreze într-o manieră asincronă, oferind o abstractizare strategică a cererii și răspunsului clientului. Pe de altă parte, într-un sistem sincron, nu există nicio diferențiere între cerere și răspuns și, prin urmare, acestea nu pot fi gestionate separat. Într-un sistem asincron, clientul trimite o sarcină, serviciul răspunde cu un mesaj care confirmă că sarcina a fost primită, iar clientul poate verifica apoi periodic starea sarcinii, solicitând rezultatul doar odată ce aceasta a fost finalizată. În timp ce clientul face o solicitare asincronă, este liber să facă alte lucrări și chiar să facă cereri asincrone de la alte servicii. Acesta din urmă este un exemplu al modului în care cozile și mesajele funcționează în sistemele distribuite.

Cozile oferă, de asemenea, o anumită protecție împotriva întreruperilor și defecțiunilor serviciului. De exemplu, este destul de ușor să creați o coadă foarte rezistentă care poate reîncerca solicitările de servicii care eșuează din cauza defecțiunilor momentane ale serverului. Este de preferat să folosiți o coadă pentru a impune garanțiile de calitate a serviciului, mai degrabă decât să expuneți clienții la întreruperi temporare ale serviciului, necesitând o gestionare complexă și adesea inconsecventă a erorilor din partea clientului.

1.4. Concluzie

Dezvoltarea sistemelor eficiente cu acces rapid la cantități mari de date este un subiect foarte interesant și există încă un număr semnificativ de instrumente bune care pot găzdui tot felul de aplicații noi. Acest capitol a atins doar câteva exemple, dar în realitate sunt multe altele - și noi inovații în acest domeniu vor continua să fie create.

Această lucrare este licențiată sub o licență Creative Commons Attribution 3.0 Unmodified. Vezi detalii în

În acest articol, vom schița câteva concepte pe care trebuie să le utilizați atunci când alegeți un ventilator de carcasă și vom vorbi despre caracteristicile diferitelor tipuri de ventilatoare. În plus, vom testa ventilatorul de 120 mm akasa Amber AK-183-L2B, care de mai bine de un an servește ca element activ al sistemului de răcire a procesorului Thermaltake Sonic Tower, folosit la testarea procesoarelor și plăcilor video. Și trebuie menționat că și-a câștigat pe deplin dreptul de a deveni primul erou dintr-o serie de recenzii dedicate fanilor pe resursa noastră.

Întrebările la care vom încerca să răspundem sunt...

Ce cerințe pot fi impuse unui ventilator de carcasă?

1. Nivel de performanță.
2. Nivel de zgomot.
3. Aspect (prezența și tipul luminii de fundal).
4. Caracteristici suplimentare (suport pentru alimentare PWM, regulator de viteză, suport anti-vibrații).

Care sunt principalele diferențe dintre ventilatoarele de carcasă?

1.Dimensiuni– dimensiunea rotorului.

Pentru a crea ventilație internă în carcasă, în cele mai multe cazuri, se folosesc ventilatoare cu o dimensiune standard de 80 mm, 92 mm sau 120 mm, deoarece găurile de montare sunt prevăzute inițial pentru instalarea lor în carcasă. Este clar că cu cât rotorul ventilatorului este mai mare, cu atât este mai mare capacitatea acestuia de a pompa debitul de aer. Prin urmare, pentru a atinge nivelurile de eficiență ale modelelor mai mari, un ventilator mai mic va trebui să se rotească cu o viteză mai mare și, în consecință, să producă mult mai mult zgomot. De fapt, din acest motiv, ventilatoarele mari de 120 mm sunt populare.

Pentru a clarifica aceste proprietăți, puteți compara caracteristicile modelelor de ventilatoare din aceeași serie de la Xinruilian Science & Technology Co. având dimensiuni diferite:

Dimensiune, mm
Viteza rpm
Flux de aer, CFM
Nivel de zgomot, dB
Presiune, mm H 2 0

Judecând după caracteristicile date ale modelelor, putem concluziona că la aceeași viteză de rotație, un ventilator de 92 mm va fi de 1,65 ori mai eficient decât unul de 80 mm, iar un ventilator de 120 mm va fi de două ori mai eficient decât un model de 92 mm. , ținând cont de faptul că toate ventilatoarele au un singur tip de rotor.

Pe lângă diferitele diametre ale rotorului, dimensiunea profilului sau adâncimea ventilatorului sunt, de asemenea, la fel de importante. Profilul „clasic” pentru carcase obișnuite este profilul de 25 mm. Ventilatoarele cu profil mai mic se numesc profil redus, în timp ce ventilatoarele cu profil mai mare sunt numite profil înalt. Puterea fluxului de aer, care este caracterizată în caiet de sarcini prin valoarea presiunii maxime, depinde direct de dimensiunea profilului.

De exemplu, să comparăm caracteristicile a două modele de 120 mm - cu un profil obișnuit și un profil înalt, care funcționează la aceeași viteză de rotație.

Dimensiune, mm
Viteza rpm
Flux de aer, CFM
Nivel de zgomot, dB
Presiune, mm H20

Tabelul arată că un ventilator cu profil înalt se distinge doar printr-un indicator mai bun al presiunii maxime a debitului de aer. În sistemele computerizate convenționale nu este nevoie să se creeze o presiune în exces, astfel încât aceste ventilatoare nu sunt folosite în ele. În cele mai multe cazuri, ventilatoarele de profil înalt sunt utilizate în servere; în plus, au o viteză de rotație crescută și, ca urmare, destul de mult zgomot de funcționare.

2. Tip rulment.

Ventilatoarele folosesc trei tipuri principale de rulmenți: simpli, combinați de alunecare și rulare și constând din doi rulmenți de rulare. Pe lângă aceste tipuri de rulmenți, mult mai rar, există și tipuri hidrodinamice care sunt special dezvoltate separat de unii producători.

Cel mai adesea, puteți determina tipul de rulment prin prezența următorilor indici în numele modelului de ventilator, deși este întotdeauna recomandabil să verificați specificația oficială:

S (mânecă) – un rulment de alunecare, care este în esență o bucșă;
CU (combo) - un rulment cu bile si o bucsa scurta;
B (minge) sau 2B (2 mingi)– doi rulmenti cu bile.

Cel mai simplu și mai ieftin, dar, din păcate, nu deosebit de durabil este rulmentul lizibil. Acest rulment arată ca o bucșă mică de cupru, în interiorul căreia alunecă, rotindu-se, arborele rotorului (tija). Un ventilator nou cu un rulment alunecat lubrifiat poate fi complet silențios, dar în timp această proprietate se poate pierde. În absența unui nivel adecvat de lubrifiere, bucșa „se uzează” destul de repede, motiv pentru care ventilatorul începe să facă zgomot. În plus, în absența lubrifierii, atunci când funcționează într-o zonă cu temperaturi ridicate, ventilatorul se poate bloca complet. Acest fapt este demonstrat mai ales în mod clar de cazurile cu surse de alimentare chinezești ieftine, în care au existat adesea cazuri de oprire a ventilatorului pe rulmentul lizibil, ceea ce asigură răcirea elementelor semiconductoare de putere. Ca urmare, sursa de alimentare a eșuat.

Versiunea combinată a rulmentului are o durată de viață relativ mai lungă.

Un rulment format din doi rulmenti cu bile este cea mai scumpa varianta, dar in acelasi timp si mai durabila. Acest tip de rulment poate funcționa liber în zone cu temperaturi ridicate. Dar, în același timp, adesea printre astfel de fani puteți găsi exemplare care produc zgomot destul de puternic și neplăcut. Această imagine este tipică în special pentru ventilatoarele ieftine, deoarece caracteristicile de zgomot ale întregii structuri depind direct de calitatea de fabricație a rulmentului miniatural. Prin urmare, dacă alegeți un produs cu rulmenți cu bile, nu căutați sub nicio formă ieftinitatea acestuia, deoarece modelele și mai scumpe sunt rareori silențioase.

3. Clasa de motor.

Toate ventilatoarele carcasei sunt alimentate de motoare de curent continuu cu patru poli. În funcție de turație, toate sunt clasificate în trei categorii: viteză mică până la 2000 rpm, medie de la 2000 la 3000 rpm și turație mare peste 3000 rpm. Puteți afla adesea clasa unui motor de ventilator după indexul din numele său, care este adesea indicat pe un autocolant:

L (scăzut) - viteza mica ( până la 2000 rpm);
M (mijloc) - in medie ( de la 2000 la 3000 rpm);
H (înalt) - de mare viteză ( peste 3000 rpm).

Ce caracterizează datele date în specificațiile producătorilor?

Viteza ventilatorului măsurată în numărul de rotații pe minut (RPM - rotații pe minut). Deoarece viteza ventilatorului în sine poate varia aproape direct proporțional cu tensiunea de alimentare, valoarea dată în specificație corespunde tensiunii nominale de alimentare. Cu cât viteza de rotație este mai mare, cu atât ventilatorul este mai eficient, dar și de obicei cu atât mai zgomotos.

Flux de aer poate fi indicat în CFM (picioare cubi pe minut, CFM) - picioare cubi pe minut sau în metri cubi pe oră (m 3 / h). În acest caz, 1 CFM ≈ 1,7 m 3 / h. Această valoare afișează cantitatea de aer „pompat” pe o anumită perioadă de timp, cu condiția să existe absența completă a rezistenței la fluxul de aer, adică cu presiune egală a aerului pe ambele părți ale ventilatorului. Desigur, cu cât această valoare este mai mare, cu atât mai bine.

Presiunea statică a fluxului de aer ventilatorul este de obicei dat în mm de coloană de apă și caracterizează forța fluxului de aer pe care o poate crea ventilatorul.

Amintiți-vă că presiunea este calculată folosind formula P=F/S. Adică presiunea este raportul dintre forța fluxului de aer și zona pe care acționează. Specificația indică cantitatea maximă de flux de aer pe care o creează ventilatorul atunci când nu poate crea flux de aer din cauza rezistenței.

Toate caracteristicile ventilatorului pot fi văzute pe graficul „Curba de performanță”.

Curba de performanță reprezintă relația dintre debitul de aer și presiune. Cel mai înalt punct al curbei, situat pe axă, nu este tocmai nimic altceva decât presiunea maximă, care este dată în specificație. Punctul cel mai de jos al curbei, situat pe cealaltă axă, corespunde debitului maxim de aer al ventilatorului atunci când acesta nu trebuie să creeze presiune. În condiții reale, și anume într-o carcasă, fluxul de aer trebuie să învingă o oarecare rezistență. Fiecare caz individual are propriul său grad de rezistență. Rezistența sistemului va fi exprimată ca o pantă pe grafic, iar punctul de intersecție al dreptei și curbei nu este altceva decât punctul de funcționare al ventilatorului în sistemul nostru condiționat.

Viața fanilor măsurată prin numărul de mii de ore în care ventilatorul trebuie să funcționeze și să ofere caracteristicile declarate. Autorul articolului nu știe pe deplin în ce condiții de funcționare sunt atinse valorile date, deoarece durata de viață depinde direct de condițiile de funcționare. Se presupune că ventilatorul este capabil să funcționeze pentru numărul specificat de ore fără a-și pierde calitățile de zgomot. Resursa depinde în mare măsură de tipul și calitatea rulmentului. Pentru rulmenți de alunecare, de obicei sunt specificate 30.000 de ore, pentru rulmenți combinați - 45.000 de ore, iar pentru rulmenți cu bile duble, sunt date valori de 60.000 de ore și peste.

În cele mai multe cazuri, un ventilator pe un rulment de alunecare poate funcționa destul de liniștit timp de aproximativ un an, deși producătorii susțin o cifră de 30 de mii. Prin urmare, nu ar trebui să fie părtinitoare cu privire la aceste numere - sunt destul de relative. Și dacă sapi mai adânc, se dovedește că producătorul a implicat și întreținerea periodică a ventilatoarelor, adică. un lubrifiant pe care utilizatorii obișnuiți îl produc rar.

Acum să revenim la eroul recenziei noastre, fanul. akasa AK-183-L2Bși uită-te la specificațiile sale:

	akasaAK-183-L2B
Dimensiune, mm
Viteza de rotație, rpm
Flux de aer, CFM
Presiune, mm H20
Resursa, h
Tip rulment	două leagăne
	3 pini
Nivel de zgomot, dB
Tensiune de alimentare, V
Pagina web a produselor
prețul mediu

Ventilatorul akasa AK-183-L2B este ambalat într-un ambalaj din plastic transparent. Spatele pachetului conține o foaie de carton albastru, evidențiind corpul transparent și rotorul ventilatorului translucid galben-chihlimbar. În general, totul este decorat în culorile corporative cunoscute albastru și galben ale grupului Akasa.

Pe spatele inserției de carton există o specificație în cinci limbi diferite.

Pe lângă ventilator, în partea de jos a pachetului se află o cutie mică de carton neagră cu o inscripție tradusă ca „Adaptor 3-4 pini”.

Prin urmare, nu este deloc surprinzător faptul că cutia conținea un adaptor care vă permite să conectați ventilatorul de la conectorii dispozitivelor periferice și, în plus, are în plus un conector cu 3 pini pentru controlul vitezei de rotație a ventilatorului. Tot în cutia neagră mică erau patru șuruburi pentru instalarea ventilatorului în carcasă.

Corpul ventilatorului akasa AK-183-L2B este realizat din plastic alb transparent, iar rotorul său este din plastic translucid galben chihlimbar. De fapt, dacă luăm în considerare întreaga gamă de produse a companiei akasa, rareori întâlnim soluții simple și standard, deoarece compania distribuie produse, în cea mai mare parte, concepute special pentru modding. Dar asta nu înseamnă deloc că, dacă nu te consideri un modder și obișnuiești să evaluezi un produs doar din motive practice, atunci acest ventilator și alte produse similare nu sunt potrivite pentru tine. De fapt, atunci când se produc produse pentru așa-zișii utilizatori dificili, moddere sau overlocke, o atenție sporită se pune întotdeauna în vedere, în primul rând, calității manoperei și proprietăților sale ceva mai înalte. Prin urmare, nu este deloc surprinzător că aproape întotdeauna calitățile de consum ale unor astfel de produse sunt mai mari decât cele ale bunurilor simple.

În exterior, ventilatorul, desigur, iese în evidență în primul rând prin frumoasa sa combinație de culori galben și alb și se pare că un astfel de ventilator pur și simplu trebuie să aibă o lumină de fundal, dar de fapt nu are. Din punct de vedere aerodinamic, nu au fost implementate inovații sau know-how în ventilator - un simplu rotor cu șapte pale.

Ventilatorul akasa AK-183-L2B este un model cu viteză mică, viteza sa nominală de rotație este de 1400 rpm, în timp ce debitul maxim de aer poate ajunge la 44,8 CFM, iar presiunea statică este de 1,1 mm coloană de apă. Caracteristicile nu sunt nici super ridicate, nici destul de obișnuite, dar acest lucru nu este surprinzător, deoarece pentru un ventilator de carcasă al unui sistem de acasă, în primul rând, se pun cerințe sporite de zgomot.

Și în acest sens, specificația indică un nivel de zgomot destul de scăzut de 18 dB. Trebuie remarcat faptul că ventilatorul akasa AK-183-L2B are la bază doi rulmenți cu bile, iar durata de viață, conform producătorului, este de 80.000 de ore. Valoarea obișnuită pentru rulmenți cu bile este de 60.000 de ore, așa că o valoare ușor crescută dă motive să sperăm într-o abordare mai bună a fabricării acestora, deoarece am observat deja că calitatea rulmentului cu bile este cea care determină caracteristicile de zgomot ale acestuia.

Ventilatorul este alimentat de un conector de alimentare cu 3 pini, care nu acceptă surse de alimentare cu lățime de impuls.

Testare

Partea practică a testului constă în două etape de testare a debitului de aer generat de ventilator la viteze nominale, precum și evaluarea volumului acestuia după ureche.

Testul nr. 1

În primul test, ventilatorul va acționa ca un element activ al răcitorului Thermalright SI-128. Testarea se efectuează într-o carcasă deschisă, iar principalul parametru controlat este temperatura de încălzire a procesorului Intel Core 2 Duo E6300 overclockat la 2,8 GHz și temperatura plăcii de bază.

Testul nr. 2

În cel de-al doilea test, ventilatorul va fi folosit în scopul propus ca ventilator de carcasă instalat pe panoul din spate și funcționând ca un ventilator de evacuare. În timpul testului, carcasa va fi închisă și nu vor mai fi pornite alte ventilatoare. Principalul parametru controlat va fi și temperatura de încălzire a procesorului Intel Core 2 Duo E6300, dar acum fără overclock, care este echipat cu un sistem pasiv de răcire Thermaltake Sonic Tower (CL-P0071) și temperatura plăcii de bază. Rezultatul testului este înregistrat după o „rulare” de 10 minute a testului de stres al procesorului în aplicația Everest.

Configurația platformei de testare cu un procesor Intel constă din următoarele componente:

Placa de baza	Gigabyte GA-965P-DS4 (Intel P965 Express)
CPU	Intel Core 2 Duo E6300 (LGA775, 1,86 GHz, L2 2 MB) @2,8 GHz
RAM	2 x DDR2-800 1024 MB Apacer PC6400
Placa video	EVGA GeForce 8600GTS 256 MB DDR3 PCI-E
HDD	Samsung HD080HJ, 80 GB, SATA-300
Unitate optică	ASUS DRW-1814BLT SATA
unitate de putere	Chieftec CFT-500-A12S 500W, ventilator 120 mm
	CODEGEN M603 MidiTower

Ventilatorul akasa AK-183-L2B demonstrează performanțe bune la egalitate cu alți concurenți. Putem confirma nivelul de zgomot declarat destul de scăzut de 18 dB doar cu opinia noastră subiectivă. Valoarea indicată este într-adevăr destul de consistentă cu nivelul real de zgomot - la viteza maximă emite un ușor zumzet.

Concluzii.

Ventilatorul akasa AK-183-L2B nu este exclusiv un decor frumos pentru modding, așa cum ar putea părea imediat cumpărătorului. Poate crea un flux de aer destul de mare și, cel mai important, produce un nivel de zgomot destul de scăzut. Dacă luăm în considerare prețul său rezonabil pentru un model de ventilator cu rulmenți de înaltă calitate, atunci în această categorie de mărfuri va fi unul dintre cele mai bune în ceea ce privește raportul preț/calitate consumator. Să repetăm ​​că în laboratorul nostru de teste, ventilatorul akasa AK-183-L2B este în funcțiune de mai bine de un an, iar calitățile sale de zgomot au rămas practic neschimbate în acest timp.

Avantaje:

• creează un flux mare de aer;
• nivel scăzut de zgomot;
• raport bun pret/performanta.

Dezavantajele includ:

• lipsa suportului PWM.

Ne exprimăm recunoștința companiei PF Service LLC (Dnepropetrovsk) pentru echipamentele puse la dispoziție pentru testare.

Articolul citit de 4669 ori

Abonați-vă la canalele noastre

Vă rugăm să activați Javascript pentru a utiliza convertorul de unități

›› Mai multe informații de la convertorul de unitate

Câți cfm într-un metru cub/minut? Răspunsul este 35.314666212661.
Presupunem că faceți conversia între picioare cubi/minutși metru cub/minut.
Puteți vedea mai multe detalii despre fiecare unitate de măsură:
cfm sau metru cub/minut
Unitatea derivată SI pentru debitul volumic este metrul cub/secundă.
1 metru cub/secundă este egal cu 2118,8799727597 cfm sau 60 metru cub/minut.
Rețineți că pot apărea erori de rotunjire, deci verificați întotdeauna rezultatele.
Utilizați această pagină pentru a afla cum să convertiți între picioare cubi/minut și metri cubi/minut.
Introduceți propriile numere în formular pentru a converti unitățile!

›› Diagrama de conversie rapidă a cfm în metru cub/minut

1 cfm în metru cub/minut = 0,02832 metru cub/minut

10 cfm în metru cub/minut = 0,28317 metru cub/minut

20 cfm în metru cub/minut = 0,56634 metru cub/minut

30 cfm în metru cub/minut = 0,84951 metru cub/minut

40 cfm în metru cub/minut = 1,13267 metru cub/minut

50 cfm în metru cub/minut = 1,41584 metru cub/minut

100 cfm în metru cub/minut = 2,83168 metru cub/minut

200 cfm în metru cub/minut = 5,66337 metru cub/minut

›› Doriți alte unități?

›› Definiție: Picior cub/minut

Piciori cubi pe minut (CFM) este o măsură utilizată în igiena industrială și ingineria ventilației. Descrie viteza de curgere a unui volum de gaz sau aer în sau în afara unui spațiu.

O măsurătoare standard a fluxului de aer care indică câți picioare cubi de aer trec pe lângă un punct staționar într-un minut. Cu cât numărul este mai mare, cu atât mai mult aer este forțat prin sistem. Debitul volumetric al unui lichid sau gaz în picioare cubi pe minut. 1 CFM este egal cu aproximativ 0,47 litri pe secundă.

›› Conversii metrice și multe altele

site-ul web oferă un calculator de conversie online pentru toate tipurile de unități de măsură. Puteți găsi tabele de conversie metrică pentru unitățile SI, precum și unități engleze, valută și alte date. Introduceți simboluri de unitate, abrevieri sau nume complete pentru unitățile de lungime, suprafață, masă, presiune și alte tipuri. Exemplele includ mm, inci, 100 kg, uncie lichide americane, 6"3", 10 piatră 4, cm cubi, metri pătrați, grame, alunițe, picioare pe secundă și multe altele!

• Traducere

Măsurarea debitului blocajelor pe baza timpului de trecere dublu al unui pachet

Prin toate măsurile, internetul de astăzi nu poate muta datele la fel de repede cum ar trebui. Majoritatea utilizatorilor de telefonie mobilă din lume se confruntă cu întârzieri care variază de la câteva secunde la câteva minute: hotspot-urile publice WiFi din aeroporturi și conferințe sunt și mai rele. Fizicienii și oamenii de știință în climă trebuie să partajeze petabytes de date cu colegii din întreaga lume, dar constată că infrastructura lor elaborată multi-gigabit produce adesea doar câțiva megabiți pe secundă prin legături transcontinentale.

Aceste probleme au apărut din alegerile arhitecturale făcute atunci când a fost creată congestia TCP în anii 1980, când pierderea pachetelor a fost interpretată ca „congestie”. Echivalența acestor concepte era adevărată pentru acea vreme, dar numai datorită limitărilor tehnologiei, și nu prin definiție. Pe măsură ce NIC-urile (controlere de interfață de rețea) au trecut de la viteze megabit la gigabit și cipurile de memorie de la kilobyte la gigabytes, relația dintre pierderea pachetelor și congestie a devenit mai puțin clară.

În TCP modern, limitarea congestiei de pierderi de pachete - chiar și în cea mai avansată tehnologie de acest gen, CUBIC - este cauza principală a acestor probleme. Dacă tampoanele de blocaj sunt prea mari, controlul congestiei pierderii pachetelor le menține pline, provocând tamponarea inutilă a rețelei. Dacă tampoanele sunt prea mici, sistemul de control al congestionării pierderii pachetelor interpretează incorect pierderea pachetelor ca un semnal de congestie, rezultând o debit redus. Rezolvarea acestor probleme necesită o alternativă la limitarea congestiei de pierderi de pachete. Pentru a găsi această alternativă, trebuie să înțelegeți unde și cum apare aglomerația.

Aglomerație și blocaj

În orice moment, există o singură legătură cea mai lentă într-o conexiune TCP (full duplex) sau blocajîn toate direcțiile. Blocajul este important din următoarele motive:

• Acesta determină rata maximă de transfer de date prin conexiune. Aceasta este proprietatea principală a unui flux de date necomprimat (de exemplu, imaginați-vă o autostradă cu șase benzi în timpul orelor de vârf dacă, din cauza unui accident, o mică secțiune a drumului este limitată la o singură bandă. Traficul din fața accidentului nu se va deplasa mai repede decât traficul pe această bandă.
• Acesta este locul unde se formează constant cozile. Ele scad doar dacă intensitatea fluxului de ieșire din blocaj depășește intensitatea fluxului de intrare. Pentru conexiunile care rulează la rata maximă de biți, toate fluxurile de ieșire către blocaj au întotdeauna un debit de ieșire mai mare, astfel încât cozile se deplasează spre blocaj.

Indiferent de câte legături există într-o conexiune și care sunt vitezele lor individuale, din punct de vedere TCP, o rută arbitrar complexă apare ca o singură conexiune cu același RTT (durată dus-întors) și debit de blocaj . Două limitări fizice RTprop(timp de propagare dus-întors, timp de trecere a pachetului dublu) și BtlBw(lățimea de bandă îngustă) afectează performanța transmisiei. (Dacă calea rețelei ar fi o conductă de material, RTprop ar fi lungimea conductei, iar BtlBw ar fi diametrul acesteia).

Figura 1 prezintă diferite combinații de RTT și baud rate cu volumul de date în zbor, adică în zbor (date trimise, dar fără confirmare de livrare). Liniile albastre arată limita RTprop, liniile verzi limita BtlBw, iar liniile roșii bufferul de blocaj. Operațiunile în zone gri nu sunt posibile deoarece contrazic cel puțin o restricție. Tranzițiile între restricții au dus la formarea a trei regiuni (limitate de aplicații, limitate de lățime de bandă și limitate de buffer) cu un comportament calitativ diferit.

Poza 1

Când nu există suficiente date în zbor pentru a umple conducta, RTprop determină comportamentul; altfel BtlBw domină. Liniile de restricție se intersectează în punctul , cunoscut și sub denumirea de conducte BDP (produs de întârziere a lățimii de bandă, un derivat al debitului și întârzierii). Deoarece conducta este plină după acest punct, excesul creează o coadă la blocaj, rezultând o relație liniară între RTT și datele în zbor prezentate în graficul de sus. Pachetele sunt aruncate atunci când excesul depășește capacitatea tampon. Congestionare este pur și simplu să fie continuu la dreapta liniei BDP și controlul congestiei- o schemă pentru a stabili o limită la cât de departe în dreapta liniei BDP are loc, în medie, transmisia de date.

Controlul congestiei bazat pe pierderi operează la marginea dreaptă a regiunii limitate de lățime de bandă, oferind o capacitate completă de blocaj cu prețul latenței mari și pierderii frecvente de pachete. Pe vremea când memoria era scumpă, dimensiunile bufferului erau doar puțin mai mari decât BDP, ceea ce minimiza latența excesivă a controlului congestiei bazat pe pierderi. Reducerile ulterioare ale prețurilor memoriei au condus la o creștere a tamponării inutile a rețelei și la o creștere a RTT la secunde în loc de milisecunde.

Pe marginea stângă a zonei limitate de capacitatea canalului se află un punct de operare cu condiții mai bune decât în ​​dreapta. În 1979, Leonard Kleinrock a arătat că acest punct de operare este optim; maximizează debitul real, minimizând în același timp întârzierile și pierderile, atât pentru conexiuni individuale, cât și pentru rețea în ansamblu. Din păcate, cam în aceeași perioadă, Jeffrey Yaffe a demonstrat că este imposibil să se creeze un algoritm distribuit care să convergă în acest punct de operare. Această constatare a schimbat direcția cercetării. În loc să caute un algoritm distribuit care tinde spre punctul optim de operare Kleinrock, cercetătorii au început să exploreze abordări alternative pentru controlul congestiei.

Echipa noastră de la Google petrece ore întregi în fiecare zi studiind jurnalele de captură antet TCP din întreaga lume, înțelegând anomaliile și comportamentul patologic. De obicei, căutăm mai întâi caracteristicile cheie ale traseului, RTprop și BtlBw. Faptul că ele pot fi deduse din urmele rețelei sugerează că concluzia lui Jaffe s-ar putea să nu fie atât de clară cum se credea cândva. Deducerea sa se bazează pe incertitudinea fundamentală de măsurare (de exemplu, dacă creșterea măsurată a RTT este cauzată de o modificare a lungimii căii, de o scădere a capacității de blocaj sau de o creștere a întârzierii la coadă din cauza traficului de la o altă conexiune). Deși nu este posibilă eliminarea incertitudinii fiecărei măsurători specifice, comportamentul conexiunii în timp oferă o imagine mai clară, sugerând posibilitatea utilizării strategiilor de măsurare menite să elimine incertitudinea.

Combinând aceste măsurători cu o buclă servo robustă și valorificând cele mai recente progrese în sistemele de control, se poate spera să dezvolte un protocol de gestionare a congestiei distribuite care să răspundă la congestionarea reală, mai degrabă decât la pierderea de pachete sau la întârzierile momentane în coadă. Și va converge cu o probabilitate mare la punctul optim de operare Kleinrock. Astfel a început proiectul nostru de trei ani de dezvoltare a unui sistem de management al congestiei bazat pe măsurarea a doi parametri care caracterizează o rută: capacitatea de blocaj și timpul de călătorie dus-întors de pachete, sau BBR.

Caracteristicile gâtului de sticlă

O conexiune funcționează la debit maxim și latență minimă atunci când rata de sosire a pachetelor (echilibrul ratei) la blocaj este egală cu BtlBw și datele totale (legatură completă) în zbor este egală cu BDP().

Prima condiție asigură că blocajul este utilizat 100%. Al doilea ne asigură că avem suficiente date pentru a preveni blocajele, dar nu pentru a copleși canalul. Condiția echilibrului vitezei în sine Nu garantează nicio coadă, doar dimensiunea sa constantă (de exemplu, dacă o conexiune începe prin trimiterea unei ferestre inițiale de 10 pachete la un BDP cu cinci pachete, apoi rulează exact la aceeași viteză de blocaj, atunci cinci din cele zece pachete inițiale vor umple canal, iar excesul va forma o coadă permanentă în blocaj care nu se va putea dizolva). De asemenea, condiția de legătură completă nu garantează că nu există o coadă (de exemplu, o conexiune trimite BDP în rafale peste BDP/2 și utilizează pe deplin blocajul, dar coada medie este BDP/4). Singura modalitate de a minimiza cozile de așteptare la blocaj și pe întreaga legătură este de a satisface ambele condiții simultan.

Valorile BtlBw și RTprop se schimbă de-a lungul duratei de viață a conexiunii, așa că ar trebui să fie evaluate continuu. În prezent, TCP monitorizează RTT (intervalul de timp dintre trimiterea unui pachet de date și raportarea livrării acestuia), deoarece este necesar pentru a determina pierderile. La orice moment dat,

unde reprezintă „zgomotul” de la cozile de-a lungul rutei, strategia destinatarului de întârziere a recunoașterii, aglomerarea de confirmare etc. RTprop este o proprietate fizică a conexiunii și se schimbă doar atunci când se schimbă canalul în sine. Deoarece schimbările de canal au loc pe o scară de timp ≥ RTprop, atunci ar fi o estimare imparțială și eficientă a timpului
adică rularea într-o fereastră de timp (care este de obicei de la zeci de secunde la minute).

Spre deosebire de RTT, nimic din specificațiile TCP nu necesită o implementare pentru a urmări debitul blocajului, dar o estimare bună a acestui lucru poate fi obținută din urmărirea ratelor de livrare. Când o confirmare a livrării unui pachet revine expeditorului, acesta arată RTT-ul pachetului și anunță livrarea datelor în zbor când pachetul pleacă. Viteza medie de livrare între trimiterea unui pachet și primirea unei confirmări este raportul dintre datele livrate și timpul scurs: . Această rată trebuie să fie mai mică sau egală cu capacitatea de blocaj (cantitatea de sosire este cunoscută exact, deci toată incertitudinea constă în , care trebuie să fie mai mare sau egal cu intervalul de sosire real; prin urmare raportul trebuie să fie mai mic sau egal cu rata reală de livrare, care, la rândul ei, este la coadă, limitată de sus de capacitatea blocajului). Prin urmare, fereastra maximă a ratei de livrare este o estimare eficientă și imparțială a BtlBw:

unde fereastra de timp este de obicei între șase și zece RTT-uri.

TCP trebuie să înregistreze ora la care a fost trimis fiecare pachet pentru a calcula RTT. BBR mărește aceste înregistrări cu cantitatea totală de date livrate, astfel încât sosirea fiecărei confirmări raportează atât RTT, cât și rezultatul măsurării ratei de livrare, pe care filtrele le convertesc în estimări ale RTprop și BtlBw.

Rețineți că aceste valori sunt complet independente: RTprop se poate modifica (de exemplu, atunci când ruta se schimbă), dar suferă același blocaj, sau BtlBw se poate modifica (de exemplu, atunci când capacitatea canalului wireless se schimbă) fără a modifica ruta. (Independența ambilor factori de moderare este motivul pentru care aceștia trebuie cunoscuți pentru a lega comportamentul de transport cu ruta de livrare). Deoarece RTprop este vizibil doar pe partea stângă a BDP și BtlBw doar pe partea dreaptă în Figura 1, acestea sunt supuse principiului incertitudinii: ori de câte ori unul dintre cele două poate fi măsurat, celălalt nu poate fi măsurat. Intuitiv, acest lucru poate fi înțeles astfel: pentru a determina capacitatea unui canal, acesta trebuie să fie supraumplut, ceea ce creează o coadă care face imposibilă măsurarea lungimii canalului. De exemplu, o aplicație cu un protocol de cerere/răspuns nu poate trimite niciodată suficiente date pentru a umple canalul și a monitoriza BtlBw. O transmisie de mai multe ore a unei matrice mari de date poate petrece tot timpul într-o zonă cu lățime de bandă limitată și poate primi doar o singură mostră RTprop de la RTT-ul primului pachet. Principiul inerent al incertitudinii înseamnă că, pe lângă estimări pentru a reconstrui cei doi parametri ai traseului, trebuie să existe state care să urmărească simultan atât ceea ce poate fi învățat la punctul de operare curent, cât și, pe măsură ce informațiile devin mai puțin proaspete, cum se ajunge la punctul de operare. unde se pot obține date mai recente.

Maparea unui flux de pachete la o cale de livrare

Algoritmul de bază BBR constă din două părți:

Când primim confirmarea (ack)

Fiecare confirmare oferă un nou RTT și măsurători ale ratei medii de livrare, care actualizează estimările RTprop și BtlBw:

Funcția onAck(pachet) rtt = acum - packet.sendtime update_min_filter(RTpropFilter, rtt) livrat += packet.size delivered_time = acum deliveryRate = (livrat - packet.delivered) / (delivered_time - packet.delivered_time) dacă (deliveryRate > Bt. currentMax || ! packet.app_limited) update_max_filter(BtlBwFilter, deliveryRate) if (app_limited_until > 0) app_limited_until = app_limited_until - packet.size
Verificarea dacă este necesară din cauza problemei de incertitudine discutată în ultimul paragraf: expeditorii pot fi limitați de aplicație, ceea ce înseamnă că aplicația poate rămâne fără date pentru a umple rețeaua. Aceasta este o situație destul de tipică din cauza traficului de cereri/răspuns. Când există o oportunitate de a trimite, dar nu sunt trimise date, BBR marchează mostrele de lățime de bandă corespunzătoare ca „aplicație limitată”, adică app_limited (vezi pseudocodul send()). Acest cod determină ce mostre să includă în modelul de debit, astfel încât să reflecte limitele rețelei mai degrabă decât limitele aplicației. BtlBw este o limită superioară rigidă a ratei de livrare, astfel încât o rată de livrare măsurată mai mare decât estimarea curentă a BtlBw ar trebui să implice o subestimare a BtlBw, indiferent dacă eșantionul a fost limitat de aplicare sau nu. În caz contrar, probele cu restricții de aplicare sunt aruncate. (Figura 1 arată că în regiunea cu limitarea aplicației deliveryRate, parametrul BtlBw este subestimat). Aceste verificări împiedică filtrul BtlBw să populeze filtrul BtlBw cu valori prea scăzute, ceea ce ar putea încetini transmiterea datelor.

Când datele sunt trimise

Pentru a potrivi rata de sosire a pachetelor cu rata de plecare din blocaj, BBR urmărește fiecare pachet de date. (BBR trebuie să se potrivească rată blocaj: aceasta înseamnă că urmărirea este o parte integrantă a arhitecturii și o parte fundamentală a operațiunii - deci pacing_rate este principalul parametru de control. Parametru auxiliar cwnd_gain conectează în zbor cu un set mic de BDP-uri pentru a gestiona patologiile tipice de rețea și receptor (a se vedea capitolul despre recunoașterile întârziate și extinse de mai jos). Conceptual, procedura de trimitere în TCP arată ca următorul cod. (Pe Linux, trimiterea datelor folosește o procedură eficientă de așteptare, FQ/pacing, care oferă BBR performanță liniară la o singură conexiune pe conexiuni multi-gigabit și gestionează mii de conexiuni la viteză mai mică, cu o supraîncărcare a CPU neglijabilă.)

Funcția send(packet) bdp = BtlBwFilter.currentMax × RTpropFilter.currentMin if (inflight >= cwnd_gain × bdp) // așteptați confirmarea sau expirarea timpului de retransmisie return if (acum >= nextSendTime) packet = nextPacketToSend() if (! packet) app_limited_until = returnare în zbor packet.app_limited = (app_limited_until > 0) packet.sendtime = acum packet.delivered = livrat packet.delivered_time = livrat_time ship(packet) nextSendTime = acum + packet.size / (pacing_gain × BtlBwFilter.currentMax) timer(sendCall, nextSendTime)
Comportament în stare de echilibru

Viteza și cantitatea de date trimise prin BBR depind doar de BtlBw și RTprop, astfel încât filtrele controlează nu numai estimările constrângerilor de blocaj, ci și aplicarea acestora. Aceasta creează bucla de control personalizată descrisă în Figura 2, care arată RTT (albastru), în zbor (verde) și rata de livrare (roșu) peste 700 de milisecunde pentru un flux de 10 Mbit și 40 de milisecunde. Linia groasă gri de deasupra vitezei de livrare este starea filtrului BtlBw max. Formele triunghiulare sunt obținute prin ciclul factorului pacing_gain în BBR pentru a determina creșterea în BtlBw. Câștigul din fiecare parte a ciclului este afișat aliniat în timp cu datele afectate. Acest factor a funcționat pe RTT mai devreme când datele au fost trimise. Acest lucru este arătat de crestele orizontale din descrierea secvenței de evenimente din partea stângă.

Figura 2

BBR minimizează latența, deoarece cea mai mare parte a timpului este petrecut cu același BDP în acțiune. Din acest motiv, blocajul se deplasează către expeditor, astfel încât creșterea BtlBw devine inobservabilă. În consecință, BBR petrece periodic intervalul RTprop la pacing_gain > 1, ceea ce crește viteza de trimitere și cantitatea de date trimise fără confirmarea livrării (înflight). Dacă BtlBw nu se modifică, atunci se creează o coadă în fața blocajului, crescând RTT-ul, ceea ce menține rata de livrare neschimbată. (Coada poate fi eliminată prin trimiterea de date cu o valoare compensatoare pacing_gain< 1 для следующего RTprop). Если BtlBw увеличивается, то скорость deliveryRate тоже увеличивается, а новое максимальное значение фильтра немедленно увеличивает базовую скорость отслеживания (pacing_rate). Din acest motiv, BBR se adaptează la noua dimensiune a blocajului exponențial rapid. Figura 3 arată acest efect asupra unui flux de 10 Mbps 40 ms, pe care BtlBw crește brusc la 20 Mbps după 20 de secunde de funcționare constantă (în partea stângă a graficului), apoi scade la 10 Mbps după alte 20 de secunde de funcționare susținută la 20 Mbit/s (dreapta). partea graficului).

Figura 3

(În esență, BBR este un exemplu simplu de sistem de control „max-plus”, o nouă abordare a sistemelor de control bazată pe algebră max-plus non-standard. Această abordare permite adaptarea vitezei [controlată de câștig max] indiferent de creșterea cozii [controlată de raportul de transmisie in medie]. Când se aplică problemei noastre, aceasta se rezumă la o buclă de control simplă, necondiționată, în care adaptarea la modificările constrângerilor fizice se realizează automat prin schimbarea filtrelor care exprimă acele constrângeri. Un sistem tradițional ar necesita crearea multor bucle de control combinate într-o mașină de stare complexă pentru a obține acest rezultat).

Comportament la rularea unui singur fir BBR

Implementările moderne gestionează evenimente precum pornirea, oprirea și recuperarea pierderilor folosind algoritmi de „eveniment” cu multe linii de cod. BBR folosește codul de mai sus (în capitolul anterior, „Potrivirea unui flux de pachete cu o cale de livrare”) pentru orice. Evenimentele sunt procesate prin trecerea printr-o secvență de „stări”. „Stările” în sine sunt definite de un tabel cu una sau mai multe valori fixe ale coeficienților și criterii de ieșire. Cea mai mare parte a timpului este petrecut în starea ProbeBW, care este descrisă în capitolul „Comportament în stare de echilibru”. Stările Startup și Drain sunt utilizate la pornirea unei conexiuni (Figura 4). Pentru a gestiona o conexiune în care debitul crește cu 12 ordine de mărime, starea de pornire implementează un algoritm de căutare binar pentru BtlBw, care utilizează un factor de transfer pentru a dubla rata de transfer atunci când rata de livrare crește. Aceasta definește BtlBw în RTT, dar în același timp creează o coadă inutilă la . Odată ce Startup găsește BtlBw, sistemul BBR intră în starea Drain, care folosește câștigurile inverse ale Startup pentru a scăpa de coada în exces, apoi intră în starea ProbeBW de îndată ce în zbor ajunge la linia BDP.

Figura 4

Figura 4 arată prima secundă a unui flux BBR de 10 Mbps 40 ms. Graficul de sus arată timpul și succesiunea evenimentelor, precum și progresul expeditorului (verde) și al destinatarului (albastru): cantitatea de date transmise și primite. Linia roșie arată performanța CUBIC a expeditorului în aceleași condiții. Liniile gri verticale indică timpii de tranziție între stările BBR. Graficul de jos arată modificarea timpului de călătorie dus-întors (RTT) pentru ambele conexiuni. Rețineți că scala de timp pentru acest grafic corespunde cu ora primirii confirmării sosirii (ack). Prin urmare, graficele pot părea a fi deplasate în timp, dar, de fapt, evenimentele de mai jos corespund momentelor în care sistemul BBR află despre aceste evenimente și reacționează.

Graficul de jos din Figura 4 compară BBR și CUBIC. La început, comportamentul lor este aproape același, dar BBR golește complet coada creată la pornirea conexiunii, în timp ce CUBIC nu poate face acest lucru. Nu are un model de urmărire care să vă spună cât de mult din datele trimise sunt redundante. Prin urmare, CUBIC mărește transmisia de date fără confirmarea livrării într-un mod mai puțin agresiv, dar această creștere continuă până când buffer-ul de blocaj se depășește și începe să renunțe la pachete, sau până când limita destinatarului privind trimiterea datelor fără confirmare (fereastra de primire TCP) este atinsă.

Figura 5 arată comportamentul RTT în primele opt secunde ale conexiunii descrise în figura anterioară 4. Tehnologia CUBIC (în roșu) umple întregul buffer disponibil, apoi se rotește între 70% și 100% la fiecare câteva secunde. Odată ce conexiunea este pornită, BBR (în verde) funcționează practic fără crearea de cozi.

Figura 5

Comportament atunci când mai multe fire BBR se întâlnesc într-un blocaj

Figura 6 arată cum debitul fluxurilor BBR multiple converge către o secțiune corectă a conexiunii cu un blocaj de 100 megabiți/10 milisecunde. Structurile triunghiulare orientate în jos sunt stări ale conexiunilor ProbeRTT în care autosincronizarea accelerează eventuala convergență.

Figura 6

Ciclurile de câștig ProbeBW (Figura 2) stimulează fluxurile mai mari să renunțe la lățime de bandă la fluxuri mai mici, determinând fiecare flux să își înțeleagă starea corectă. Acest lucru se întâmplă destul de repede (mai multe cicluri ProbeBW), deși nedreptatea poate persista dacă firele care pornesc târziu supraestimează RTprop din cauza firelor anterioare (temporar) creând o coadă.

Pentru a afla adevărata RTProp, fluxul este mutat la stânga liniei BDP utilizând starea ProbeRTT: dacă estimarea RTProp nu este actualizată (adică prin eșantionarea unui RTT mai mic) timp de multe secunde, atunci BBR intră în ProbeRTT stare, reducând cantitatea de date trimise (în zbor) la patru pachete pentru cel puțin o trecere dublă și apoi revine la starea anterioară. Când firele mari intră în starea ProbeRTT, multe pachete sunt scoase din coadă, astfel încât mai multe fire să vadă noua valoare RTprop (noul RTT minim). Acest lucru resetează estimările lor RTprop la zero în același timp, astfel încât toți intră împreună în starea ProbeRTT - iar coada se micșorează și mai mult, determinând și mai multe fire să vadă noua valoare RTprop și așa mai departe. Această coordonare distribuită este un factor cheie atât pentru alocarea corectă a lățimii de bandă, cât și pentru stabilitate.

BBR sincronizează firele în jurul evenimentului dorit, care este o coadă goală într-un blocaj. Spre deosebire de această abordare, limitarea congestiei de pierderi de pachete sincronizează fluxurile în jurul evenimentelor nedorite, cum ar fi creșterea periodică a cozii de așteptare și depășirile de buffer, ceea ce crește latența și pierderea de pachete.

Experiență în implementarea B4 WAN la Google

Rețeaua B4 de la Google este o WAN de mare viteză (rețea cu zonă largă), construită pe comutatoare ieftine obișnuite. Pierderile la aceste comutatoare cu buffere mici apar în principal din cauza afluxului ocazional de mici explozii de trafic. În 2015, Google a început să migreze traficul de producție de la CUBIC la BBR. Nu au fost raportate probleme sau regresii, iar din 2016 tot traficul B4 TCP utilizează BBR. Figura 7 ilustrează un motiv pentru care sa făcut acest lucru: debitul BBR este în mod constant de 2 până la 25 de ori mai mare decât cel al lui CUBIC. Am văzut o îmbunătățire și mai mare, dar am constatat că 75% din conexiunile BBR au fost limitate de tamponul de recepție TCP din nucleu, pe care personalul de operațiuni de rețea l-a stabilit în mod deliberat la o valoare scăzută (8 MB) pentru a preveni inundarea rețelei cu megaocteți de CUBIC. trafic în exces fără confirmare de livrare (dacă împărțiți 8 MB la 200 ms RTT intercontinental, obțineți 335 Mbps maxim). Mărirea manuală a bufferului de recepție pe o rută SUA-Europa a crescut instantaneu rata de date BBR la 2 Gbps, în timp ce CUBIC a rămas la 15 Mbps - această creștere relativă de 133 de ori a debitului a fost prezisă de Mathis și colegii în munca științifică din 1997.

Figura 7

Figura 7 arată îmbunătățirea relativă a BBR în comparație cu CUBIC; Inset: funcții de distribuție cumulativă (CDF) pentru capacitate. Măsurătorile au fost efectuate folosind un serviciu de detectare activ, care deschide conexiuni persistente BBR și CUBIC la centrele de date la distanță, apoi transmite 8 MB de date în fiecare minut. Sondele explorează multe rute B4 între America de Nord, Europa și Asia.

Îmbunătățirea uriașă este un rezultat direct al BBR Nu folosește pierderea de pachete ca indicator al congestiei. Pentru a obține un debit maxim, metodele existente de control al congestiei pierderii de pachete necesită ca rata de pierdere să fie mai mică decât pătratul invers al BDP (de exemplu, mai puțin de o pierdere la 30 de milioane de pachete pentru o conexiune de 10 Gbps, 100 ms). Figura 8 compară debitul utilizabil măsurat la diferite niveluri de pierdere a pachetelor. În algoritmul CUBIC, toleranța la pierderea pachetelor este o proprietate structurală a algoritmului, în timp ce în BBR este un parametru de configurare. Pe măsură ce nivelul de pierdere în BBR se apropie de câștigul maxim al ProbeBW, probabilitatea de a măsura rata de livrare a BtlBw real scade brusc, determinând filtrul să subestimeze max.

Figura 8

Figura 8 compară debitul utilizabil al BBR și CUBIC într-un flux de 60 de secunde pe o conexiune de 100 Mbps și 100 ms cu pierderi aleatorii cuprinse între 0,001% și 50%. Debitul CUBIC scade cu un factor de 10 la o pierdere de 0,1% și se blochează complet la mai mult de 1%. Debitul maxim este considerat a fi fracția din lățimea de bandă minus pierderile de pachete (). BBR rămâne la acest nivel până la un nivel de pierdere de 5% și aproape de acesta până la 15%.

Experiență de implementare YouTube Edge

BBR este implementat pe serverele video YouTube și Google.com. Google derulează un mic experiment în care un mic procent de utilizatori sunt transferați aleatoriu la BBR sau CUBIC. Redarea videoclipului prin BBR arată o îmbunătățire semnificativă a tuturor evaluărilor utilizatorilor privind calitatea serviciului. Poate pentru că comportamentul BBR este mai consistent și mai previzibil. BBR îmbunătățește doar puțin debitul de conexiune, deoarece YouTube adaptează deja vitezele de streaming la niveluri cu mult sub BtlBw pentru a minimiza stocarea și rebuffering inutile în rețea. Dar chiar și aici, BBR reduce mediana RTT cu 53% la nivel global și cu peste 80% în țările în curs de dezvoltare.

Figura 9 arată îmbunătățirea medie a RTT între BBR și CUBIC de peste 200 de milioane de vizionări video YouTube măsurate pe cinci continente pe o perioadă de o săptămână. Mai mult de jumătate din cele 7 miliarde de conexiuni mobile ale lumii sunt conectate pe 2,5G la viteze între 8 și 114 Kbps, cu probleme bine documentate din cauza faptului că tehnicile de control al congestiei pierderii de pachete tind să depășească tampoanele. Blocajul în aceste sisteme este de obicei între SGSN (Serving GPRS Support Node) și dispozitivul mobil. Software-ul SGSN rulează pe o platformă standard de PC cu cantități mari de RAM, unde există adesea megaocteți de buffer între Internet și dispozitivul mobil. Figura 10 compară latența SGSN (emulata) între internet și dispozitivul mobil pentru BBR și CUBIC. Liniile orizontale marchează unele dintre cele mai grave consecințe: TCP se adaptează la întârzieri lungi RTT, cu excepția pachetului SYN care inițiază conexiunea, care are un timeout fix, în funcție de sistemul de operare. Atunci când un dispozitiv mobil primește o cantitate mare de date (de exemplu, de la o actualizare automată a software-ului) printr-un buffer mare SGSN, dispozitivul nu poate stabili nicio conexiune la Internet până când coada nu este golită (pachetul SYN ACK este întârziat mai mult decât timeout fix SYN) .

Figura 9

Figura 10 prezintă modificări mediane de RTT în stare de echilibru față de dimensiunea tamponului pe o conexiune de 128 Kbps, 40 ms cu opt fluxuri BBR (verde) sau CUBIC (roșu). BBR menține coada la valori minime, indiferent de dimensiunea bufferului de blocaj și de numărul de fire active. Fluxurile CUBIC umplu întotdeauna tamponul, astfel încât latența crește liniar cu dimensiunea tamponului.

Figura 10

Banda adaptivă în comunicațiile celulare mobile

Sistemele celulare adaptează lățimea de bandă fiecărui utilizator pe baza parțial pe o prognoză a cererii care ține cont de coada de pachete dedicate utilizatorului respectiv. Versiunile timpurii ale BBR au fost configurate pentru a crea cozi foarte mici, ceea ce face ca conexiunile să se blocheze la viteze reduse. Creșterea valorii de vârf pacing_gain pentru ProbeBW și creșterea cozilor a dus la o scădere a conexiunilor blocate. Acest lucru arată o adaptabilitate excelentă pentru unele rețele. Cu setarea curentă a câștigului de vârf, nu apare nicio degradare în nicio rețea în comparație cu CUBIC.

Pachete întârziate și întinse

Rețelele celulare, WiFi și de bandă largă întârzie adesea și acumulează pachete de confirmare. Când zborul este limitat la un singur BDP, provoacă întreruperi care reduc debitul. Creșterea factorului cwnd_gain al lui ProbeBW la doi a permis transmiterea lină să continue la rata de livrare estimată, chiar și atunci când pachetele de confirmare au fost întârziate la un RTT. Acest lucru previne foarte mult defecțiunile.

Limitatoare de cupe de curent

Implementarea inițială a BBR pe YouTube a arătat că majoritatea furnizorilor de servicii de internet din lume distorsionau traficul folosind limitatoarele actuale de rată a grupului. Bucket-ul este de obicei plin la începutul conexiunii, astfel încât BBR învață parametrul BtlBw pentru rețeaua de bază. Dar odată ce găleata este goală, toate pachetele trimise mai repede decât (mult mai puțin decât BtlBw) rata de umplere a găleții sunt aruncate. BBR învață în cele din urmă această nouă rată de livrare, dar ciclul de câștig al ProbeBW are ca rezultat o pierdere constantă, moderată. Pentru a minimiza pierderea de lățime de bandă în amonte și creșterea latenței aplicației din această pierdere, am adăugat un detector de poliție dedicat și un model de poliție explicit la BBR. De asemenea, studiem în mod activ cele mai bune modalități de a elimina daunele cauzate de limitatoarele de viteză.

Concurența cu metodele de control al congestiei bazate pe pierderea pachetelor

BBR se referă la partajarea echitabilă a lățimii de bandă a blocajului, fie în competiție cu alte fluxuri BBR, fie cu fluxuri controlate prin tehnici de control al congestiei pierderii de pachete. Chiar și atunci când acesta din urmă umple tamponul disponibil, ProbeBW încă schimbă în mod fiabil estimarea BtlBw către partajarea corectă a firelor, iar ProbeRTT consideră estimarea RTProp suficient de mare pentru convergența tit-for-tat la partajarea corectă. Cu toate acestea, buffer-urile de router negestionate mai mari decât unele BDP-uri determină concurenții moșteni cu limitarea congestiei de pierderi de pachete pentru a umfla coada și a captura mai mult decât cota lor echitabilă. Eliminarea acestui lucru este un alt domeniu de cercetare activă.

Concluzie

Regândirea modului în care gestionăm aglomerația aduce beneficii enorme. În loc să utilizeze evenimente precum risipa sau ocuparea tamponului, care sunt doar slab corelate cu congestia, BBR începe cu un model formal de congestie Kleinrock și punctul său de funcționare optim asociat. Concluzia nefericită că este „imposibilă” determinarea simultană a parametrilor critici ai latenței și lățimii de bandă este ocolită de observația că aceștia pot fi prevăzuți simultan. Progresele recente în sistemele de control și teoria estimării sunt apoi aplicate pentru a crea o buclă simplă de control distribuită care se apropie de optim prin utilizarea completă a rețelei, menținând în același timp o coadă mică. Implementarea BBR de la Google este disponibilă în nucleul Linux open source și este descrisă în detaliu în anexa la acest articol.

Tehnologia BBR este utilizată pe coloana vertebrală Google B4, îmbunătățind randamentul cu ordine de mărime în comparație cu CUBIC. De asemenea, se implementează pe serverele web Google și YouTube, reducând semnificativ latența pe toate cele cinci continente testate până în prezent, și mai ales puternic în țările în curs de dezvoltare. Tehnologia BBR operează exclusiv pe partea expeditorului și nu necesită modificări ale protocolului, destinatarului sau rețelei, permițând implementarea acesteia treptat. Depinde doar de notificările RTT și de livrare a pachetelor, așa că poate fi folosit în majoritatea protocoalelor de transport pe Internet.

Mulțumiri

Autorii îi sunt recunoscători lui Len Kleinrock pentru că a subliniat cum să gestionăm corect congestia. Îi suntem datori lui Larry Brakmo pentru munca sa de pionierat asupra sistemelor de control al congestiei Vegas și New Vegas, care au prefigurat multe elemente ale BBR, și pentru sfaturile și îndrumările sale în timpul dezvoltării timpurii a BBR. De asemenea, dorim să mulțumim lui Eric Dumazet, Nandita Dukkipati, Jana Iyengar, Ian Swett, M. Fitz Nowlan, David Wetherall, Leonidas Leonidas Kontothanassis, Amin Vahdat și echipelor de infrastructură Google BwE și YouTube pentru ajutorul și sprijinul neprețuit.

Anexă - descriere detaliată

Mașină de stare pentru sondarea secvențială

Pacing_gain controlează cât de repede sunt trimise pachetele în raport cu BtlBw și este cheia inteligenței BBR. Când pacing_gain este mai mare de unu, în zbor crește și intervalul dintre sosiri de pachete scade, ceea ce mută conexiunea în partea dreaptă din Figura 1. Când pacing_gain este mai mic de unu, are loc efectul opus, conexiunea se deplasează spre stânga.

BBR folosește pacing_gain pentru a implementa o mașină simplă de testare a stării secvențiale care alternează între testarea pentru o lățime de bandă mai mare și testarea pentru un timp de trecere dublu de pachete mai scurt. (Nu este necesar să testați o lățime de bandă mai mică, deoarece este gestionată automat de filtrul BtlBw msx: noile măsurători reflectă căderea, astfel încât BtlBw se va corecta imediat ce ultimele modificări vechi sunt eliminate din filtrul de timeout. RTprop min. filtrul gestionează creșterea căilor de livrare în același mod).

Dacă debitul blocajului crește, BBR-ul trebuie să trimită date mai repede pentru a le detecta. De asemenea, dacă timpul real de călătorie dus-întors al unui pachet se modifică, acest lucru modifică BDP-ul și, astfel, BDP-ul trebuie să trimită date mai lent pentru a menține în zbor sub BDP pentru a măsura noul RTprop. Prin urmare, singura modalitate de a detecta aceste modificări este de a efectua experimente, trimițând mai rapid pentru a testa o creștere a BtlBw sau trimițând mai lent pentru a testa o scădere a RTprop. Frecvența, scara, durata și designul acestor experimente variază în funcție de ceea ce este deja cunoscut (conexiunea rulează vs. starea de echilibru) și de comportamentul aplicației care trimite datele (intermitent vs persistent).

Stare echilibrată

Firele BBR își petrec cea mai mare parte a timpului în starea ProbeBW încercând banda folosind o tehnică numită câștiga ciclism, ceea ce ajută fluxurile BBR să atingă un debit mare, o latență scăzută în coadă și o convergență echitabilă a lățimii de bandă. Folosind câștiga ciclism, BBR parcurge o serie de valori pentru câștig pacing_gain. Opt faze ale ciclului sunt utilizate cu următoarele valori: 5/4, 3/4, 1, 1, 1, 1, 1, 1. Fiecare fază rulează de obicei pentru RTprop prezis. Acest design permite buclei de coeficienți să probeze mai întâi canalul pentru o capacitate mai mare cu o valoare pacing_gain mai mare de 1,0 și apoi dispersați orice coadă rezultată folosind pacing_gain cu aceeași cantitate mai mică de 1,0 și apoi se deplasează la viteza de croazieră cu o coadă scurtă de coeficienți de exact 1,0. Câștigul mediu pentru toate fazele este de 1,0 deoarece ProbeBW tinde spre medie pentru a egaliza lățimea de bandă disponibilă și, prin urmare, să mențină o utilizare ridicată a lățimii de bandă fără a crește coada. Rețineți că, deși ciclurile de rată se modifică pacing_gain, dar sensul cwnd_gain rămâne întotdeauna egal cu doi, deoarece pachetele de ack întârziate și întinse pot apărea în orice moment (vezi capitolul despre pachetele de ack întârziate și întinse).

Mai mult, pentru a îmbunătăți amestecarea firelor de execuție și partajarea echitabilă a lățimii de bandă și pentru a reduce coada de așteptare atunci când mai multe fire de execuție BBR împărtășesc un blocaj, BBR schimbă aleatoriu fazele buclei ProbeBW, selectând aleatoriu prima fază dintre toate, cu excepția valorilor 3/4. De ce nu începe ciclul la 3/4? Scopul principal al acestei valori a coeficientului este de a dispersa orice coadă care se poate forma în timpul aplicării coeficientului 5/4 atunci când canalul este deja plin. Când un proces iese din starea Drain sau ProbeRTT și intră în ProbeBW, nu există nicio coadă, deci factorul 3/4 nu își face treaba. Aplicarea a 3/4 într-un astfel de context are doar un efect negativ: umplerea canalului în această fază va fi 3/4, nu 1. Astfel, începerea unui ciclu cu 3/4 are doar un efect negativ, dar nu pozitiv. , iar din moment ce intrarea în starea ProbeBW are loc la începutul oricărei conexiuni pentru o perioadă lungă de timp, atunci BBR folosește această mică optimizare.

Firele BBR lucrează împreună pentru a goli periodic coada de blocaj folosind o stare numită ProbeRTT. În orice altă stare decât ProbeRTT în sine, dacă estimarea RTProp nu a fost actualizată (de exemplu, prin eșantionarea unui RTT mai mic) mai mult de 10 secunde, atunci BBR intră în starea ProbeRTT și reduce cwnd la o valoare foarte mică (patru pachete). ). Menținând acest număr minim de pachete în zbor timp de cel puțin 200 ms și timp de trecere a unui pachet, BBR iese din starea ProbeRTT și intră fie în Startup, fie în ProbeBW, în funcție de evaluarea sa dacă canalul este deja plin.

BBR este proiectat să funcționeze de cele mai multe ori (aproximativ 98%) în starea ProbeBW și restul timpului în ProbeRTT, pe baza unui set de compromisuri. Starea ProbeRTT durează suficient de mult (cel puțin 200 ms) pentru a permite firelor de execuție cu diferite RTT-uri să aibă stări ProbeRTT paralele, dar, în același timp, durează o perioadă de timp suficient de scurtă pentru a limita atingerea de performanță la aproximativ două procente (200 ms / 10 secunde). ). Fereastra filtrului RTprop (10 secunde) este suficient de mică pentru a se adapta rapid la schimbarea nivelurilor de trafic sau la schimbările rutei, dar suficient de mare pentru aplicații interactive. Astfel de aplicații (de exemplu, pagini web, apeluri de procedură la distanță, fragmente video) prezintă adesea perioade naturale de liniște sau activitate mică în sloturile acestei ferestre, unde debitul este suficient de scăzut sau suficient de lung pentru a dispersa coada într-un blocaj. Apoi, filtrul RTprop se potrivește oportunistic acestor măsurători RTprop, iar RTProp este actualizat fără a fi nevoie să se angajeze ProbeRTT. Astfel, fluxurile de obicei trebuie să sacrifice doar 2% din lățimea de bandă dacă fluxurile multiple umplu puternic canalul pe toată fereastra RTPProp.

Comportamentul la pornire

Când pornește un fir BBR, efectuează primul (și cel mai rapid) proces secvențial de sondare/golire a cozii. Lățimea de bandă a rețelei variază în intervalul 10 12 - de la câțiva biți la 100 gigabiți pe secundă. Pentru a afla valoarea lui BtlBw pentru o astfel de schimbare uriașă a intervalului, BBR efectuează o căutare binară în spațiul de viteză. Găsește foarte repede BtlBw (pachete cu trecere dublă), dar în detrimentul creării unei cozi în 2BDP în ultima etapă a căutării. Căutarea se efectuează în starea Startup în BBR, iar golirea cozii create se realizează în starea Drain.

În primul rând, Startup crește exponențial viteza de trimitere a datelor, dublând-o la fiecare rundă. Pentru a realiza o astfel de tatonare rapidă în cel mai relaxat mod, la pornirea valorilor câștigului pacing_gainȘi cwnd_gain setată la , valoarea minimă care permite ca rata de trimitere a datelor să se dubleze la fiecare rundă. Odată ce canalul este plin, coeficientul cwnd_gain limitează dimensiunea cozii la .

În starea de pornire a conexiunii, BBR evaluează dacă canalul este plin căutând un platou în estimarea BtlBw. Dacă constată că a trecut prin mai multe (trei) runde în care încercarea de a dubla viteza de livrare nu produce cu adevărat o creștere mare a vitezei (mai puțin de 25%), atunci consideră că a ajuns la BtlBw, așa că iese din Starea de pornire și intră în starea de golire. BBR așteaptă trei runde pentru a obține dovezi concludente că platoul ratei de livrare observat de expeditor nu este un efect temporar al ferestrei de primire. Așteptarea a trei runde permite suficient timp pentru acordarea automată din partea destinatarului pentru a deschide fereastra de primire și pentru ca expeditorul BBR să detecteze necesitatea creșterii BtlBw: în prima rundă, algoritmul de reglare automată pentru fereastra de recepție mărește fereastra de primire; în a doua rundă, expeditorul umple fereastra de primire mărită; în a treia rundă, expeditorul primește mostre cu o viteză de livrare crescută. Această limită de trei runde s-a dovedit pe baza rezultatelor implementării sale pe YouTube.

În starea Drain, algoritmul BBR încearcă să golească rapid coada care s-a format în starea de pornire a conexiunii prin trecerea la pacing_gain cu valori inverse față de cele utilizate în starea de pornire. Când numărul de pachete aflate în zbor se potrivește cu estimarea BDP, aceasta înseamnă că BBR estimează coada complet goală, dar canalul este încă plin. Apoi BBR părăsește starea Drain și intră în ProbeBW.

Rețineți că pornirea conexiunii BBR și pornirea lentă CUBIC explorează exponențial debitul de blocaj, dublând rata de trimitere în fiecare rundă. Cu toate acestea, ele sunt radical diferite. În primul rând, BBR determină mai fiabil lățimea de bandă disponibilă, deoarece nu oprește căutarea în cazul pierderii pachetelor sau (precum Hystart de la CUBIC) a unei latențe crescute. În al doilea rând, BBR crește fără probleme viteza de trimitere, în timp ce CUBIC are o explozie de pachete la fiecare rundă (chiar și cu ritm) și apoi o perioadă de liniște. Figura 4 arată numărul de pachete în zbor și timpul RTT observat pentru fiecare mesaj de confirmare pentru BBR și CUBIC.

Răspunsul la situațiile de tranziție

Calea rețelei și traficul care circulă de-a lungul ei pot suferi schimbări bruște, dramatice. Pentru a se adapta la acestea fără probleme și în mod fiabil și pentru a reduce pierderea de pachete în aceste situații, BBR utilizează o serie de strategii pentru a implementa modelul său de bază. În primul rând, BBR consideră scopul către care curentul cwnd se apropie cu grijă de jos, crescând cwnd de fiecare dată nu mai mult decât cantitatea de date pentru care au fost primite confirmări de livrare. În al doilea rând, la un timeout de retransmisie, ceea ce înseamnă că expeditorul consideră că toate pachetele aflate în zbor sunt pierdute, BBR reduce în mod conservator cwnd până la un pachet și trimite un singur pachet (la fel ca algoritmii de control al congestionării pierderii pachetelor, cum ar fi CUBIC). În sfârșit, atunci când expeditorul observă o pierdere de pachet, dar mai sunt pachete în zbor, în prima etapă a procesului de recuperare a pierderii, BBR reduce temporar rata de expediere la rata de livrare curentă; în a doua și următoarele runde de recuperare a pierderilor, verifică dacă rata de expediere nu este niciodată mai mare de dublul ratei de livrare actuale. Acest lucru reduce semnificativ pierderile în situații tranzitorii când BBR întâlnește limitatori de rată sau concurează cu alte fluxuri într-un tampon de dimensiuni comparabile cu BDP.

Legături

1. Abrahamsson, M. 2015. Suprimarea TCP ACK. lista de corespondență IETF AQM;