De QUIC Protokoll ass extrem interessant ze kucken, dofir hu mir gär doriwwer schreiwen. Awer wa fréier Publikatiounen iwwer QUIC méi vun enger historescher (lokaler Geschicht, wann Dir wëllt) Natur an Hardware waren, haut si mir frou eng Iwwersetzung vun enger anerer Aart ze verëffentlechen - mir schwätzen iwwer déi richteg Uwendung vum Protokoll am Joer 2019. Ausserdeem schwätze mir net vun enger klenger Infrastruktur déi an enger sougenannter Garage baséiert, mee vun Uber, déi bal iwwerall op der Welt funktionéiert. Wéi d'Ingenieuren vun der Firma zu der Entscheedung koumen QUIC an der Produktioun ze benotzen, wéi se d'Tester gemaach hunn a wat se gesinn hunn nodeems se se an der Produktioun ausgerullt hunn - ënner dem Schnëtt.
D'Biller sinn klickbar. Genéisst d'Liesen!
Uber huet eng global Skala, nämlech 600 Stied vun der Präsenz, an all eenzel vun deenen d'Applikatioun ganz op drahtlose Internet vu méi wéi 4500 Cellular Opérateuren hänkt. D'Benotzer erwaarden datt d'App net nëmme séier ass, mee an Echtzäit - fir dëst z'erreechen, brauch d'Uber App niddereg latency an eng ganz zouverléisseg Verbindung. Och, mä de Stack mécht et net gutt an dynamesche a Verloscht-ufälleg drahtlose Netzwierker. Mir hu gemierkt datt an dësem Fall niddereg Leeschtung direkt mat TCP Implementatiounen am Betribssystemkäre verbonnen ass.
Fir de Problem ze léisen, hu mir applizéiert , e modernen Kanal Multiplexing Protokoll deen eis méi Kontroll iwwer d'Leeschtung vum Transportprotokoll gëtt. Aktuell den Aarbechtsgrupp standardizes QUIC als .
No extensiv Testen hu mir ofgeschloss datt d'Ëmsetzung vun QUIC an eiser Applikatioun zu méi nidderegen Schwanzlatzen am Verglach zum TCP géif resultéieren. Mir hunn eng Reduktioun am Beräich vun 10-30% fir HTTPS Traffic an de Chauffer- a Passagéierapplikatiounen observéiert. QUIC huet eis och end-to-end Kontroll iwwer Benotzerpakete ginn.
An dësem Artikel deele mir eis Erfahrung an der Optimiséierung vun TCP fir Uber Uwendungen mat engem Stack deen QUIC ënnerstëtzt.
Déi lescht Technologie: TCP
Haut ass TCP dee meescht benotzten Transportprotokoll fir HTTPS Traffic um Internet ze liwweren. TCP liwwert en zouverléissege Stroum vu Bytes, doduerch mat Netzwierkstau a Linkschichtverloschter. Déi verbreet Notzung vun TCP fir HTTPS Traffic ass wéinst der fréierer Ubiquity (bal all OS enthält TCP), Disponibilitéit op déi meescht Infrastrukturen (wéi Lastbalancers, HTTPS Proxies an CDNs), an Out-of-the-Box Funktionalitéit déi verfügbar ass op bal déi meescht Plattformen an Netzwierker.
Déi meescht Benotzer benotzen eis App ënnerwee, an TCP Schwanz Latenzen waren néierens bei den Ufuerderunge vun eisem Echtzäit HTTPS Traffic. Einfach gesot, Benotzer op der ganzer Welt hunn dëst erlieft - Figur 1 weist Verspéidungen a grousse Stied:
Figur 1: Schwänzlatenz variéiert an den Haaptstied vun Uber.
Och wann d'Latenz an indeschen a brasilianesche Netzwierker méi héich war wéi an den USA an de UK, ass d'Schwanzlatenz wesentlech méi héich wéi d'Duerchschnëttslatenz. An dat gëllt och fir d'USA a Groussbritannien.
TCP iwwer d'Loft Leeschtung
TCP gouf geschaf fir verkabelt Netzwierker, dat heescht, mat engem Akzent op héich prévisibel Linken. Allerdéngs, drahtlos Netzwierker hunn hir eege Charakteristiken a Schwieregkeeten. Als éischt sinn drahtlose Netzwierker ufälleg fir Verloschter wéinst Interferenz a Signaldempung. Zum Beispill sinn Wi-Fi Netzwierker empfindlech op Mikrowellen, Bluetooth an aner Radiowellen. Zellular Netzwierker leiden ënner Signalverloscht () duerch Reflexioun/Absorptioun vum Signal duerch Objeten a Gebaier, souwéi vun vun Nopeschlänner . Dëst féiert zu méi bedeitend (4-10 Mol) a méi divers a Paketverloscht am Verglach mat enger Kabelverbindung.
Fir Bandbreedschwankungen a Verloschter ze bekämpfen, benotze cellulär Netzwierker typesch grouss Puffer fir Traffic Bursts. Dëst kann zu exzessive Schlaangen féieren, wat méi Verspéidungen bedeit. Ganz dacks behandelt TCP dës Schlaang als Offall wéinst engem verlängerten Timeout, sou datt TCP tendéiert ze relaiséieren an doduerch de Puffer ze fëllen. Dëse Problem ass bekannt als (), an dëst ass ganz modern Internet.
Schlussendlech variéiert d'Performance vun der Zellularnetz vum Carrier, Regioun an Zäit. An der Figur 2 hu mir d'Medianverzögerungen vum HTTPS-Traffic iwwer Zellen an engem 2-Kilometer-Bereich gesammelt. Daten gesammelt fir zwee grouss Cellulär Opérateuren zu Delhi, Indien. Wéi Dir kënnt gesinn, variéiert d'Performance vun Zell zu Zell. Och d'Produktivitéit vun engem Bedreiwer ënnerscheet sech vun der Produktivitéit vum zweeten. Dëst gëtt beaflosst vu Faktoren wéi Netzwierkentrée Musteren, déi Zäit a Standuert berücksichtegen, Benotzermobilitéit, souwéi Netzwierkinfrastruktur berücksichtegt Tuermdicht an d'Verhältnis vun Netzwierktypen (LTE, 3G, etc.).
Figur 2. Verspéidungen benotzt engem 2 km Radius als Beispill. Delhi, Indien.
Och d'Performance vun Zellular Netzwierker variéiert mat der Zäit. Figur 3 weist d'Median latency vum Dag vun der Woch. Mir hunn och Differenzen op enger méi klenger Skala observéiert, bannent engem eenzegen Dag a Stonn.
Figur 3. Schwäif Verspéidungen kann däitlech tëscht Deeg variéieren, mä fir déi selwecht Bedreiwer.
All déi uewe bewierkt datt d'TCP Leeschtung net effikass ass an drahtlose Netzwierker. Wéi och ëmmer, ier mir no Alternativen zum TCP sichen, wollte mir e präzise Verständnis op de folgende Punkte entwéckelen:
- ass TCP den Haaptschëlleg hannert Schwanzlatzen an eisen Uwendungen?
- Hutt modern Netzwierker bedeitend a variéiert Ronn-Rees Verspéidungen (RTT)?
- Wat ass den Impakt vun RTT a Verloscht op TCP Leeschtung?
TCP Leeschtung Analyse
Fir ze verstoen wéi mir TCP Leeschtung analyséiert hunn, kucke mer séier wéi TCP Daten vun engem Sender an en Empfänger transferéiert. Als éischt erstellt de Sender eng TCP-Verbindung, mécht en Dräi-Wee : De Sender schéckt e SYN Paket, waart op e SYN-ACK Paket vum Empfänger, schéckt dann en ACK Paket. En zousätzleche zweeten an drëtte Pass ass verbraucht fir d'TCP Verbindung ze etabléieren. Den Empfänger erkennt den Empfang vun all Paket (ACK) fir zouverlässeg Liwwerung ze garantéieren.
Wann e Paket oder ACK verluer ass, schéckt de Sender no engem Timeout (RTO, ). RTO gëtt dynamesch berechent op Basis vu verschiddene Faktoren, sou wéi déi erwaart RTT Verzögerung tëscht dem Sender an dem Empfänger.
Figur 4. Paketaustausch iwwer TCP / TLS enthält e Retransmissionsmechanismus.
Fir festzestellen wéi TCP an eisen Uwendungen ausgeführt huet, hu mir TCP Pakete benotzt fir eng Woch op Kampf Traffic vun indesche Rand Serveren kommen. Mir analyséieren dann d'TCP Verbindungen benotzt . Zousätzlech hu mir eng Android Applikatioun erstallt déi emuléiert Traffic op en Testserver schéckt, sou vill wéi méiglech de realen Traffic imitéiert. Smartphones mat dëser Applikatioun goufen u verschidde Mataarbechter verdeelt, déi Logbicher iwwer e puer Deeg gesammelt hunn.
D'Resultater vu béiden Experimenter ware konsequent mateneen. Mir hunn héich RTT latencies gesinn; Schwanzwäerter ware bal 6 Mol méi héich wéi de Medianwäert; den arithmeteschen Duerchschnëtt vun de Verspéidungen ass méi wéi 1 Sekonn. Vill Verbindunge ware verléiert, sou datt TCP 3,5% vun alle Pakete weiderginn. An iwwerlaaschte Gebidder wéi Fluchhäfen an Gare hu mir 7% Verloschter gesinn. Dës Resultater werfen Zweifel un der konventioneller Wäisheet déi déi an Zellular Netzwierker benotzt ginn däitlech reduzéieren Verloschter um Transport Niveau. Drënner sinn d'Testresultater vun der "Simulator" Applikatioun:
Netzwierk Metriken
Wäerter
RTT, Millisekonnen [50%, 75%, 95%, 99%]
[350, 425, 725, 2300]
RTT-Divergenz, Sekonnen
Duerchschnëtt ~ 1,2 s
Packet Verloscht op onbestänneg Verbindungen
Duerchschnëtt ~ 3.5% (7% an iwwerlaascht Gebidder)
Bal d'Halschent vun dëse Verbindungen haten op d'mannst ee Paketverloscht, déi meescht vun hinnen SYN an SYN-ACK Pakete. Déi meescht TCP-Implementatiounen benotzen en RTO-Wäert vun 1 Sekonn fir SYN-Päckchen, wat exponentiell eropgeet fir spéider Verloschter. Applikatioun Luede Zäite kënnen eropgoen wéinst TCP méi laang dauert fir Verbindungen opzebauen.
Am Fall vun Datepäck reduzéieren héich RTO Wäerter d'nëtzlech Notzung vum Netz staark an der Präsenz vu transiente Verloschter an drahtlose Netzwierker. Mir hu festgestallt datt déi duerchschnëttlech Iwwerdroungszäit ongeféier 1 Sekonn ass mat enger Schwanzverzögerung vu bal 30 Sekonnen. Dës héich Latenzen um TCP Niveau hunn HTTPS Timeouts a Re-Ufroen verursaacht, wat d'Netzlatenz an d'Ineffizienz weider erhéijen.
Wärend de 75. Prozentsaz vum gemoossene RTT ongeféier 425 ms war, war de 75. Prozenttil fir TCP bal 3 Sekonnen. Dëst weist datt de Verloscht verursaacht huet datt TCP 7-10 Passë geholl huet fir Daten erfollegräich ze vermëttelen. Dëst kann eng Konsequenz vun ineffizient RTO Berechnung ginn, TCP Onméiglechkeet séier op Verloscht z'äntwerten an der Fënster an d'Ineffizienz vum Stau Kontroll Algorithmus, deen net tëscht drahtlose Verloschter a Verloschter duerch Reseau Stau ënnerscheet. Drënner sinn d'Resultater vun TCP Verloscht Tester:
TCP Packet Verloscht Statistiken
Wäert
Prozentsaz vun Verbindungen mat op d'mannst 1 Paket Verloscht
45%
Prozentsaz vun Verbindungen mat Verloschter während Verbindung Setup
30%
Prozentsaz vun Verbindungen mat Verloschter während Datenaustausch
76%
Verdeelung vun Verspéidungen an der Iwwerdroung, Sekonnen [50%, 75%, 95%,99%] [1, 2.8, 15, 28]
Verdeelung vun der Unzuel vun den Iwwerdroe fir ee Paket oder TCP Segment
[1,3,6,7]
Uwendung vun QUIC
Ursprénglech vu Google entwéckelt, QUIC ass e multi-threaded modernen Transportprotokoll deen uewen op UDP leeft. De Moment ass QUIC an (mir scho geschriwwen datt et, wéi et war, zwou Versioune vu QUIC, virwëtzeg – ca. Iwwersetzer). Wéi an der Figur 5 gewisen, gëtt QUIC ënner HTTP/3 gesat (tatsächlech HTTP/2 uewen op QUIC ass HTTP/3, wat elo intensiv standardiséiert gëtt). Et ersetzt deelweis d'HTTPS an TCP Schichten andeems Dir UDP benotzt fir Päck ze bilden. QUIC ënnerstëtzt nëmme sécher Datenübertragung well TLS voll a QUIC agebaut ass.
Figur 5: QUIC leeft ënner HTTP/3, ersetzt TLS, déi virdru ënner HTTP/2 gelaf ass.
Drënner sinn d'Grënn déi eis iwwerzeegt hunn QUIC fir TCP Verstärkung ze benotzen:
- 0-RTT Verbindung Etablissement. QUIC erlaabt d'Wiederbenotzen vun Autorisatioune vu fréiere Verbindungen, reduzéiert d'Zuel vu Sécherheetshandshaken. An Zukunft wäert 0-RTT Ënnerstëtzung, mee eng Dräierkoalitioun TCP Handshake wäert nach néideg ginn.
- iwwerwannen HoL Spär. HTTP/2 benotzt eng TCP Verbindung pro Client fir d'Performance ze verbesseren, awer dëst kann zu HoL (Head-of-Line) Blockéierung féieren. QUIC vereinfacht Multiplexing a liwwert Ufroen un d'Applikatioun onofhängeg.
- Stau Kontroll. QUIC wunnt op der Applikatiounsschicht, wat et méi einfach mécht den Haapttransportalgorithmus ze aktualiséieren deen d'Sendung kontrolléiert baséiert op Netzwierkparameter (Zuel vu Verloschter oder RTT). Déi meescht TCP Implementatiounen benotzen den Algorithmus , wat net optimal ass fir latency-sensibel Traffic. Kuerzem entwéckelt Algorithmen wéi , méi präzis de Netz modelléieren an d'Latenz optimiséieren. QUIC erlaabt Iech BBR ze benotzen an dësen Algorithmus ze aktualiséieren wéi et benotzt gëtt. .
- replenishment vun Verloschter. QUIC rifft zwee TLPs () ier de RTO ausgeléist gëtt - och wann d'Verloschter ganz bemierkbar sinn. Dëst ass anescht wéi TCP Implementatiounen. TLP retransmittéiert haaptsächlech de leschte Paket (oder den neien, wann et een ass) fir séier Erhuelung auszeléisen. D'Handhabung vu Schwanzverzögerungen ass besonnesch nëtzlech fir de Wee wéi Uber säi Netzwierk bedreift, nämlech fir kuerz, sporadesch a latency-sensibel Datenübertragungen.
- optimiséiert ACK. Well all Paket eng eenzegaarteg Sequenznummer huet, gëtt et kee Problem Pakete wa se nei iwwerdroe ginn. ACK Pakete enthalen och Zäit fir de Paket ze veraarbecht an en ACK op der Client Säit ze generéieren. Dës Fonctiounen suergen, datt QUIC berechent RTT méi präziist. ACK an QUIC ënnerstëtzt bis zu 256 Bands , hëlleft dem Sender méi elastesch fir Paket-Shuffelen a benotzt manner Bytes am Prozess. Selektiv ACK () an TCP léist dëse Problem net an alle Fäll.
- Verbindung Migratioun. QUIC Verbindunge ginn duerch eng 64-Bit ID identifizéiert, also wann e Client IP Adressen ännert, kann déi al Verbindung ID weider op der neier IP Adress ouni Ënnerbriechung benotzt ginn. Dëst ass eng ganz heefeg Praxis fir mobil Uwendungen wou de Benotzer tëscht Wi-Fi an Cellular Verbindungen wiesselt.
Alternativen zu QUIC
Mir hunn alternativ Approche geduecht fir de Problem ze léisen ier Dir QUIC gewielt hutt.
Dat éischt wat mir probéiert hunn, war TPC PoPs (Points of Presence) z'installéieren fir TCP Verbindunge méi no bei de Benotzer ofzeschléissen. Wesentlech schléissen PoPs eng TCP-Verbindung mat engem mobilen Apparat méi no beim Zellularnetz of a proxy de Traffic zréck an d'originell Infrastruktur. Andeems Dir den TCP méi no ofschléisst, kënne mir potenziell den RTT reduzéieren an dofir suergen datt TCP méi reaktiounsfäeger op eng dynamesch drahtlos Ëmfeld ass. Wéi och ëmmer, eis Experimenter hunn gewisen datt de gréissten Deel vun der RTT a Verloscht aus Cellular Netzwierker kënnt an d'Benotzung vu PoPs keng bedeitend Leeschtungsverbesserung ubitt.
Mir hunn och TCP Parameteren ofstëmmen. En TCP-Stack op eisen heterogenen Randserveren opzestellen war schwéier well TCP disparate Implementatiounen iwwer verschidden OS Versiounen huet. Et war schwéier dëst ëmzesetzen a verschidde Netzwierkkonfiguratiounen ze testen. TCP direkt op mobilen Apparater konfiguréieren war net méiglech wéinst Mangel u Permissiounen. Méi wichteg, Features wéi 0-RTT Verbindungen a verbessert RTT Viraussoen si kritesch fir d'Architektur vum Protokoll, an dofir ass et onméiglech bedeitend Virdeeler z'erreechen andeems TCP eleng ofstëmmt.
Schlussendlech hu mir e puer UDP-baséiert Protokoller evaluéiert déi Videostreaming léisen - mir wollte kucken ob dës Protokoller an eisem Fall hëllefe géifen. Leider fehlen se schwéier a ville Sécherheetsastellungen, an hunn och eng zousätzlech TCP Verbindung fir Metadaten a Kontrollinformatioun verlaangt.
Eis Fuerschung huet gewisen datt QUIC vläicht deen eenzege Protokoll ass, dee mam Problem vum Internetverkéier hëllefe kann, wärend souwuel Sécherheet a Leeschtung berücksichtegt ginn.
Integratioun vu QUIC an der Plattform
Fir QUIC erfollegräich z'integréieren an d'Applikatiounsleistung an aarme Konnektivitéitsëmfeld ze verbesseren, hu mir den alen Stack (HTTP / 2 iwwer TLS / TCP) mam QUIC Protokoll ersat. Mir hunn d'Netzbibliothéik benotzt aus , déi d'Original, Google Versioun vum Protokoll enthält - gQUIC. Dës Implementatioun gëtt och permanent verbessert fir déi lescht IETF Spezifizéierung ze verfollegen.
Mir hunn als éischt Cronet an eis Android Apps integréiert fir Ënnerstëtzung fir QUIC ze addéieren. D'Integratioun gouf esou duerchgefouert fir d'Migratiounskäschte sou vill wéi méiglech ze reduzéieren. Amplaz den alen Netzwierkstack komplett ze ersetzen deen d'Bibliothéik benotzt huet , Mir hunn Cronet UNDER dem OkHttp API Kader integréiert. Andeems mir d'Integratioun op dës Manéier maachen, hu mir Ännerunge vun eisem Netzwierk vermeit (déi benotzt gi vun ) um API Niveau.
Ähnlech wéi d'Approche fir Android Apparater, hu mir Cronet an Uber Apps op iOS implementéiert, HTTP-Traffic vum Netz offangen benotzt . Dës Abstraktioun, déi vun der iOS Foundation zur Verfügung gestallt gëtt, handhabt protokollspezifesch URL-Daten a garantéiert datt mir Cronet an eis iOS Uwendungen integréiere kënnen ouni bedeitend Migratiounskäschte.
Komplett QUIC op Google Cloud Balancer
Op der Backend Säit gëtt QUIC Fäerdegstellung vun der Google Cloud Load Balancing Infrastruktur geliwwert, déi benotzt Header an Äntwerte fir QUIC z'ënnerstëtzen. Am Allgemengen füügt de Balancer en alt-svc Header un all HTTP-Ufro un, an dëst validéiert scho QUIC Ënnerstëtzung fir d'Domain. Wann e Cronet Client eng HTTP Äntwert mat dësem Header kritt, benotzt et QUIC fir spéider HTTP Ufroen un dat Domain. Wann de Balancer de QUIC ofgeschloss huet, schéckt eis Infrastruktur dës Aktioun explizit iwwer HTTP2 / TCP un eis Datenzenteren.
Leeschtung: Resultater
Ausgangsleistung ass den Haaptgrond fir eis Sich no engem bessere Protokoll. Fir unzefänken hu mir e Stand mat fir erauszefannen wéi QUIC sech ënner verschiddene Netzwierkprofiler behuelen. Fir d'Performance vum QUIC op real-Welt Netzwierker ze testen, hu mir Experimenter gemaach wärend mir ronderëm New Delhi gefuer sinn mat emuléierten Netzwierkverkéier ganz ähnlech wéi HTTP-Uriff an der Passagéier-App.
Experiment 1
Ausrüstung fir den Experiment:
- Test Android Apparater mat OkHttp a Cronet Stacks fir sécherzestellen datt mir HTTPS Traffic iwwer TCP respektiv QUIC erlaben;
- e Java-baséiert Emulatiounsserver deen déiselwecht Aart vun HTTPS Header an Äntwerte schéckt a Client-Geräter lued fir Ufroe vun hinnen ze kréien;
- Cloud Proxyen déi kierperlech no bei Indien lokaliséiert sinn fir TCP a QUIC Verbindungen ofzeschléissen. Wärend fir TCP-Kënnegung hu mir e Reverse Proxy benotzt , et war schwéier eng Open Source Reverse Proxy fir QUIC ze fannen. Mir hunn e Reverse Proxy fir QUIC selwer gebaut mat der Basis QUIC Stack vu Chromium an et an Chrom als Open Source.
Figur 6. D'TCP vs QUIC Road Test Suite bestoung aus Android Apparater mat OkHttp a Cronet, Cloud Proxyen fir d'Verbindungen ofzeschléissen, an en Emulatiounsserver.
Experiment 2
Wann Google gemaach QUIC verfügbar mat , Mir hunn déiselwecht Inventar benotzt, awer mat enger Ännerung: Amplaz vun NGINX hu mir Google Lastbalancer geholl fir TCP- a QUIC-Verbindunge vun Apparater ofzeschléissen, wéi och fir den HTTPS-Traffic op den Emulatiounsserver ze routen. Balancer sinn iwwerall op der Welt verdeelt, awer benotzt de PoP Server am nootste vum Apparat (dank der Geolocation).
Figur 7. Am zweeten Experiment wollte mir d'Vervollstännegungslatenz vun TCP a QUIC vergläichen: Google Cloud benotzen an eise Cloud Proxy benotzen.
Als Resultat hunn e puer Offenbarungen op eis gewaart:
- Terminatioun iwwer PoP verbessert TCP Leeschtung. Well Balancer TCP Verbindunge méi no bei de Benotzer ofschléissen an héich optimiséiert sinn, resultéiert dëst zu méi nidderegen RTTs, wat d'TCP Leeschtung verbessert. An obwuel QUIC manner betraff war, huet et ëmmer nach TCP iwwerschratt wat d'Schwänzlatenz reduzéiert (um 10-30 Prozent).
- Schwänz betraff sinn . Och wann eise QUIC Proxy méi wäit vun den Apparater war (ongeféier 50 ms méi héich Latenz) wéi d'Laaschtbalancer vu Google, huet et ähnlech Leeschtung geliwwert - eng 15% Reduktioun vun der latency versus eng 20% Reduktioun am 99th percentile fir TCP. Dëst hindeit datt de leschte Kilometer Iwwergank e Flaschenhals am Netz ass.
Figure 8: Resultater vun zwee Experimenter weisen datt QUIC däitlech méi wéi TCP mécht.
Kampf Verkéier
Inspiréiert vun Experimenter hu mir QUIC Support an eisen Android an iOS Uwendungen implementéiert. Mir hunn A / B Tester gemaach fir den Impakt vum QUIC an de Stied ze bestëmmen wou Uber operéiert. Am Allgemengen hu mir eng bedeitend Reduktioun vun de Schwanzverzögerungen iwwer béid Regiounen, Telekomoperateuren an Netzwierkart gesinn.
D'Grafiken hei ënnen weisen d'Prozentualverbesserungen an de Schwänz (95 an 99 Prozent) no Makro-Regioun a verschiddenen Netzwierktypen - LTE, 3G, 2G.
Figur 9. A Schluecht Tester huet QUIC TCP am Sënn vun latency.
Nëmme vir
Vläicht ass dëst just den Ufank - d'Verëffentlechung vu QUIC an d'Produktioun huet erstaunlech Méiglechkeete geliwwert fir d'Applikatiounsleistung a stabilen an onbestännegen Netzwierker ze verbesseren, nämlech:
Erhéicht Ofdeckung
Nodeems mir d'Performance vum Protokoll am realen Traffic analyséiert hunn, hu mir gesinn datt ongeféier 80% vun de Sessiounen erfollegräich QUIC fir всех Ufroen, während 15% vun de Sessiounen eng Kombinatioun vu QUIC an TCP benotzt hunn. Mir huelen un datt d'Kombinatioun wéinst der Cronet-Bibliothéik Timeout zréck op TCP ass, well et kann net tëscht realen UDP-Feeler an aarme Netzwierkbedéngungen ënnerscheeden. Mir sichen de Moment no enger Léisung fir dëse Problem wéi mir un déi spéider Ëmsetzung vum QUIC schaffen.
QUIC Optimisatioun
Traffic vu mobilen Apps ass latency sensibel, awer net bandwidth sensibel. Och eis Uwendungen ginn haaptsächlech op Cellular Netzwierker benotzt. Baséierend op Experimenter sinn Schwanzlatzen nach ëmmer héich, och wann Dir e Proxy benotzt fir TCP a QUIC no bei de Benotzer ofzeschléissen. Mir sichen aktiv no Weeër fir Stau Gestioun ze verbesseren an d'Effizienz vun QUIC Verloscht Erhuelung Algorithmen verbesseren.
Mat dësen an e puer aner Verbesserunge plangen mir d'Benotzererfarung onofhängeg vum Netzwierk a Regioun ze verbesseren, fir bequem an nahtlos Pakettransport méi zougänglech ronderëm d'Welt ze maachen.
Source: will.com