QUIC-protokolli on äärmiselt huvitav jälgida, mistõttu meile meeldib sellest kirjutada. Aga kui varasemad väljaanded QUICi kohta olid pigem ajalooline (kui soovite kodulooline) olemus ja riistvara, siis täna avaldame hea meelega teistsuguse tõlke - protokolli reaalsest rakendamisest räägime 2019. aastal. Pealegi ei räägi me nn garaažis põhinevast väikesest taristust, vaid Uberist, mis tegutseb peaaegu kõikjal maailmas. Kuidas ettevõtte insenerid otsustasid QUIC-i tootmises kasutada, kuidas nad katseid läbi viisid ja mida nad nägid pärast selle tootmises kasutuselevõttu – lõikest allpool.
Pildid on klikitavad. Nautige lugemist!
Uberil on ülemaailmne mastaap, nimelt 600 kohalolekulinna, millest igaühes toetub rakendus täielikult enam kui 4500 mobiilsideoperaatori traadita Internetile. Kasutajad eeldavad, et äpp pole lihtsalt kiire, vaid reaalajas – selle saavutamiseks vajab Uberi rakendus madalat latentsust ja väga töökindlat ühendust. Paraku, aga virn ei tööta hästi dünaamilistes ja kadudetundlikes traadita võrkudes. Mõistsime, et antud juhul on madal jõudlus otseselt seotud TCP-rakendustega operatsioonisüsteemi tuumades.
Probleemi lahendamiseks taotlesime , kaasaegne kanalite multipleksimise protokoll, mis annab meile suurema kontrolli transpordiprotokolli toimivuse üle. Hetkel töörühm standardib QUIC as .
Pärast ulatuslikku testimist jõudsime järeldusele, et QUIC-i rakendamine meie rakenduses tooks kaasa madalama latentsusaega võrreldes TCP-ga. Märkasime juhi ja reisijate rakendustes HTTPS-i liikluse vähenemist 10–30%. QUIC andis meile ka täieliku kontrolli kasutajapakettide üle.
Selles artiklis jagame oma kogemusi TCP optimeerimisel Uberi rakenduste jaoks, kasutades QUIC-i toetavat pinu.
Uusim tehnoloogia: TCP
Tänapäeval on TCP enimkasutatav transpordiprotokoll HTTPS-i liikluse edastamiseks Internetis. TCP pakub usaldusväärset baitide voogu, mis aitab toime tulla võrgu ülekoormuse ja lingikihi kadudega. TCP laialdane kasutamine HTTPS-i liikluse jaoks on tingitud esimese levikust (peaaegu iga OS sisaldab TCP-d), saadavusest enamikus infrastruktuurides (nt koormuse tasakaalustajad, HTTPS-i puhverserverid ja CDN-id) ja saadaolevatest kasutusvalmis funktsioonidest. peaaegu enamikul platvormidel ja võrkudel.
Enamik kasutajaid kasutab meie rakendust liikvel olles ja TCP saba latentsusaeg ei vastanud meie reaalajas HTTPS-i liikluse nõuetele. Lihtsamalt öeldes on kasutajad üle kogu maailma seda kogenud – joonisel 1 on näidatud viivitused suuremates linnades:
Joonis 1. Saba latentsus on Uberi peamistes linnades erinev.
Kuigi India ja Brasiilia võrkude latentsusaeg oli kõrgem kui USA-s ja Ühendkuningriigis, on saba latentsusaeg keskmisest oluliselt kõrgem. Ja see kehtib isegi USA ja Ühendkuningriigi kohta.
TCP üle õhu jõudlus
TCP loodi jaoks ühendatud võrgustikud, st rõhuasetusega väga prognoositavatel linkidel. Kuid, juhtmevaba võrkudel on oma eripärad ja raskused. Esiteks on traadita võrgud vastuvõtlikud häirete ja signaali sumbumise tõttu kadudele. Näiteks Wi-Fi võrgud on tundlikud mikrolainete, Bluetoothi ja muude raadiolainete suhtes. Mobiilsidevõrgud kannatavad signaali kadumise () signaali peegeldumise/neeldumise tõttu objektide ja ehitiste poolt, samuti alates naabrist . See toob kaasa olulisema (4-10 korda) ja mitmekesisema ja pakettakad võrreldes juhtmega ühendusega.
Ribalaiuse kõikumiste ja kadude vastu võitlemiseks kasutavad mobiilsidevõrgud tavaliselt liikluspakettide jaoks suuri puhvreid. See võib kaasa tuua liigse järjekorra, mis tähendab pikemaid viivitusi. Väga sageli käsitleb TCP seda järjekorda pikenenud ajalõpu tõttu raiskamisena, nii et TCP kipub edastama ja seeläbi puhvrit täitma. See probleem on tuntud kui () ja see on väga kaasaegne Internet.
Lõpuks sõltub mobiilsidevõrgu jõudlus operaatorist, piirkonnast ja ajast. Joonisel 2 kogusime HTTPS-i liikluse keskmised viivitused lahtrite vahel 2-kilomeetrise vahemikus. Andmed koguti kahe suurema mobiilsideoperaatori kohta Indias Delhis. Nagu näete, on jõudlus lahtriti erinev. Samuti erineb ühe operaatori tootlikkus teise tootlikkusest. Seda mõjutavad sellised tegurid nagu võrgu sisenemise mustrid, võttes arvesse aega ja asukohta, kasutajate mobiilsus, samuti võrgu infrastruktuur, mis võtab arvesse tornitihedust ja võrgutüüpide suhet (LTE, 3G jne).
Joonis 2. Viivitused, kasutades näitena 2 km raadiust. Delhi, India.
Samuti varieerub mobiilsidevõrkude jõudlus aja jooksul. Joonisel 3 on näidatud keskmine latentsusaeg nädalapäevade kaupa. Samuti täheldasime erinevusi väiksemas ulatuses, ühe päeva ja tunni jooksul.
Joonis 3. Saba viivitused võivad päevade lõikes oluliselt erineda, kuid sama operaatori puhul.
Kõik ülaltoodud asjaolud põhjustavad TCP jõudluse traadita võrkudes ebaefektiivseks. Kuid enne TCP-le alternatiivide otsimist soovisime välja töötada täpse arusaamise järgmistest punktidest:
- kas TCP on meie rakenduste saba latentsusaja peamine süüdlane?
- Kas tänapäevastel võrkudel on märkimisväärsed ja mitmekesised edasi-tagasi viivitused (RTT)?
- Milline on RTT ja kaotuse mõju TCP jõudlusele?
TCP jõudluse analüüs
Et mõista, kuidas me TCP jõudlust analüüsisime, vaatame lühidalt, kuidas TCP edastab andmeid saatjalt vastuvõtjale. Esiteks loob saatja kolmesuunalise TCP-ühenduse : Saatja saadab SYN-paketi, ootab vastuvõtjalt SYN-ACK-paketti, seejärel saadab ACK-paketi. Täiendav teine ja kolmas läbimine kulub TCP-ühenduse loomiseks. Usaldusväärse kohaletoimetamise tagamiseks kinnitab saaja iga paketi kättesaamist (ACK).
Kui pakett või ACK kaob, saadab saatja pärast ajalõpu (RTO, ). RTO arvutatakse dünaamiliselt erinevate tegurite alusel, nagu eeldatav RTT viivitus saatja ja saaja vahel.
Joonis 4. Pakettvahetus TCP/TLS-i kaudu sisaldab kordusedastusmehhanismi.
Et teha kindlaks, kuidas TCP meie rakendustes toimis, jälgisime TCP-pakette kasutades nädalaks India servaserveritest tuleva lahinguliikluse kohta. Seejärel analüüsisime TCP-ühendusi kasutades . Lisaks lõime Androidi rakenduse, mis saadab emuleeritud liikluse testserverisse, imiteerides nii palju kui võimalik tegelikku liiklust. Selle rakendusega nutitelefone jagati mitmele töötajale, kes kogusid logisid mitme päeva jooksul.
Mõlema katse tulemused olid üksteisega kooskõlas. Nägime suurt RTT latentsust; saba väärtused olid peaaegu 6 korda suuremad kui keskmine väärtus; viivituste aritmeetiline keskmine on üle 1 sekundi. Paljud ühendused olid kadudega, mistõttu TCP edastas uuesti 3,5% kõigist pakettidest. Ülekoormatud piirkondades, nagu lennujaamad ja rongijaamad, nägime 7% kahjumit. Need tulemused seavad kahtluse alla mobiilsidevõrkudes kasutatavate tavapäraste tarkuste oluliselt vähendada kadusid transpordi tasandil. Allpool on rakenduse "simulaator" testitulemused:
Võrgumõõdikud
Väärtused
RTT, millisekundid [50%, 75%, 95%, 99%]
[350, 425, 725, 2300]
RTT lahknemine sekundites
Keskmiselt ~1,2 s
Pakettide kadu ebastabiilsete ühenduste korral
Keskmine ~3.5% (7% ülekoormatud aladel)
Peaaegu pooltel neist ühendustest oli vähemalt üks paketikadu, enamik neist olid SYN ja SYN-ACK paketid. Enamik TCP-rakendusi kasutab SYN-pakettide jaoks RTO väärtust 1 sekund, mis suureneb järgnevate kadude korral eksponentsiaalselt. Rakenduse laadimisajad võivad pikeneda, kuna TCP-l võtab ühenduste loomine kauem aega.
Andmepakettide puhul vähendavad kõrged RTO väärtused oluliselt võrgu kasulikku kasutamist traadita võrkudes mööduvate kadude korral. Leidsime, et keskmine taasedastusaeg on ligikaudu 1 sekund ja saba viivitus on peaaegu 30 sekundit. Need kõrged latentsusajad TCP tasemel põhjustasid HTTPS-i ajalõppe ja uuesti taotlusi, suurendades veelgi võrgu latentsust ja ebatõhusust.
Kui mõõdetud RTT 75. protsentiil oli umbes 425 ms, siis TCP 75. protsentiil oli peaaegu 3 sekundit. See vihjab, et kaotuse tõttu kulus TCP-l andmete edukaks edastamiseks 7–10 korda. See võib olla ebatõhusa RTO arvutamise, TCP võimetuse kadudele kiiresti reageerida, tagajärg aknas ja ülekoormuse kontrolli algoritmi ebaefektiivsus, mis ei tee vahet traadita ühenduse kadudel ja võrgu ülekoormusest tulenevatel kadudel. Allpool on toodud TCP kaotustestide tulemused:
TCP pakettide kadumise statistika
Väärtus
Vähemalt ühe paketikaotusega ühenduste protsent
45%
Ühenduse seadistamise ajal kaotsiläinud ühenduste protsent
30%
Andmevahetuse ajal kaotsiläinud ühenduste protsent
76%
Taasedastuse viivituste jaotus, sekundites [50%, 75%, 95%, 99%] [1, 2.8, 15, 28]
Kordusedastuste arvu jaotus ühe paketi või TCP segmendi kohta
[1,3,6,7]
QUIC-i rakendamine
Algselt Google'i välja töötatud QUIC on mitme lõimega kaasaegne transpordiprotokoll, mis töötab UDP peal. Praegu on QUIC sees (me juba kirjutasime, et QUIC-ist on justkui kaks versiooni, uudishimulik – ca. tõlkija). Nagu on näidatud joonisel 5, on QUIC paigutatud HTTP/3 alla (tegelikult on QUICi peal olev HTTP/2 HTTP/3, mida nüüd intensiivselt standardiseeritakse). See asendab osaliselt HTTPS-i ja TCP-kihi, kasutades pakettide moodustamiseks UDP-d. QUIC toetab ainult turvalist andmeedastust, kuna TLS on QUIC-i täielikult sisse ehitatud.
Joonis 5: QUIC töötab HTTP/3 all, asendades TLS-i, mis varem töötas HTTP/2 all.
Allpool on toodud põhjused, mis veensid meid kasutama QUIC-i TCP võimendamiseks:
- 0-RTT ühenduse loomine. QUIC võimaldab taaskasutada varasemate ühenduste volitusi, vähendades turvakäepigistuste arvu. Tulevikus toetab 0-RTT-d, kuid siiski on vaja kolmepoolset TCP-käepigistust.
- HoL-i blokeerimise ületamine. HTTP/2 kasutab jõudluse parandamiseks ühte TCP-ühendust kliendi kohta, kuid see võib viia HoL-i (head-of-line) blokeerimiseni. QUIC lihtsustab multipleksimist ja edastab päringud rakendusele iseseisvalt.
- ummikute kontroll. QUIC asub rakenduskihis, muutes lihtsamaks peamise transpordialgoritmi värskendamise, mis juhib saatmist võrguparameetrite (kadude arv või RTT) alusel. Enamik TCP-rakendusi kasutab algoritmi , mis pole latentsustundliku liikluse jaoks optimaalne. Hiljuti välja töötatud algoritmid nagu , modelleerida võrku täpsemalt ja optimeerida latentsust. QUIC võimaldab teil kasutada BBR-i ja värskendada seda algoritmi, kui seda kasutatakse. .
- kadude täiendamine. QUIC kutsub kahte TLP-d () enne RTO käivitumist – isegi kui kahjud on väga märgatavad. See erineb TCP-rakendustest. TLP saadab uuesti peamiselt viimase paketi (või uue, kui see on olemas), et käivitada kiire täiendamine. Sabaviivituste käsitlemine on eriti kasulik Uberi võrgu haldamisel, nimelt lühikeste, juhuslike ja latentsustundlike andmeedastuste puhul.
- optimeeritud ACK. Kuna igal paketil on kordumatu järjenumber, pole probleemi pakette, kui need uuesti edastatakse. ACK-paketid sisaldavad ka aega paketi töötlemiseks ja kliendi poolel ACK-i genereerimiseks. Need funktsioonid tagavad, et QUIC arvutab RTT-d täpsemalt. ACK in QUIC toetab kuni 256 riba , mis aitab saatjal olla pakettide segamise suhtes vastupidavam ja kasutada protsessis vähem baite. Valikuline ACK () TCP-s ei lahenda seda probleemi kõigil juhtudel.
- ühenduse migratsioon. QUIC-ühendused tuvastatakse 64-bitise ID-ga, nii et kui klient muudab IP-aadresse, saab vana ühenduse ID-d katkestusteta uuel IP-aadressil edasi kasutada. See on väga levinud praktika mobiilirakenduste puhul, kus kasutaja lülitub Wi-Fi ja mobiilsideühenduste vahel.
QUIC-i alternatiivid
Enne QUICi valimist kaalusime probleemi lahendamiseks alternatiivseid lähenemisviise.
Esimese asjana proovisime juurutada TPC PoP-sid (kohapunktid), et lõpetada TCP-ühendused kasutajatele lähemal. Põhimõtteliselt lõpetavad PoP-d TCP-ühenduse mobiilsidevõrgule lähemal asuva mobiilseadmega ja suunavad liikluse tagasi algsesse infrastruktuuri. TCP-d lähemale sulgedes saame potentsiaalselt vähendada RTT-d ja tagada, et TCP reageerib paremini dünaamilisele traadita keskkonnale. Kuid meie katsed on näidanud, et suurem osa RTT-st ja kadudest pärineb mobiilsidevõrkudest ning PoP-de kasutamine ei anna jõudluse olulist paranemist.
Vaatasime ka TCP parameetrite häälestamist. TCP-virna seadistamine meie heterogeensetes servaserverites oli keeruline, kuna TCP-l on erinevates OS-i versioonides erinevad rakendused. Selle juurutamine ja erinevate võrgukonfiguratsioonide testimine oli keeruline. TCP-d otse mobiilseadmetes konfigureerida ei saanud lubade puudumise tõttu. Veelgi olulisem on see, et sellised funktsioonid nagu 0-RTT ühendused ja täiustatud RTT ennustus on protokolli arhitektuuri jaoks kriitilise tähtsusega ning seetõttu on võimatu saavutada märkimisväärset kasu ainult TCP häälestamisega.
Lõpuks hindasime mitmeid UDP-põhiseid protokolle, mis tegelevad video voogesituse tõrkeotsinguga – tahtsime näha, kas need protokollid aitaksid meie puhul. Kahjuks puudusid neil paljudes turvaseadetes tõsiselt ning metaandmete ja juhtimisteabe jaoks oli vaja ka täiendavat TCP-ühendust.
Meie uuringud on näidanud, et QUIC on võib-olla ainus protokoll, mis võib aidata Interneti-liikluse probleemi lahendamisel, võttes samal ajal arvesse nii turvalisust kui ka jõudlust.
QUIC-i integreerimine platvormiga
QUICi edukaks manustamiseks ja rakenduse jõudluse parandamiseks kehvas ühenduvusega keskkondades asendasime vana pinu (HTTP/2 üle TLS/TCP) QUIC-protokolliga. Kasutasime võrguteeki kohta , mis sisaldab protokolli algset Google'i versiooni - gQUIC. Seda teostust täiustatakse pidevalt, et järgida uusimat IETF-i spetsifikatsiooni.
Esmalt integreerisime Croneti oma Androidi rakendustesse, et lisada QUIC-i tugi. Lõimumine viidi läbi nii, et migratsioonikulud oleksid võimalikult palju väiksemad. Selle asemel, et täielikult välja vahetada vana võrgupakk, mis kasutas raamatukogu , oleme integreerinud Croneti OkHttp API raamistikku. Sel viisil integreerimisega vältisime muudatusi oma võrgukõnedes (mida kasutavad ) API tasemel.
Sarnaselt Android-seadmetele mõeldud lähenemisviisiga rakendasime Croneti iOS-i Uberi rakendustesse, peatades võrgu HTTP-liikluse. kasutades . See iOS-i sihtasutuse pakutav abstraktsioon käsitleb protokollispetsiifilisi URL-i andmeid ja tagab, et saame Croneti oma iOS-i rakendustesse integreerida ilma oluliste migratsioonikuludeta.
QUIC-i lõpuleviimine teenuses Google Cloud Balancers
Taustaküljel pakub QUIC-i lõpetamist Google'i pilvekoormuse tasakaalustamise infrastruktuur, mis kasutab QUIC-i toetamiseks vastuste päised. Üldiselt lisab tasakaalustaja igale HTTP päringule alt-svc päise ja see juba kinnitab domeeni QUIC-toe. Kui Croneti klient saab selle päisega HTTP-vastuse, kasutab ta sellele domeenile järgnevate HTTP-päringute jaoks QUIC-i. Kui tasakaalustaja on QUIC-i lõpetanud, saadab meie infrastruktuur selle toimingu HTTP2/TCP kaudu meie andmekeskustesse.
Toimivus: tulemused
Väljundjõudlus on meie parema protokolli otsimise peamine põhjus. Alustuseks lõime stendi et teada saada, kuidas QUIC erinevate võrguprofiilide korral käitub. QUIC-i jõudluse testimiseks reaalsetes võrkudes tegime New Delhis ringi sõites katseid, kasutades emuleeritud võrguliiklust, mis sarnanes reisijate rakenduse HTTP-kõnedega.
1. katse
Varustus katse jaoks:
- testige Android-seadmeid OkHttp ja Croneti virnadega, et tagada HTTPS-i liikluse lubamine vastavalt TCP ja QUIC kaudu;
- Java-põhine emulatsiooniserver, mis saadab vastusteks sama tüüpi HTTPS-i päiseid ja laadib klientseadmeid, et neilt päringuid saada;
- pilvepuhverserverid, mis asuvad füüsiliselt India lähedal, et lõpetada TCP- ja QUIC-ühendused. Kuigi TCP lõpetamiseks kasutasime sisse lülitatud pöördpuhverserverit , oli QUIC-i jaoks raske avatud lähtekoodiga pöördpuhverserverit leida. Ehitasime ise QUIC-i jaoks pöördpuhverserveri, kasutades Chromiumi ja põhilist QUIC-i pinu see kroomiks avatud lähtekoodiga.
Joonis 6. TCP vs QUIC teekatsete komplekt koosnes Android-seadmetest koos OkHttp ja Cronetiga, pilvepuhverserveritest ühenduste katkestamiseks ja emulatsiooniserverist.
2. katse
Kui Google tegi QUIC-i kättesaadavaks koos , kasutasime sama inventari, kuid ühe muudatusega: võtsime NGINX-i asemel Google'i koormuse tasakaalustajad, et lõpetada seadmete TCP- ja QUIC-ühendused ning suunata HTTPS-liiklus emulatsiooniserverisse. Tasakaalustajad on laiali üle maailma, kuid kasutavad seadmele lähimat PoP-serverit (tänu geograafilisele asukohale).
Joonis 7. Teises katses tahtsime võrrelda TCP ja QUIC-i valmimise latentsust: kasutades Google Cloudi ja kasutades meie pilvepuhverserverit.
Selle tulemusena ootasid meid mitmed ilmutused:
- lõpetamine PoP kaudu parandas TCP jõudlust. Kuna tasakaalustajad lõpetavad TCP-ühendused kasutajatele lähemal ja on väga optimeeritud, on tulemuseks madalamad RTT-d, mis parandab TCP jõudlust. Ja kuigi QUIC oli vähem mõjutatud, ületas see ikkagi TCP-d saba latentsuse vähendamise osas (10–30 protsenti).
- sabad on mõjutatud . Kuigi meie QUIC-puhverserver asus seadmetest kaugemal (umbes 50 ms kõrgem latentsusaeg) kui Google'i koormuse tasakaalustajad, andis see sarnase jõudluse – latentsusaega vähenes 15%, võrreldes TCP 20. protsentiili vähenemisega 99%. See viitab sellele, et viimase miili üleminek on võrgu kitsaskoht.
Joonis 8: Kahe katse tulemused näitavad, et QUIC ületab oluliselt TCP-d.
Võitle liiklusega
Eksperimenteerimisest inspireerituna oleme oma Androidi ja iOS-i rakendustes juurutanud QUIC-toe. Viisime läbi A/B testimise, et teha kindlaks QUICi mõju linnades, kus Uber tegutseb. Üldiselt nägime mõlema piirkonna, telekommunikatsioonioperaatorite ja võrgutüübi lõikes viivituste märkimisväärset vähenemist.
Allolevad graafikud näitavad sabade (95 ja 99 protsentiili) täiustusi protsentuaalselt makropiirkondade ja erinevate võrgutüüpide kaupa (LTE, 3G, 2G).
Joonis 9. Lahingutestides ületas QUIC latentsusaja poolest TCP-d.
Ainult edasi
Võib-olla on see alles algus - QUIC-i tootmisse lubamine on pakkunud suurepäraseid võimalusi rakenduste jõudluse parandamiseks nii stabiilsetes kui ka ebastabiilsetes võrkudes, nimelt:
Suurenenud katvus
Olles analüüsinud protokolli toimivust reaalses liikluses, nägime, et ligikaudu 80% seanssidest kasutas QUIC-i edukalt Kõik taotlusi, samas kui 15% seanssidest kasutas QUIC ja TCP kombinatsiooni. Eeldame, et selle kombinatsiooni põhjuseks on Croneti teegi ajalõpp tagasi TCP-le, kuna see ei suuda eristada tegelikke UDP-tõrkeid ja halbu võrgutingimusi. Otsime praegu sellele probleemile lahendust, töötades QUICi hilisema rakendamise nimel.
QUIC optimeerimine
Mobiilirakenduste liiklus on latentsustundlik, kuid mitte ribalaiuse suhtes tundlik. Samuti kasutatakse meie rakendusi peamiselt mobiilsidevõrkudes. Katsete põhjal on saba latentsusajad endiselt suured, kuigi kasutatakse puhverserverit TCP ja QUIC lõpetamiseks kasutajate läheduses. Otsime aktiivselt võimalusi ummikute juhtimise parandamiseks ja QUIC-i kadude taastamise algoritmide tõhustamiseks.
Nende ja mitmete muude täiustustega plaanime parandada kasutajakogemust sõltumata võrgust ja piirkonnast, muutes mugava ja sujuva pakettveo üle maailma kättesaadavamaks.
Allikas: www.habr.com