QUIC-protokolla on erittäin mielenkiintoista katsottavaa, minkä vuoksi rakastamme siitä kirjoittamista. Mutta jos aiemmat QUIC-julkaisut olivat enemmänkin historiallista (jos haluatte, paikallishistoriaa) ja laitteistoa, niin tänään julkaisemme mielellämme toisenlaisen käännöksen - puhumme protokollan todellisesta soveltamisesta vuonna 2019. Emme myöskään puhu pienestä niin sanotussa autotallissa sijaitsevasta infrastruktuurista, vaan Uberista, joka toimii lähes kaikkialla maailmassa. Miten yrityksen insinöörit päätyivät päätökseen käyttää QUICia tuotannossa, miten he suorittivat testit ja mitä he näkivät sen käyttöönoton jälkeen tuotannossa - leikkauksen alapuolella.
Kuvat ovat klikattavia. Nauti lukemisesta!
Uberilla on globaali mittakaava, nimittäin 600 läsnäolokaupunkia, joista jokaisessa sovellus on täysin riippuvainen langattomasta Internetistä yli 4500 XNUMX matkapuhelinoperaattorilta. Käyttäjät odottavat sovelluksen olevan paitsi nopea, myös reaaliaikainen - tämän saavuttamiseksi Uber-sovellus tarvitsee alhaisen latenssin ja erittäin luotettavan yhteyden. Valitettavasti, mutta pino ei toimi hyvin dynaamisissa ja häviämisalttiissa langattomissa verkoissa. Ymmärsimme, että tässä tapauksessa alhainen suorituskyky liittyy suoraan TCP-toteutuksiin käyttöjärjestelmän ytimissä.
Ratkaisimme ongelman , moderni kanavamultipleksointiprotokolla, joka antaa meille paremman hallinnan siirtoprotokollan suorituskyvystä. Tällä hetkellä työryhmä standardoi QUIC:n nimellä .
Laajan testauksen jälkeen päätimme, että QUIC:n käyttöönotto sovelluksessamme johtaisi pienempään loppuviiveeseen verrattuna TCP:hen. Havaitsimme 10–30 %:n pienenemisen HTTPS-liikenteessä kuljettajan ja matkustajan sovelluksissa. QUIC antoi meille myös käyttäjäpakettien kokonaisvaltaisen hallinnan.
Tässä artikkelissa jaamme kokemuksemme TCP:n optimoinnista Uber-sovelluksille käyttämällä pinoa, joka tukee QUIC:tä.
Uusin tekniikka: TCP
Nykyään TCP on eniten käytetty siirtoprotokolla HTTPS-liikenteen välittämiseen Internetissä. TCP tarjoaa luotettavan tavuvirran, mikä selviytyy verkon ruuhkautumisesta ja linkkikerroksen häviöistä. TCP:n laaja käyttö HTTPS-liikenteessä johtuu edellisen yleisyydestä (melkein jokainen käyttöjärjestelmä sisältää TCP:n), saatavuudesta useimmissa infrastruktuurissa (kuten kuormituksen tasaajat, HTTPS-välityspalvelimet ja CDN-verkot) ja valmiista toiminnallisuudesta, joka on saatavilla. lähes useimmilla alustoilla ja verkoilla.
Suurin osa käyttäjistä käyttää sovellusta liikkeellä ollessaan, ja TCP:n loppuviiveet eivät olleet lähelläkään reaaliaikaisen HTTPS-liikenteen vaatimuksia. Yksinkertaisesti sanottuna käyttäjät kaikkialla maailmassa ovat kokeneet tämän - Kuva 1 näyttää viiveet suurissa kaupungeissa:
Kuva 1: Hännän latenssi vaihtelee Uberin pääkaupungeissa.
Vaikka latenssi Intian ja Brasilian verkoissa oli korkeampi kuin Yhdysvalloissa ja Isossa-Britanniassa, hännän latenssi on huomattavasti keskimääräistä latenssia korkeampi. Ja tämä pätee jopa Yhdysvaltoihin ja Isoon-Britanniaan.
TCP over the air -suorituskyky
TCP luotiin varten langallinen verkkoja, eli painottaen hyvin ennustettavia linkkejä. Kuitenkin, langaton verkostoilla on omat ominaisuutensa ja vaikeutensa. Ensinnäkin langattomat verkot ovat alttiita häiriöille ja signaalin vaimenemiselle. Esimerkiksi Wi-Fi-verkot ovat herkkiä mikroaalloille, bluetoothille ja muille radioaalloille. Matkapuhelinverkot kärsivät signaalin katoamisesta () johtuen signaalin heijastumisesta/absorptiosta esineissä ja rakennuksissa sekä lähteistä naapurista . Tämä johtaa merkittävämpään (4-10 kertaa) ja monipuolisempaan ja pakettihäviö verrattuna langalliseen yhteyteen.
Kaistanleveyden vaihteluiden ja häviöiden torjumiseksi matkapuhelinverkot käyttävät tyypillisesti suuria puskureita liikennepurskeille. Tämä voi johtaa liialliseen jonotukseen, mikä tarkoittaa pidempiä viiveitä. Hyvin usein TCP käsittelee tätä jonotusta hukkaana pitkittyneen aikakatkaisun vuoksi, joten TCP pyrkii välittämään ja siten täyttämään puskurin. Tämä ongelma tunnetaan nimellä (), ja tämä on erittäin moderni Internet.
Lopuksi matkapuhelinverkon suorituskyky vaihtelee operaattorin, alueen ja ajan mukaan. Kuvassa 2 keräsimme HTTPS-liikenteen mediaaniviiveet solujen välillä 2 kilometrin etäisyydeltä. Tiedot kerättiin kahdelta suurimmalta matkapuhelinoperaattorilta Delhissä, Intiassa. Kuten näet, suorituskyky vaihtelee solusta toiseen. Lisäksi yhden operaattorin tuottavuus eroaa toisen tuottavuudesta. Tähän vaikuttavat sellaiset tekijät kuin verkon sisääntulomallit ottaen huomioon aika ja sijainti, käyttäjien liikkuvuus sekä verkkoinfrastruktuuri, jossa otetaan huomioon tornitiheys ja verkkotyyppien suhde (LTE, 3G jne.).
Kuva 2. Viiveet esimerkkinä 2 km:n säteellä. Delhi, Intia.
Myös matkapuhelinverkkojen suorituskyky vaihtelee ajan myötä. Kuva 3 näyttää mediaanilatenssin viikonpäivittäin. Havaitsimme eroja myös pienemmässä mittakaavassa, yhden päivän ja tunnin sisällä.
Kuva 3. Hännän viiveet voivat vaihdella merkittävästi päivien välillä, mutta samalla operaattorilla.
Kaikki edellä mainitut syyt heikentävät TCP:n suorituskykyä langattomissa verkoissa. Ennen kuin etsimme vaihtoehtoja TCP:lle, halusimme kuitenkin saada tarkan käsityksen seuraavista seikoista:
- onko TCP pääsyyllinen sovelluksiemme viiveiden takana?
- Onko nykyaikaisissa verkoissa merkittäviä ja vaihtelevia meno-paluuviiveitä (RTT)?
- Mikä on RTT:n ja menetyksen vaikutus TCP:n suorituskykyyn?
TCP-suorituskykyanalyysi
Ymmärtääksemme, kuinka analysoimme TCP:n suorituskykyä, katsotaanpa nopeasti, kuinka TCP siirtää tietoja lähettäjältä vastaanottajalle. Ensin lähettäjä muodostaa TCP-yhteyden suorittaen kolmisuuntaisen yhteyden : Lähettäjä lähettää SYN-paketin, odottaa SYN-ACK-pakettia vastaanottajalta ja lähettää sitten ACK-paketin. Toinen ja kolmas passi kuluu TCP-yhteyden muodostamiseen. Vastaanottaja kuittaa jokaisen paketin vastaanottamisen (ACK) varmistaakseen luotettavan toimituksen.
Jos paketti tai ACK katoaa, lähettäjä lähettää uudelleen aikakatkaisun jälkeen (RTO, ). RTO lasketaan dynaamisesti eri tekijöiden perusteella, kuten odotetun RTT-viiveen lähettäjän ja vastaanottajan välillä.
Kuva 4. Pakettien vaihto TCP/TLS:n kautta sisältää uudelleenlähetysmekanismin.
Sen määrittämiseksi, kuinka TCP toimii sovelluksissamme, seurasimme TCP-paketteja käyttämällä viikon ajan taisteluliikenteessä, joka tulee Intian reunapalvelimista. Analysoimme sitten TCP-yhteydet käyttämällä . Lisäksi loimme Android-sovelluksen, joka lähettää emuloitua liikennettä testipalvelimelle jäljittelemällä mahdollisimman paljon todellista liikennettä. Tällä sovelluksella varustettuja älypuhelimia jaettiin useille työntekijöille, jotka keräsivät lokeja useiden päivien aikana.
Molempien kokeiden tulokset olivat yhdenmukaisia toistensa kanssa. Näimme korkeita RTT-viiveitä; hännän arvot olivat lähes 6 kertaa korkeammat kuin mediaaniarvo; viiveiden aritmeettinen keskiarvo on yli 1 sekunti. Monet yhteydet olivat häviöllisiä, minkä vuoksi TCP lähetti uudelleen 3,5 % kaikista paketeista. Ruuhkaisilla alueilla, kuten lentokentillä ja rautatieasemilla, tappiot olivat 7 %. Nämä tulokset kyseenalaistavat solukkoverkoissa käytettyjen tavanomaisen viisauden vähentää merkittävästi kuljetustason häviöitä. Alla ovat "simulaattori"-sovelluksen testitulokset:
Verkkomittarit
Arvot
RTT, millisekuntia [50%, 75%, 95%, 99 %]
[350, 425, 725, 2300]
RTT-ero, sekuntia
Keskimäärin ~1,2s
Pakettihäviö epävakaissa yhteyksissä
Keskimäärin ~3.5 % (7 % ylikuormitetuilla alueilla)
Lähes puolella näistä yhteyksistä oli ainakin yksi pakettihäviö, suurin osa SYN- ja SYN-ACK-paketteja. Useimmat TCP-toteutukset käyttävät SYN-pakettien RTO-arvoa 1 sekunti, joka kasvaa eksponentiaalisesti myöhemmissä häviöissä. Sovellusten latausajat voivat pidentyä, koska TCP:llä kestää kauemmin muodostaa yhteydet.
Datapakettien tapauksessa korkeat RTO-arvot vähentävät huomattavasti verkon hyödyllistä käyttöä langattomien verkkojen ohimenevien häviöiden yhteydessä. Havaitsimme, että keskimääräinen uudelleenlähetysaika on noin 1 sekunti ja loppuviive on lähes 30 sekuntia. Nämä korkeat viiveet TCP-tasolla aiheuttivat HTTPS-aikakatkaisuja ja uudelleenpyyntöjä, mikä lisäsi verkon latenssia ja tehottomuutta entisestään.
Kun mitatun RTT:n 75. prosenttipiste oli noin 425 ms, TCP:n 75. prosenttipiste oli lähes 3 sekuntia. Tämä vihjaa, että menetys aiheutti TCP:lle 7-10 kulkua tiedonsiirron onnistumiseen. Tämä voi johtua tehottomasta RTO-laskennasta, TCP:n kyvyttömyydestä reagoida nopeasti menetyksiin ikkunassa ja ruuhkanhallinta-algoritmin tehottomuus, joka ei tee eroa langattomien häviöiden ja verkon ruuhkasta johtuvien häviöiden välillä. Alla on TCP-häviötestien tulokset:
TCP-pakettien menetystilastot
Arvo
Niiden yhteyksien prosenttiosuus, joissa on vähintään yksi pakettihäviö
45%
Niiden yhteyksien prosenttiosuus, joissa on menetyksiä yhteyden määrityksen aikana
30%
Niiden yhteyksien prosenttiosuus, joissa tiedonsiirron aikana on hävinnyt
76%
Uudelleenlähetyksen viiveiden jakautuminen, sekuntia [50%, 75%, 95%, 99%] [1, 2.8, 15, 28]
Uudelleenlähetysten lukumäärän jakautuminen yhdelle paketille tai TCP-segmentille
[1,3,6,7]
QUIC:n sovellus
Alun perin Googlen kehittämä QUIC on monisäikeinen moderni siirtoprotokolla, joka toimii UDP:n päällä. Tällä hetkellä QUIC on käytössä (kirjoitimme jo, että QUICista on ikään kuin kaksi versiota, utelias – noin kääntäjä). Kuten kuvasta 5 näkyy, QUIC on sijoitettu HTTP/3:n alle (itse asiassa HTTP/2 QUIC:n päällä on HTTP/3, jota nyt intensiivisesti standardoidaan). Se korvaa osittain HTTPS- ja TCP-kerrokset käyttämällä UDP:tä pakettien muodostamiseen. QUIC tukee vain suojattua tiedonsiirtoa, koska TLS on täysin sisäänrakennettu QUICiin.
Kuva 5: QUIC toimii HTTP/3:lla ja korvaa TLS:n, joka aiemmin toimi HTTP/2:ssa.
Alla on syitä, jotka saivat meidät käyttämään QUIC:tä TCP-vahvistukseen:
- 0-RTT-yhteyden muodostaminen. QUIC mahdollistaa aiempien yhteyksien valtuuksien uudelleenkäytön, mikä vähentää turvakättelyjen määrää. Tulevaisuudessa tukee 0-RTT:tä, mutta kolmisuuntainen TCP-kättely vaaditaan silti.
- HoL-eston voittamiseksi. HTTP/2 käyttää yhtä TCP-yhteyttä asiakasta kohden suorituskyvyn parantamiseksi, mutta tämä voi johtaa HoL-estoon (head-of-line). QUIC yksinkertaistaa multipleksointia ja toimittaa pyynnöt sovellukseen itsenäisesti.
- ruuhkautumisen hallinta. QUIC sijaitsee sovelluskerroksessa, mikä helpottaa pääkuljetusalgoritmin päivittämistä, joka ohjaa lähetystä verkkoparametrien (häviöiden määrä tai RTT) perusteella. Useimmat TCP-toteutukset käyttävät algoritmia , joka ei ole optimaalinen latenssiherkälle liikenteelle. Äskettäin kehitetyt algoritmit, kuten , mallintaa verkkoa tarkemmin ja optimoi latenssin. QUIC mahdollistaa BBR:n käytön ja tämän algoritmin päivittämisen sitä mukaa kun sitä käytetään. .
- tappioiden korvaaminen. QUIC kutsuu kaksi TLP:tä () ennen kuin RTO laukeaa – vaikka tappiot olisivat hyvin havaittavissa. Tämä eroaa TCP-toteutuksista. TLP lähettää uudelleen pääasiassa viimeisen paketin (tai uuden, jos sellainen on) käynnistääkseen nopean täydennyksen. Tail-viiveiden käsitteleminen on erityisen hyödyllistä tavalle, jolla Uber käyttää verkkoaan, eli lyhyissä, satunnaisissa ja latenssiherkissä tiedonsiirroissa.
- optimoitu ACK. Koska jokaisella paketilla on yksilöllinen järjestysnumero, ongelmaa ei ole paketteja, kun ne lähetetään uudelleen. ACK-paketit sisältävät myös aikaa käsitellä paketti ja luoda ACK asiakaspuolella. Nämä ominaisuudet varmistavat, että QUIC laskee RTT:n tarkemmin. ACK in QUIC tukee jopa 256 kaistaa , mikä auttaa lähettäjää kestämään pakettien sekoitusta ja käyttämään vähemmän tavuja prosessissa. Valikoiva ACK () TCP:ssä ei ratkaise tätä ongelmaa kaikissa tapauksissa.
- yhteyden siirto. QUIC-yhteydet tunnistetaan 64-bittisellä tunnuksella, joten jos asiakas vaihtaa IP-osoitteita, vanhaa yhteystunnusta voidaan jatkaa uudessa IP-osoitteessa keskeytyksettä. Tämä on hyvin yleinen käytäntö mobiilisovelluksissa, joissa käyttäjä vaihtaa Wi-Fi- ja matkapuhelinyhteyksien välillä.
Vaihtoehtoja QUIC:lle
Pohdimme vaihtoehtoisia lähestymistapoja ongelman ratkaisemiseen ennen kuin valitsimme QUIC:n.
Ensimmäinen asia, jonka yritimme, oli ottaa käyttöön TPC PoP (Point of Presence) -pisteitä TCP-yhteyksien katkaisemiseksi lähempänä käyttäjiä. Pohjimmiltaan PoP:t päättävät TCP-yhteyden mobiililaitteeseen lähempänä matkapuhelinverkkoa ja välittävät liikenteen takaisin alkuperäiseen infrastruktuuriin. Päättämällä TCP:n lähemmäksi voimme mahdollisesti vähentää RTT:tä ja varmistaa, että TCP reagoi paremmin dynaamiseen langattomaan ympäristöön. Kokeilumme ovat kuitenkin osoittaneet, että suurin osa RTT:stä ja häviöstä tulee matkapuhelinverkoista, eikä PoP:ien käyttö paranna merkittävästi suorituskykyä.
Tarkastelimme myös TCP-parametrien viritystä. TCP-pinon määrittäminen heterogeenisille reunapalvelimillemme oli vaikeaa, koska TCP:llä on erilaisia toteutuksia eri käyttöjärjestelmäversioissa. Tämän toteuttaminen ja erilaisten verkkokokoonpanojen testaaminen oli vaikeaa. TCP:n määrittäminen suoraan mobiililaitteissa ei ollut mahdollista käyttöoikeuksien puutteen vuoksi. Vielä tärkeämpää on, että ominaisuudet, kuten 0-RTT-yhteydet ja parannettu RTT-ennustus, ovat kriittisiä protokollan arkkitehtuurille, ja siksi on mahdotonta saavuttaa merkittäviä etuja virittämällä TCP:tä yksin.
Lopuksi arvioimme useita UDP-pohjaisia protokollia, jotka tekevät videon suoratoiston vianetsinnän – halusimme nähdä, auttaisivatko nämä protokollat meidän tapauksessamme. Valitettavasti niistä puuttui vakavasti monia suojausasetuksia, ja ne vaativat myös ylimääräisen TCP-yhteyden metadataa ja ohjaustietoja varten.
Tutkimuksemme ovat osoittaneet, että QUIC on ehkä ainoa protokolla, joka voi auttaa Internet-liikenteen ongelmassa, samalla kun otetaan huomioon sekä tietoturva että suorituskyky.
QUICin integrointi alustaan
QUIC:n upottaminen onnistuneesti ja sovellusten suorituskyvyn parantaminen huonoissa yhteysympäristöissä korvasi vanhan pinon (HTTP/2 over TLS/TCP) QUIC-protokollalla. Käytimme verkkokirjastoa ja , joka sisältää protokollan alkuperäisen Google-version - gQUIC. Tätä toteutusta myös parannetaan jatkuvasti uusimman IETF-spesifikaation mukaisesti.
Integroimme ensin Cronetin Android-sovelluksiimme QUIC-tuen lisäämiseksi. Integraatio toteutettiin siten, että muuttokustannukset pienenivät mahdollisimman paljon. Sen sijaan, että kirjastoa käyttänyt vanha verkkopino korvattaisiin kokonaan , olemme integroineet Cronetin OkHttp API -kehykseen. Tekemällä integroinnin tällä tavalla vältimme muutoksia verkkopuheluihimme (jotka käyttävät ) API-tasolla.
Android-laitteiden tapaan otimme Cronetin käyttöön iOS:n Uber-sovelluksiin sieppaamalla HTTP-liikenteen verkosta. käyttämällä . Tämä iOS Foundationin tarjoama abstraktio käsittelee protokollakohtaisia URL-tietoja ja varmistaa, että voimme integroida Cronetin iOS-sovelluksiimme ilman merkittäviä siirtokustannuksia.
Suoritetaan QUIC Google Cloud Balancersissa
Taustapuolella QUIC-täydennyksen tarjoaa Google Cloud Load Balancing -infrastruktuuri, joka käyttää QUIC-tukea koskevien vastausten otsikot. Yleensä tasapainotin lisää alt-svc-otsikon jokaiseen HTTP-pyyntöön, ja tämä jo vahvistaa QUIC-tuen toimialueelle. Kun Cronet-asiakas vastaanottaa HTTP-vastauksen tällä otsikolla, se käyttää QUIC:tä myöhemmissä HTTP-pyynnöissä kyseiselle toimialueelle. Kun tasapainotin on suorittanut QUIC:n, infrastruktuurimme lähettää tämän toiminnon erikseen HTTP2/TCP:n kautta palvelinkeskuksillemme.
Suorituskyky: Tulokset
Lähtöteho on tärkein syy paremman protokollan etsimiseen. Aluksi loimme jalustan saadaksesi selville, kuinka QUIC käyttäytyy eri verkkoprofiileissa. Testaaksemme QUIC:n suorituskykyä todellisissa verkoissa suoritimme kokeita ajaessamme ympäri New Delhiä käyttämällä emuloitua verkkoliikennettä, joka on hyvin samanlaista kuin matkustajasovelluksen HTTP-puhelut.
Koe 1
Varusteet kokeeseen:
- testaa Android-laitteita OkHttp- ja Cronet-pinoilla varmistaaksemme, että sallimme HTTPS-liikenteen TCP:n ja QUIC:n kautta;
- Java-pohjainen emulointipalvelin, joka lähettää samantyyppisiä HTTPS-otsikoita vastauksissa ja lataa asiakaslaitteet vastaanottaakseen pyyntöjä niiltä;
- pilvivälityspalvelimet, jotka sijaitsevat fyysisesti lähellä Intiaa TCP- ja QUIC-yhteyksien katkaisemiseksi. Vaikka TCP-päätyksessä käytimme käänteistä välityspalvelinta , oli vaikea löytää avoimen lähdekoodin käänteistä välityspalvelinta QUIC:lle. Rakensimme itse käänteisen välityspalvelimen QUIC:lle käyttämällä Chromiumin ja Chromiumin perus-QUIC-pinoa se kromiksi avoimena lähdekoodina.
Kuva 6. TCP vs QUIC -tietestipaketti koostui Android-laitteista, joissa oli OkHttp ja Cronet, pilvivälityspalvelimet yhteyksien katkaisemiseen ja emulointipalvelimen.
Koe 2
Kun Google tarjosi QUIC:n saataville , käytimme samaa inventaariota, mutta yhdellä muutoksella: NGINX:n sijaan otimme Googlen kuormantasaajat katkaisemaan TCP- ja QUIC-yhteydet laitteista sekä reitittämään HTTPS-liikennettä emulointipalvelimelle. Balancereita on jaettu ympäri maailmaa, mutta ne käyttävät laitetta lähinnä olevaa PoP-palvelinta (maantieteellisen sijainnin ansiosta).
Kuva 7. Toisessa kokeessa halusimme verrata TCP:n ja QUIC:n valmistumisviivettä: käyttämällä Google Cloudia ja käyttämällä pilvivälityspalvelinta.
Tämän seurauksena meitä odotti useita paljastuksia:
- lopettaminen PoP:n kautta paransi TCP:n suorituskykyä. Koska tasapainottimet päättävät TCP-yhteydet lähempänä käyttäjiä ja ovat erittäin optimoituja, tämä johtaa alhaisempiin RTT-arvoihin, mikä parantaa TCP:n suorituskykyä. Ja vaikka vaikutus QUIC:iin oli vähäisempi, se ylitti silti TCP:n hännän latenssin vähentämisessä (10–30 prosenttia).
- hännät vaikuttavat . Vaikka QUIC-välityspalvelimemme oli kauempana laitteista (noin 50 ms korkeampi latenssi) kuin Googlen kuormantasaajat, se tarjosi samanlaisen suorituskyvyn - 15 prosentin vähennys latenssissa verrattuna 20 prosentin laskuun TCP:n 99. prosenttipisteessä. Tämä viittaa siihen, että viimeisen mailin siirtyminen on verkon pullonkaula.
Kuva 8: Kahden kokeen tulokset osoittavat, että QUIC on huomattavasti tehokkaampi kuin TCP.
Taistele liikennettä vastaan
Kokeilun innoittamana olemme ottaneet QUIC-tuen käyttöön Android- ja iOS-sovelluksissamme. Teimme A/B-testauksen määrittääksemme QUIC:n vaikutuksen kaupungeissa, joissa Uber toimii. Yleisesti ottaen havaitsimme, että viiveet vähenivät merkittävästi molemmilla alueilla, teleoperaattoreissa ja verkkotyypeissä.
Alla olevat kaaviot näyttävät prosentuaaliset parannukset tailoissa (95 ja 99 prosenttipisteet) makroalueen ja eri verkkotyyppien - LTE, 3G, 2G - mukaan.
Kuva 9. Taistelutesteissä QUIC ylitti TCP:n latenssin suhteen.
Vain eteenpäin
Ehkä tämä on vasta alkua - QUIC:n julkaisu tuotantoon on tarjonnut uskomattomia mahdollisuuksia parantaa sovellusten suorituskykyä sekä vakaissa että epävakaissa verkoissa, nimittäin:
Lisääntynyt kattavuus
Analysoituamme protokollan suorituskyvyn todellisessa liikenteessä havaitsimme, että noin 80 % istunnoista käytti onnistuneesti QUIC:tä Kaikki pyyntöjä, kun taas 15 % istunnoista käytti QUIC:n ja TCP:n yhdistelmää. Oletamme, että yhdistelmä johtuu Cronet-kirjaston aikakatkaisusta takaisin TCP:hen, koska se ei pysty erottamaan todellisia UDP-virheitä ja huonoja verkkoolosuhteita. Etsimme parhaillaan ratkaisua tähän ongelmaan, kun pyrimme toteuttamaan QUIC:n myöhemmin.
QUIC-optimointi
Mobiilisovellusten liikenne on latenssiherkkää, mutta ei kaistanleveysherkkää. Myös sovelluksiamme käytetään ensisijaisesti matkapuhelinverkoissa. Kokeiden perusteella loppuviiveet ovat edelleen korkeat, vaikka välityspalvelinta käytetään TCP:n ja QUIC:n päättämiseen lähellä käyttäjiä. Etsimme aktiivisesti tapoja parantaa ruuhkanhallintaa ja parantaa QUIC-häviönpalautusalgoritmien tehokkuutta.
Näillä ja useilla muilla parannuksilla aiomme parantaa käyttökokemusta verkosta ja alueesta riippumatta, mikä tekee pakettien kuljetuksesta helpompaa ja saumattomampaa kaikkialla maailmassa.
Lähde: will.com