QUIC-protokoll töös: kuidas Uber seda rakendas jõudluse optimeerimiseks

QUIC-protokolli jälgimine on äärmiselt huvitav, mistõttu me armastame sellest kirjutada. Kui varasemad publikatsioonid QUIC-ist kandsid rohkem ajaloolist (kui soovite, ka kultuurilist) iseloomu ja teooriat, siis täna oleme rõõmsad, et saame avaldada tõlke, mis käsitleb protokolli tegelikku rakendust 2019. aastal. Ja see ei puuduta väikeseid infrastruktuure, mis põhinevad tinglikul garaažil, vaid Uberit, mis tegutseb peaaegu üle kogu maailma. Kuidas ettevõtte insenerid otsustasid minna QUIC-i kasutamisega tootmisesse, milliseid teste nad läbi viisid ja mida nad pärast tootmisse viimist nägid – loe allpool.

Pildid on klikatavad. Head lugemist!

Uber – see on globaalne kohalolek, nimelt 600 linna, kus igas rakendus toetub täielikult enam kui 4500 mobiilioperaatori juhtmevaba internetile. Kasutajad ootavad, et rakendus töötab mitte ainult kiiresti, vaid reaalajas – selle tagamiseks vajab Uberi rakendus madalat latentsust ja väga usaldusväärset ühendust. Kahjuks, aga tehnoloogia... HTTP/2 halvab energiaga dünaamilistes ja kaotuste suhtes altid juhtmeteta võrkudes. Oleme mõistnud, et antud juhul on madal jõudlus otseselt seotud TCP rakendustega operatsioonisüsteemide kernades.

Probleemi lahendamiseks kasutasime QUIC, kaasaegset protokolli kanalite mitmekordistamiseks, mis annab meile rohkem kontrolli transportprotokolli jõudluse üle. Praegu töötab rühm IETF standardisiseerib QUIC kui HTTP/3.

Pärast põhjalikke katseid oleme jõudnud järeldusele, et QUIC'i rakendamine meie rakenduses vähendab "sabade" viivitusi võrreldes TCP-ga. Oleme märganud, et HTTPSi liikluses oli langus vahemikus 10-30% juhi- ja reisija rakenduse näitel. Lisaks andis QUIC meile täieliku kontrolli kasutajapakettide üle.

Selles artiklis jagame kogemusi TCP optimeerimisest Uberi rakendustes QUIC-i toetava kuhja abil.

Tehnika viimane sõna: TCP

Täna on TCP kõige laialdasemalt kasutatav transportprotokoll HTTPS-i liikluse edastamiseks internetis. TCP tagab usaldusväärse byte'ide voolu, millega ta suudab toime tulla võrgu ülekoormuse ja kühveldamise kaotustega. TCP laialdane kasutamine HTTPS-i liikluses selgitab selle omnipresentse kohaloleku (peaaegu igas opsüsteemis on TCP), saadavuse suuremas osas infrastruktuurist (näiteks koormuse tasakaalustajad, HTTPS-proksid ja CDN) ning „kastist välja“ funktsionaalsus, mis on enamikes platvormides ja võrkudes peaaegu alati olemas.

Enamik kasutajaid kasutab meie rakendust teel olles ja TCP „sabas” esinevad viivitused ei olnud kaugeltki meie reaalajas HTTPS-i liikluse nõuded. Lihtsalt öeldes, on selle probleemiga silmitsi seisnud kasutajad üle kogu maailma – Joonisel 1 on kajastatud viivitused suurtes linnades:

Joonis 1. „Saba” viivituse suurus varieerub Uberi kohaloleku peamistes linnades.

Kuigi viivitused India ja Brasiilia võrkudes olid suuremad kui USA ja Ühendkuningriigis, olid sabaviivitused siiski oluliselt suuremad kui keskmised viivitused. Ja see kehtib ka USA ja Ühendkuningriigi kohta.

TCP jõudlus õhus

TCP on loodud kaablivõrkude jaoks, mis tähendab, et see keskendub hästi prognoositavatele linkidele. Kuid traadita võrkudel on oma eripärad ja raskused. Esiteks, traadita võrgud on tundlikud kaotustele, mis on põhjustatud häiretest ja signaali nõrgenemisest. Näiteks on Wi-Fi võrgud tundlikud mikrolainele, Bluetoothile ja muudele raadiolainetele. Mobiilsete võrkude signaal kaob ( teekonna kadumine) objekti ja hoonete tõttu signaali peegeldumise / neeldumise tõttu ning samutihäirete tõttu naabervõrkudest mobiilitornidelt . See toob kaasa märkimisväärselt (4–10 korda) ja mitmekesiseidringiküljed (RTT) ja pakettide kaod võrreldes kaabliühendusega. Kuna mobiilivõrkude lairibavõime ja kadude kõikumisega võitlemiseks kasutatakse tavaliselt suuri puhverdusi liikluspiikide jaoks. See võib põhjustada liialdatud järjestust, mis tähendab suuremaid viiteid. Tihti tõlgendab TCP sellist järjestust kaotuseks pikema ooteaja tõttu, seetõttu on TCP kalduv tegema edasisi ülekandeid ja täitma niiviisi puhverdust. See probleem on tuntud kui

liigne võrgu puhverdamine, puhverdamise paisumine bufferbloat (), ja see on vägatõsine probleem tõsine probleem kaasaegse interneti.

Lõpuks muutub mobiilsidevõrgu jõudlus sõltuvalt operaatorist, piirkonnast ja ajast. Joonisel 2 on kogutud HTTPS-liikluse mediaanlatentsus 2 km raadiuses asuvate mobiilside baasjaamade kohta. Andmed on kogutud kahe suurema mobiilioperaatori kohta Delhis, Indias. Nagu märgata, varieerub jõudlus jaamade vahel. Samuti on ühe operaatori jõudlus erinev teise operaatori jõudlusest. Sellele mõjuvad tegurid, nagu võrku sisenemise mustrid ajastuse ja asukoha järgi, kasutajate liikuvus ning võrgu infrastruktuur arvestades tugede tihedust ja võrgu tüüpide (LTE, 3G jne) suhet.

Joonis 2. Latentsus 2-kilomeetrise raadiuse näitel. Delhi, India.

Samuti muutub mobiilsidevõrkude jõudlus ajas. Joonisel 3 on näidatud mediaanlatentsus nädalapäevade kaupa. Me oleme ka märganud erinevusi väiksemal skaalal – ühe päeva ja tunni jooksul.

Joonis 3. Ahnustav latentsus võib nädalapäevade lõikes märkimisväärselt varieeruda, kuid sama operaatori puhul.

Kõik eeltoodud asjaolud viivad selleni, et TCP töötlus ei ole tõhus traadita võrkudes. Enne kui otsime TCP alternatiive, soovime selgitada järgmisi punkte:

• Kas TCP on meie rakendustes peamine viivitusallikas?
• Kas kaasaegsetes võrkudes esineb märkimisväärseid ja mitmekesiseid ringviivitusi (RTT)?
• Milline on RTT ja kaotuste mõju TCP jõudlusele?

TCP jõudluse analüüs

Kuna me analüüsisime TCP jõudlust, tuletame meelde, kuidas TCP andmeid saatjast saajani edastab. Esmalt loob saatja TCP-ühenduse, tehes kolmeastmelise käepigistuse: saatja saadab SYN-paketi, ootab saajalt SYN-ACK-paketti ja seejärel saadab ACK-paketi. Ühenduse loomisele kulub veel lisaks teine ja kolmas läbimine. Saaja kinnitab iga paketi vastuvõtmist (ACK), et tagada usaldusväärne edastus.

Kui pakett või ACK kaob, teeb saatja ajavahemiku pärast edastuse korduse (RTO, edastusajad). RTO arvutatakse dünaamiliselt, tuginedes erinevatele teguritele, näiteks eeldatavale RTT viivitusele saatja ja vastuvõtja vahel.

Joonis 4. TCP/TLS paketivahetus hõlmab retranšmitmehhanisme.

Kohandamaks, kuidas TCP meie rakendustes töötas, jälgisime TCP-pakette tcpdump nädala jooksul tootmisliikluses, mis tuli India piiriserveritest. Seejärel analüüsisime TCP-ühendusi kasutades tcptrace. Lisaks lõime Android-rakenduse, mis saadab emuleeritud liiklust testserverile, maksimaalselt jäljendades tegelikku liiklust. Nutitelefonid, millel oli see rakendus, jagati mitmele töötajale, kes kogusid logisid mitme päeva jooksul.

Mõlema katse tulemused olid omavahel kooskõlas. Nägime kõrgeid RTT-viivitusi; sabaväärtused olid peaaegu kuus korda kõrgemad kui mediaanväärtus; viivituste keskmine väärtus oli üle ühe sekundi. Paljudel ühendustel esines kaotusi, mis sundis TCP-d taasülekandma 3,5% kõikidest pakettidest. Ülekoormatud piirkondades, nagu lennujaamad ja jaamad, täheldasime 7% kaotusi. Sellised tulemused panevad kahtlema levinud arvamuses, et mobiilivõrkudes kasutatavad tippjõudlusega edastamisvõtted vähendavad oluliselt kaotusi transporditasandil. Allpool on testi tulemused simulaatori rakendusest:

Võrgumõõdikud
Väärtused

RTT, millisekundid [50%, 75%, 95%, 99%]
[350, 425, 725, 2300]

RTT-variance, sekundid
Keskmiselt ~1,2 s

Pakettide kaotus ebastabiilsetes ühendustes
Keskmiselt ~3,5% (7% ülekoormatud piirkondades)

Peaaegu pooltel nendest ühendustest oli vähemalt üks pakett kaotatud, enamik neist olid SYN ja SYN-ACK paketid. Enamik TCP rakendusi kasutab SYN-pakettide jaoks RTO väärtust 1 sekund, mis suureneb eksponentsiaalselt järgnevate kaotuste korral. Rakenduse laadimise aeg võib pikeneda, kuna TCP vajab rohkem aega ühenduste seadmiseks.

Andmepakettide puhul alandavad kõrged RTO väärtused oluliselt võrgu tõhusust ajutiste kaotuste korral traadita võrkudes. Me leidsime, et keskmine retransmissioni aeg on umbes 1 sekund koos lõpukuulamisega peaaegu 30 sekundit. Sellised kõrged viivitused TCP tasandil põhjustasid HTTPS-aega-out’e ja uuesti päringuid, mis suurendas veelgi viivitust ja võrgu ebaefektiivsust.

Kuigi 75. protsentiil mõõdetud RTT-st oli umbes 425 ms, oli TCP jaoks 75. protsentiil peaaegu 3 sekundit. See vihjab sellele, et kaotused sundisid TCP-d tegema 7-10 läbimist, et andmeid edukalt edastada. See võib olla tingitud RTO ebaefektiivsest arvutamisest ja TCP võimetusest kiiresti reageerida kaotusele. viimaste pakettide aknades ja ülekande koormuse haldamise algoritmi efektiivsus, mis ei erista traadita kaotusi ja võrgu ülekoormusest tingitud kaotusi. Allpool on TCP kaotuste testitulemused:

TCP pakettide kaotuse statistika
Väärtus

Protsent ühendustest, millel on vähemalt 1 paketi kaotus
45%

Protsent ühendustest, millel on kaotusi ühenduse loomise ajal
30%

Protsent ühendustest, millel on kaotusi andmevahetuse ajal
76%

Viivituse jaotumine edasisaatmisel, sekundid [50%, 75%, 95%, 99%]
[1, 2.8, 15, 28]

Üksiku paketi või TCP-segmendi edasisaatmise kordade jaotumine
[1,3,6,7]

QUIC rakendamine

Algusest peale Google'i loodud, QUIC on mitme keermega kaasaegne transpordiprotokoll, mis töötab UDP peal. Praegu on QUIC standardeerimise protsessis (oleme juba kirjutanud, et QUIC-l on sisuliselt kaks versiooni, uudishimulikud võivad minna lingile – tõlkija märkus). Nagu on näidatud Joonisel 5, paikneb QUIC HTTP/3 all (tegelikult on HTTP/2 QUIC-i peal HTTP/3, mida praegu aktiivselt standardiseeritakse). See asendab osaliselt HTTPS-i ja TCP tasemed, kasutades pakettide vormistamiseks UDP-d. QUIC toetab ainult turvalist andmeedastust, kuna TLS on täielikult integreeritud QUIC-i.

Joonis 5: QUIC töötab HTTP/3 all, asendades TLS-i, mis varem töötas HTTP/2 all.

Allpool toome välja põhjused, mis veensid meid QUIC-i kasutama TCP tugevdamiseks:

• 0-RTT ühenduse loomine. QUIC võimaldab eelneva ühenduse autoriseerimiste taaskasutamist, vähendades turvahandshake'ide arvu. Tulevikus TLS1.3 toetab 0-RTT, kuid kolmik TCP-handshake jääb siiski kohustuslikuks.
• HoL-blokeeringu ületamine. HTTP/2 kasutab iga kliendi jaoks ühte TCP-ühendust, et parandada jõudlust, kuid see võib põhjustada HoL (head-of-line) blokeeringut. QUIC lihtsustab multipleximist ja edastab päringud rakendusse üksteisest sõltumatult.
• ülekande haldamine. QUIC on rakendustaseme protokoll, mis võimaldab peamiseks transportprotokolliks, mis haldab andmete saatmist, paremini ajakohastada, tuginedes võrguparametritele (kaotuste arv või RTT). Enamiku TCP-implementatsioonide puhul kasutatakse algoritmi CUBIC, mis ei ole optimaalne viivitustele tundlikule liiklusele. Hiljuti välja töötatud algoritmid nagu BBR, modelleerivad võrku täpsemalt ja optimeerivad viivitusi. QUIC võimaldab kasutada BBR-i ja ajakohastada seda algoritmi selle parandamise käigus. kaotuste täiendamine..
• QUIC kutsub esile kaks TLP-d ( tail loss probe) enne, kui RTO aktiveerub – isegi kui kaotused on väga tajutavad. See erineb TCP-implementatsioonidest. TLP edastab peamiselt viimase paketi (või uue, kui selline on olemas), et alustada kiiret täiendamist. Hääbuvate viivituste käsitlemine on eriti kasulik, kuidas Uber võrku kasutab, nimelt lühikeste, perioodiliste ja viivitustele tundlike andmesideedastuste jaoks.optimeeritud ACK.
• Kuna igal paketti on ainulaadne järjestusnumber, ei teki probleemi eristamisega. eristamine pakettide edastamisel. ACK-paketid sisaldavad samuti paketi töötlemise aega ja ACK genereerimise aega kliendi poolel. Need omadused tagavad, et QUIC arvutab RTT-d täpsemalt. ACK QUIC-is toetab kuni 256 vahemikku. NACK, aidates saatjat paremini pakettide ümberpaigutumise suhtes taluda ja vähendada protsessis kasutatavaid bite. Valikuline ACK (SACK) TCP-s ei lahenda seda probleemi kõikides olukordades.
• ühenduse migreerimine. QUIC-ühendused tuvastatakse 64-bitise ID abil, nii et kui klient muudab IP-aadresse, saab vanat ühenduse ID-d uue IP-aadressiga edasi kasutada ilma katkemisteta. See on mobiilirakendustes väga levinud praktika, kui kasutaja vahetab Wi-Fi ja mobiilsete ühenduste vahel.

QUIC-i alternatiivid

Oleme kaalunud alternatiivseid lähenemisviise probleemi lahendamiseks, enne kui valisime QUIC-i.

Esimene asi, mida me proovisime, oli TPC PoP'ide (Presence Points) käivitamine, et lõpetada TCP-ühendusi lähemal kasutajatele. Sisuliselt lõpetab PoP TCP-ühenduse mobiilseadme lähedal mobiilivõrgu kaudu ja edastab liikluse tagasi algse infrastruktuuri. TCP lähemal lõpetades suudame potentsiaalselt vähendada RTT-d ja olla kindlad, et TCP reageerib aktiivsemalt dünaamilisele traadita keskonnale. Siiski näitasid meie katsed, et enamik RTT-st ja kadusid tulevad mobiilivõrkudest ning PoP-ide kasutamine ei too märkimisväärset täiustamist jõudluselt.

Me oleme samuti kaalunud TCP parameetrite täiustamist. TCP-steki seadistamine meie heterogeensetes piiriservers on olnud keeruline, kuna TCP-l on erinevates OS versioonides ühitamatud rakendused. Erinevate võrgukonfiguratsioonide rakendamine ja testimine on olnud keeruline. TCP seadmine otse mobiilsetes seadmetes oli võimatu, kuna puudusid õigused. Veelgi olulisem on, et sellised funktsioonid nagu 0-RTT ühendused ja täiustatud RTT ennustamine on protokolli arhitektuuri jaoks kriitilise tähtsusega ning seega ei saa TCP seadistamisega olulisi eeliseid saavutada.

Lõpuks hindasime mitmeid UDP-põhiseid protokolle, mis lahendavad probleemid videovoogesituses – soovisime teada, kas need protokollid aitavad meie puhul. Kahjuks puudusid neil paljud turvaseaded ning nad vajasid lisaks TCP ühendust metaandmete ja juhtimisteabe jaoks.

Meie uurimised näitasid, et QUIC on ilmselt ainus protokoll, mis suudab aidata Interneti-liikluse probleemide lahendamisel, arvestades nii turvalisuse kui ka jõudlusega.

QUIC integreerimine platvormile

QUIC-i edukaks integreerimiseks ja rakenduse jõudluse parandamiseks halva ühenduvuse tingimustes asendasime vana steki (HTTP/2 TLS-i/TCP-i peal) QUIC protokolliga. Kasutasime võrgu raamatukogu Cronet kohast Chromium Projects, mis sisaldab originaalset, Google'i versiooni protokollist – gQUIC. See teostus täiustatakse pidevalt, et järgida viimast IETF spetsifikatsiooni.

Esmalt integreerisime Croneti oma Android-rakendustesse, et lisada QUIC-i tugi. Integreerimine viidi läbi nii, et minimeerida migratsioonikulud. Selle asemel, et täielikult asendada vana võrgu redaktori, mis kasutas teeki OkHttp, integreerisime Croneti OkHttp API raamistiku ALL. Sel viisil integreerides vältisime muudatusi meie võrgu päringutes (mida kasutavad Retrofit) API tasemel.

Sarnaselt lähenemisele Android-seadmetele, oleme integreerinud Croneti Uberi rakendustesse iOS-is, suunates HTTP-liiklust võrgu API, kasutades NSURLProtocol. See iOS Foundation'i pakutud abstraktsioon töötleb protokollispetsiifilisi URL-andmeid ja tagab, et saame Croneti integreerida oma iOS-rakendustesse ilma oluliste migratsioonikuludeta.

QUIC-i lõpetamine Google Cloud-i koormustasemetel

Google Cloud Load balancing infrastruktuuri abil on QUIC-i lõpetamine tagaplaanil kindlustatud, mis kasutab alt-svc vastustes pealkirju QUIC-i toetamiseks. Üldiselt lisab koormustaseme iga HTTP-päringule alt-svc pealkirja ja valideerib siis domeeni QUIC-i toetust. Kui klient Cronet saab HTTP-vastuse sellise pealkirjaga, kasutab ta QUIC-i järgnevate HTTP-päringute jaoks sellele domeenile. Kui koormustase lõpetab QUIC-i, saadab meie infrastruktuur selle tegevuse selgelt HTTP2/TCP kaudu meie andmekeskustesse.

Tulemus: tulemused

Toodetud tulemus on meie peamine põhjus otsida parimat protokolli. Alustuseks lõime labori võrgu emuleerimisega, et uurida, kuidas QUIC erinevates võrguprofiilides käitub. QUIC-i toimivuse kontrollimiseks reaalses võrgus viisime läbi katseid, sõites läbi Delhi, kasutades samas emuleeritud võrgu liiklust, mis on väga sarnane HTTP-kutsetele reisija rakenduses.

Eksperiment 1

Katse inventar:

• Androidi testseadmed OkHttp ja Cronet'i hunnikutega, et veenduda, et suuname HTTPS-liiklust vastavalt TCP ja QUIC kaudu;
• Java-põhine emulatsiooniserver, mis saadab sarnaseid HTTPS-pealkirju vastustes ja koormab kliendiseadmeid, et saada neilt päringuid;
• pilvepõhised proksid, mis asuvad füüsiliselt India lähedal, et lõpetada TCP ja QUIC ühendused. Kuigi TCP lõpetamiseks kasutasime tagapoolt proksit, NGINX, oli raske leida avatud lähtekoodiga tagapoolt proksit QUIC-ile. Kogusime ise QUIC-i tagapoolt proksi, kasutades Chromiumi põhihunnikut ja avalikustasid seda Chromiumis avatud lähtekoodina.

Joonis 6. TCP vs QUIC testide komplekt koosnes Android-seadmetest OkHttp ja Cronet'i ning pilvepõhistest proksidest ühenduste lõpetamiseks ja emulatsiooniserverist.

Eksperiment 2

Kui Google tegi QUIC-i kergesti kättesaadavaks Google Cloud Load Balancing, me kasutasime sama inventari, kuid ühe muudatusega: NGINX-i asemel kasutasime Google'i koormuse jagajaid TCP- ja QUIC-ühenduste lõpetamiseks seadmetelt ning HTTPS-i liikluse suunamiseks emulatsiooniserverisse. Koormuse jagajad on jaotatud kogu maailmas, kuid kasutavad seadmele lähimat PoP-serverit (täname geolokatsiooni eest).

Joonis 7. Teises eksperimendis soovisime võrrelda TCP ja QUIC lõpetamise viivitust: Google Cloudi ja meie pilveproksi abil.

Lõpuks ootasime meid ees mitmed avastused:

• PoP kaudu lõpetamine parandas TCP jõudlust. Kuna koormuse jagajad lõpetavad TCP-ühenduse lähemal kasutajatele ja on suurepäraselt optimeeritud, toob see kaasa väiksemad RTT-d, mis parandab TCP jõudlust. Ja kuigi see mõjutas QUIC-i vähem, jäi see siiski TCP-le ette tagasiviivituste vähendamisel (10–30 protsenti).
• tagasiviivitusi mõjutavad võrgu üleminekud (hops). Kuigi meie QUIC-proksi viibis seadmetest kaugemal (umbes 50 ms kõrgem latentsus) kui Google'i tasakaalustajad, pakkus see sarnast jõudlust – latentsuse langus 15% võrreldes 20% langusega 99. percenti TCP puhul. See näitab, et viimase miili vahetus on võrgu töötluses kitsaskohaks.

Joonis 8. Kahe katse tulemused näitavad, et QUIC ületabTCP-d oluliselt.

Reaalne liiklus

Katsed inspireerisid meid rakendama QUICi meie Androidi ja iOS-i rakendustes. Viisime läbi A/B testimise, et määrata QUICi mõju Uberi kohalolekuga linnades. Üldiselt nägime märkimisväärset vähenemist saba latentsuses eri piirkondades, operaatorite seas ja võrgu tüüpide lõikes.

Allpool oleval graafikul on näidatud protsentuaalsed parandused sabades (95 ja 99 percenti) makroregioonide ja erinevate võrgu tüüpide – LTE, 3G, 2G – lõikes.

Joonis 9. Reaalsetes testides ületas QUIC TCP-d latentsuse poolest.

Ainult edasi

Võib-olla on see alles algus – QUICi juurutamine tootmisse on pakkunud uskumatu võimalusi rakenduste jõudluse parandamiseks nii stabiilsetes kui ka ebastabiilsetes võrkudes, sealhulgas:

Katvuse suurenemine

Analüüsides protokolli jõudlust reaalses liikluses, oleme näinud, et umbes 80% sessioonidest kasutas QUIC-i edukalt keskkondades ja projekti klastrites. Selline põhimõte on õige küsitlusteks, samas kui 15% sessioonidest kasutas kombinatsiooni QUIC-ist ja TCP-st. Eeldame, et see kombinatsioon tekkis seetõttu, et Cronet'i teek vahetab tagasi TCP-ks timeout'i tõttu, kuna ta ei suuda eristada tõelisi UDP-rikkeid ja halbu võrgu tingimusi. Praegu otsime lahendust sellele probleemile, samas kui töötame QUIC-i edasise rakendamise kallal.

QUIC-i optimeerimine

Mobiilirakendustest pärinev liiklus on viivituste suhtes tundlik, kuid mitte ribalaiuse suhtes. Lisaks kasutatakse meie rakendusi peamiselt mobiilivõrkudes. Katsed näitavad, et sabaviivitused on endiselt suured, isegi hoolimata TCP ja QUIC lõpuleviimisest vahetult kasutajate lähedal. Otsime aktiivselt viise, et parandada koormuse juhtimist ja suurendada QUIC-i kaotusetaastamise efektiivsust.

Nende ja mõnede muude täiustustega plaanime parandada kasutajakogemust sõltumata võrgust ja piirkonnast, muutes pakettide sujuva ja mugava edastamise globaalselt kergemini kättesaadavaks.

Allikas: habr.com