Das QUIC-Protokoll ist äußerst interessant anzusehen, weshalb wir gerne darüber schreiben. Aber wenn frühere Veröffentlichungen über QUIC eher historischer (lokaler, wenn Sie so wollen) Natur und Hardware waren, freuen wir uns heute, eine Übersetzung der anderen Art zu veröffentlichen – wir werden über die tatsächliche Anwendung des Protokolls im Jahr 2019 sprechen. Darüber hinaus sprechen wir nicht von einer kleinen Infrastruktur, die in einer sogenannten Garage angesiedelt ist, sondern von Uber, das fast auf der ganzen Welt operiert. Wie die Ingenieure des Unternehmens zu der Entscheidung kamen, QUIC in der Produktion einzusetzen, wie sie die Tests durchführten und was sie nach der Einführung in der Produktion sahen – unter dem Strich.
Die Bilder sind anklickbar. Viel Spaß beim Lesen!
Uber verfügt über eine globale Reichweite, nämlich in 600 Städten, in denen die Anwendung vollständig auf drahtloses Internet von mehr als 4500 Mobilfunkbetreibern angewiesen ist. Nutzer erwarten, dass die App nicht nur schnell, sondern auch in Echtzeit ist – um dies zu erreichen, benötigt die Uber-App eine geringe Latenz und eine sehr zuverlässige Verbindung. Leider, aber der Stapel funktioniert in dynamischen und verlustanfälligen drahtlosen Netzwerken nicht gut. Wir haben festgestellt, dass in diesem Fall die geringe Leistung direkt mit TCP-Implementierungen in Betriebssystemkernen zusammenhängt.
Um das Problem zu lösen, haben wir uns beworben , ein modernes Kanalmultiplexprotokoll, das uns mehr Kontrolle über die Leistung des Transportprotokolls gibt. Derzeit die Arbeitsgruppe standardisiert QUIC als .
Nach umfangreichen Tests kamen wir zu dem Schluss, dass die Implementierung von QUIC in unserer Anwendung im Vergleich zu TCP zu geringeren Tail-Latenzen führen würde. Wir haben eine Reduzierung des HTTPS-Verkehrs in den Fahrer- und Beifahreranwendungen im Bereich von 10–30 % beobachtet. QUIC gab uns außerdem eine umfassende Kontrolle über Benutzerpakete.
In diesem Artikel teilen wir unsere Erfahrungen bei der Optimierung von TCP für Uber-Anwendungen mithilfe eines Stacks, der QUIC unterstützt.
Die neueste Technologie: TCP
Heute ist TCP das am häufigsten verwendete Transportprotokoll für die Bereitstellung von HTTPS-Verkehr im Internet. TCP stellt einen zuverlässigen Bytestrom bereit und bewältigt so Netzwerküberlastungen und Verbindungsschichtverluste. Die weit verbreitete Verwendung von TCP für HTTPS-Verkehr ist auf die Allgegenwärtigkeit des ersteren (fast jedes Betriebssystem enthält TCP), die Verfügbarkeit auf den meisten Infrastrukturen (z. B. Load Balancer, HTTPS-Proxys und CDNs) und die sofort einsatzbereiten Funktionen zurückzuführen auf fast den meisten Plattformen und Netzwerken.
Die meisten Benutzer nutzen unsere App unterwegs und die TCP-Tail-Latenzen entsprachen bei weitem nicht den Anforderungen unseres Echtzeit-HTTPS-Verkehrs. Vereinfacht gesagt haben Benutzer auf der ganzen Welt dies erlebt – Abbildung 1 zeigt Verzögerungen in Großstädten:
Abbildung 1: Die Tail-Latenz variiert in den Uber-Hauptstädten.
Obwohl die Latenz in indischen und brasilianischen Netzwerken höher war als in den USA und im Vereinigten Königreich, ist die Tail-Latenz deutlich höher als die durchschnittliche Latenz. Und das gilt sogar für die USA und Großbritannien.
TCP-Over-the-Air-Leistung
TCP wurde erstellt für verdrahtet Netzwerke, d. h. mit Schwerpunkt auf hoch vorhersehbaren Verbindungen. Jedoch, kabellos Netzwerke haben ihre eigenen Merkmale und Schwierigkeiten. Erstens sind drahtlose Netzwerke anfällig für Verluste aufgrund von Interferenzen und Signaldämpfung. Wi-Fi-Netzwerke reagieren beispielsweise empfindlich auf Mikrowellen, Bluetooth und andere Radiowellen. Mobilfunknetze leiden unter Signalverlust () durch Reflexion/Absorption des Signals durch Objekte und Gebäude sowie durch aus der Nachbarschaft . Dies führt zu größerer Bedeutung (4-10 Mal) und vielfältiger und Paketverlust im Vergleich zu einer kabelgebundenen Verbindung.
Um Bandbreitenschwankungen und -verlusten entgegenzuwirken, nutzen Mobilfunknetze typischerweise große Puffer für Verkehrsspitzen. Dies kann zu übermäßigen Warteschlangen und damit zu längeren Verzögerungen führen. Sehr oft behandelt TCP diese Warteschlange aufgrund einer verlängerten Zeitüberschreitung als Verschwendung, sodass TCP dazu neigt, weiterzuleiten und dadurch den Puffer zu füllen. Dieses Problem ist bekannt als (), und das ist sehr modernes Internet.
Schließlich variiert die Leistung des Mobilfunknetzes je nach Mobilfunkanbieter, Region und Zeit. In Abbildung 2 haben wir die mittleren Verzögerungen des HTTPS-Verkehrs über Zellen in einem Umkreis von 2 Kilometern erfasst. Daten wurden für zwei große Mobilfunkbetreiber in Delhi, Indien, gesammelt. Wie Sie sehen, variiert die Leistung von Zelle zu Zelle. Außerdem unterscheidet sich die Produktivität eines Bedieners von der Produktivität des zweiten. Dies wird durch Faktoren wie Netzwerkeintrittsmuster unter Berücksichtigung von Zeit und Ort, Benutzermobilität sowie Netzwerkinfrastruktur unter Berücksichtigung der Turmdichte und dem Verhältnis der Netzwerktypen (LTE, 3G usw.) beeinflusst.
Abbildung 2. Verzögerungen am Beispiel eines Radius von 2 km. Delhi, Indien.
Außerdem schwankt die Leistung von Mobilfunknetzen im Laufe der Zeit. Abbildung 3 zeigt die mittlere Latenz nach Wochentag. Wir beobachteten auch Unterschiede in kleinerem Maßstab, innerhalb eines einzigen Tages und einer einzigen Stunde.
Abbildung 3. Die Verzögerungen am Ende können von Tag zu Tag erheblich variieren, jedoch für denselben Betreiber.
All dies führt dazu, dass die TCP-Leistung in drahtlosen Netzwerken ineffektiv ist. Bevor wir jedoch nach Alternativen zu TCP suchten, wollten wir ein genaues Verständnis zu folgenden Punkten entwickeln:
- Ist TCP der Hauptverursacher der Tail-Latenzen in unseren Anwendungen?
- Verfügen moderne Netzwerke über erhebliche und unterschiedliche Round-Trip-Delays (RTT)?
- Welche Auswirkungen haben RTT und Verlust auf die TCP-Leistung?
TCP-Leistungsanalyse
Um zu verstehen, wie wir die TCP-Leistung analysiert haben, werfen wir einen kurzen Blick darauf, wie TCP Daten von einem Sender an einen Empfänger überträgt. Zunächst stellt der Absender eine TCP-Verbindung her und führt dabei eine Drei-Wege-Verbindung durch : Der Absender sendet ein SYN-Paket, wartet auf ein SYN-ACK-Paket vom Empfänger und sendet dann ein ACK-Paket. Für den Aufbau der TCP-Verbindung wird ein zusätzlicher zweiter und dritter Durchgang aufgewendet. Der Empfänger bestätigt den Empfang jedes Pakets (ACK), um eine zuverlässige Zustellung zu gewährleisten.
Wenn ein Paket oder eine ACK verloren geht, sendet der Absender nach einer Zeitüberschreitung (RTO, ). RTO wird dynamisch basierend auf verschiedenen Faktoren berechnet, beispielsweise der erwarteten RTT-Verzögerung zwischen Sender und Empfänger.
Abbildung 4. Der Paketaustausch über TCP/TLS umfasst einen Neuübertragungsmechanismus.
Um festzustellen, wie TCP in unseren Anwendungen funktioniert, haben wir TCP-Pakete überwacht eine Woche lang über den Kampfverkehr, der von indischen Edge-Servern kommt. Anschließend haben wir die TCP-Verbindungen analysiert . Darüber hinaus haben wir eine Android-Anwendung erstellt, die emulierten Datenverkehr an einen Testserver sendet und dabei den realen Datenverkehr so weit wie möglich imitiert. Smartphones mit dieser Anwendung wurden an mehrere Mitarbeiter verteilt, die über mehrere Tage hinweg Protokolle sammelten.
Die Ergebnisse beider Experimente stimmten überein. Wir haben hohe RTT-Latenzen gesehen; Die Endwerte waren fast sechsmal höher als der Medianwert. das arithmetische Mittel der Verzögerungen beträgt mehr als 6 Sekunde. Viele Verbindungen waren verlustbehaftet, was dazu führte, dass TCP 1 % aller Pakete erneut übertrug. In überlasteten Gebieten wie Flughäfen und Bahnhöfen verzeichneten wir Verluste von 3,5 %. Diese Ergebnisse lassen Zweifel an der herkömmlichen Meinung aufkommen, die in Mobilfunknetzen verwendet wird Verluste auf Transportebene deutlich reduzieren. Nachfolgend finden Sie die Testergebnisse der „Simulator“-Anwendung:
Netzwerkmetriken
Die Werte
RTT, Millisekunden [50 %, 75 %, 95 %, 99 %]
[350, 425, 725, 2300]
RTT-Divergenz, Sekunden
Im Durchschnitt ~1,2 s
Paketverlust bei instabilen Verbindungen
Durchschnittlich ~3.5 % (7 % in überlasteten Gebieten)
Fast die Hälfte dieser Verbindungen hatte mindestens einen Paketverlust, die meisten davon waren SYN- und SYN-ACK-Pakete. Die meisten TCP-Implementierungen verwenden einen RTO-Wert von 1 Sekunde für SYN-Pakete, der bei nachfolgenden Verlusten exponentiell ansteigt. Die Ladezeiten von Anwendungen können sich verlängern, da TCP länger braucht, um Verbindungen herzustellen.
Bei Datenpaketen verringern hohe RTO-Werte die nutzbare Auslastung des Netzwerks bei vorübergehenden Verlusten in drahtlosen Netzwerken erheblich. Wir haben festgestellt, dass die durchschnittliche Neuübertragungszeit etwa 1 Sekunde beträgt, mit einer Endverzögerung von fast 30 Sekunden. Diese hohen Latenzen auf TCP-Ebene führten zu HTTPS-Zeitüberschreitungen und erneuten Anfragen, was die Netzwerklatenz und Ineffizienz weiter erhöhte.
Während das 75. Perzentil der gemessenen RTT bei etwa 425 ms lag, betrug das 75. Perzentil für TCP fast 3 Sekunden. Dies deutet darauf hin, dass der Verlust dazu führte, dass TCP 7–10 Durchgänge benötigte, um Daten erfolgreich zu übertragen. Dies kann eine Folge einer ineffizienten RTO-Berechnung und der Unfähigkeit von TCP sein, schnell auf Verluste zu reagieren im Fenster und die Ineffizienz des Überlastungskontrollalgorithmus, der nicht zwischen drahtlosen Verlusten und Verlusten aufgrund von Netzwerküberlastung unterscheidet. Nachfolgend finden Sie die Ergebnisse der TCP-Verlusttests:
Statistiken zum TCP-Paketverlust
Wert
Prozentsatz der Verbindungen mit mindestens 1 Paketverlust
45%
Prozentsatz der Verbindungen mit Verlusten während des Verbindungsaufbaus
30%
Prozentsatz der Verbindungen mit Verlusten während des Datenaustauschs
76%
Verteilung der Verzögerungen bei der erneuten Übertragung, Sekunden [50 %, 75 %, 95 %, 99 %] [1, 2.8, 15, 28]
Verteilung der Anzahl der erneuten Übertragungen für ein Paket oder TCP-Segment
[1,3,6,7]
Anwendung von QUIC
QUIC wurde ursprünglich von Google entwickelt und ist ein modernes Multithread-Transportprotokoll, das auf UDP läuft. Derzeit ist QUIC in (Wir haben bereits geschrieben, dass es sozusagen zwei Versionen von QUIC gibt, neugierig – ca. Übersetzer). Wie in Abbildung 5 dargestellt, wird QUIC unter HTTP/3 platziert (tatsächlich ist HTTP/2 über QUIC HTTP/3, das derzeit intensiv standardisiert wird). Es ersetzt teilweise die HTTPS- und TCP-Schichten, indem es UDP zum Bilden von Paketen verwendet. QUIC unterstützt nur die sichere Datenübertragung, da TLS vollständig in QUIC integriert ist.
Abbildung 5: QUIC läuft unter HTTP/3 und ersetzt TLS, das zuvor unter HTTP/2 lief.
Nachfolgend sind die Gründe aufgeführt, die uns überzeugt haben, QUIC für die TCP-Amplifikation zu verwenden:
- 0-RTT-Verbindungsaufbau. QUIC ermöglicht die Wiederverwendung von Autorisierungen aus früheren Verbindungen und reduziert so die Anzahl der Sicherheits-Handshakes. In der Zukunft unterstützt 0-RTT, es ist jedoch weiterhin ein Drei-Wege-TCP-Handshake erforderlich.
- Überwindung der HoL-Blockierung. HTTP/2 verwendet eine TCP-Verbindung pro Client, um die Leistung zu verbessern. Dies kann jedoch zu einer HoL-Blockierung (Head-of-Line) führen. QUIC vereinfacht das Multiplexen und übermittelt Anfragen unabhängig an die Anwendung.
- Staukontrolle. QUIC befindet sich auf der Anwendungsebene und erleichtert die Aktualisierung des Haupttransportalgorithmus, der den Versand basierend auf Netzwerkparametern (Anzahl der Verluste oder RTT) steuert. Die meisten TCP-Implementierungen verwenden den Algorithmus , was für latenzempfindlichen Datenverkehr nicht optimal ist. Kürzlich entwickelte Algorithmen wie , das Netzwerk genauer modellieren und die Latenz optimieren. Mit QUIC können Sie BBR verwenden und diesen Algorithmus bei der Verwendung aktualisieren. .
- Auffüllung der Verluste. QUIC ruft zwei TLPs auf (), bevor der RTO ausgelöst wird – auch wenn die Verluste sehr spürbar sind. Dies unterscheidet sich von TCP-Implementierungen. TLP überträgt hauptsächlich das letzte Paket (oder das neue, falls vorhanden) erneut, um eine schnelle Wiederauffüllung auszulösen. Der Umgang mit Tail-Delays ist besonders nützlich für die Art und Weise, wie Uber sein Netzwerk betreibt, nämlich für kurze, sporadische und latenzempfindliche Datenübertragungen.
- optimiertes ACK. Da jedes Paket eine eindeutige Sequenznummer hat, gibt es kein Problem Pakete, wenn sie erneut übertragen werden. ACK-Pakete enthalten auch Zeit zum Verarbeiten des Pakets und zum Generieren eines ACK auf der Clientseite. Diese Funktionen stellen sicher, dass QUIC die RTT genauer berechnet. ACK in QUIC unterstützt bis zu 256 Bänder Dies hilft dem Absender, widerstandsfähiger gegen Paket-Shuffling zu sein und dabei weniger Bytes zu verbrauchen. Selektive ACK () in TCP löst dieses Problem nicht in allen Fällen.
- Verbindungsmigration. QUIC-Verbindungen werden durch eine 64-Bit-ID identifiziert. Wenn also ein Client die IP-Adresse ändert, kann die alte Verbindungs-ID ohne Unterbrechung weiterhin auf der neuen IP-Adresse verwendet werden. Dies ist eine sehr gängige Vorgehensweise bei mobilen Anwendungen, bei denen der Benutzer zwischen WLAN- und Mobilfunkverbindungen wechselt.
Alternativen zu QUIC
Wir haben alternative Lösungsansätze für das Problem in Betracht gezogen, bevor wir uns für QUIC entschieden haben.
Als erstes haben wir versucht, TPC-PoPs (Points of Presence) einzusetzen, um TCP-Verbindungen näher an den Benutzern zu beenden. Im Wesentlichen beenden PoPs eine TCP-Verbindung mit einem mobilen Gerät, das näher am Mobilfunknetz liegt, und leiten den Datenverkehr per Proxy zurück zur ursprünglichen Infrastruktur. Indem wir TCP näher terminieren, können wir möglicherweise die RTT reduzieren und sicherstellen, dass TCP besser auf eine dynamische drahtlose Umgebung reagiert. Unsere Experimente haben jedoch gezeigt, dass der größte Teil der RTT und der Verluste aus Mobilfunknetzen stammt und die Verwendung von PoPs keine signifikante Leistungsverbesserung bietet.
Wir haben uns auch mit der Optimierung der TCP-Parameter befasst. Das Einrichten eines TCP-Stacks auf unseren heterogenen Edge-Servern war schwierig, da TCP in verschiedenen Betriebssystemversionen unterschiedliche Implementierungen aufweist. Es war schwierig, dies umzusetzen und verschiedene Netzwerkkonfigurationen zu testen. Die direkte Konfiguration von TCP auf Mobilgeräten war aufgrund fehlender Berechtigungen nicht möglich. Noch wichtiger ist, dass Funktionen wie 0-RTT-Verbindungen und eine verbesserte RTT-Vorhersage für die Architektur des Protokolls von entscheidender Bedeutung sind und es daher unmöglich ist, durch die Optimierung von TCP allein signifikante Vorteile zu erzielen.
Schließlich haben wir mehrere UDP-basierte Protokolle zur Fehlerbehebung beim Video-Streaming evaluiert – wir wollten sehen, ob diese Protokolle in unserem Fall hilfreich wären. Leider fehlten ihnen viele Sicherheitseinstellungen erheblich und sie erforderten zudem eine zusätzliche TCP-Verbindung für Metadaten und Kontrollinformationen.
Unsere Forschung hat gezeigt, dass QUIC möglicherweise das einzige Protokoll ist, das bei dem Problem des Internetverkehrs helfen kann und dabei sowohl Sicherheit als auch Leistung berücksichtigt.
Integration von QUIC in die Plattform
Um QUIC erfolgreich einzubetten und die Anwendungsleistung in Umgebungen mit schlechter Konnektivität zu verbessern, haben wir den alten Stack (HTTP/2 über TLS/TCP) durch das QUIC-Protokoll ersetzt. Wir haben die Netzwerkbibliothek verwendet von , das die ursprüngliche Google-Version des Protokolls enthält – gQUIC. Auch diese Implementierung wird ständig verbessert, um der neuesten IETF-Spezifikation zu entsprechen.
Wir haben Cronet zunächst in unsere Android-Apps integriert, um Unterstützung für QUIC hinzuzufügen. Die Integration wurde so durchgeführt, dass die Migrationskosten so gering wie möglich gehalten werden. Anstatt den alten Netzwerk-Stack, der die Bibliothek verwendet, vollständig zu ersetzen , wir haben Cronet UNTER dem OkHttp API-Framework integriert. Durch die Integration auf diese Weise haben wir Änderungen an unseren Netzwerkaufrufen (die von verwendet werden) vermieden ) auf der API-Ebene.
Ähnlich wie bei Android-Geräten haben wir Cronet in Uber-Apps auf iOS implementiert und so den HTTP-Verkehr vom Netzwerk abgefangen Verwendung . Diese von der iOS Foundation bereitgestellte Abstraktion verarbeitet protokollspezifische URL-Daten und stellt sicher, dass wir Cronet ohne nennenswerte Migrationskosten in unsere iOS-Anwendungen integrieren können.
QUIC auf Google Cloud Balancers abschließen
Auf der Backend-Seite wird die QUIC-Vervollständigung durch die Google Cloud Load Balancing-Infrastruktur bereitgestellt, die verwendet wird Header in Antworten zur Unterstützung von QUIC. Im Allgemeinen fügt der Balancer jeder HTTP-Anfrage einen alt-svc-Header hinzu, der bereits die QUIC-Unterstützung für die Domäne validiert. Wenn ein Cronet-Client eine HTTP-Antwort mit diesem Header empfängt, verwendet er QUIC für nachfolgende HTTP-Anfragen an diese Domäne. Sobald der Balancer QUIC abschließt, sendet unsere Infrastruktur diese Aktion explizit über HTTP2/TCP an unsere Rechenzentren.
Leistungsergebnisse
Die Ausgabeleistung ist der Hauptgrund für unsere Suche nach einem besseren Protokoll. Zunächst haben wir einen Stand mit aufgebaut um herauszufinden, wie sich QUIC unter verschiedenen Netzwerkprofilen verhält. Um die Leistung von QUIC in realen Netzwerken zu testen, haben wir während einer Fahrt durch Neu-Delhi Experimente durchgeführt und dabei emulierten Netzwerkverkehr verwendet, der HTTP-Aufrufen in der Passagier-App sehr ähnlich ist.
Experiment 1
Ausrüstung für das Experiment:
- Testen Sie Android-Geräte mit OkHttp- und Cronet-Stacks, um sicherzustellen, dass wir HTTPS-Verkehr über TCP bzw. QUIC zulassen;
- ein Java-basierter Emulationsserver, der in Antworten denselben Typ von HTTPS-Headern sendet und Clientgeräte lädt, um Anfragen von ihnen zu empfangen;
- Cloud-Proxys, die sich physisch in der Nähe von Indien befinden, um TCP- und QUIC-Verbindungen zu beenden. Für die TCP-Terminierung verwendeten wir einen Reverse-Proxy war es schwierig, einen Open-Source-Reverse-Proxy für QUIC zu finden. Wir haben selbst einen Reverse-Proxy für QUIC erstellt, indem wir den grundlegenden QUIC-Stack von Chromium und verwendet haben es als Open Source in Chrom umwandeln.
Abbildung 6. Die Straßentestsuite TCP vs. QUIC bestand aus Android-Geräten mit OkHttp und Cronet, Cloud-Proxys zum Beenden von Verbindungen und einem Emulationsserver.
Experiment 2
Als Google QUIC mit verfügbar machte haben wir das gleiche Inventar verwendet, jedoch mit einer Änderung: Anstelle von NGINX haben wir Google Load Balancer verwendet, um TCP- und QUIC-Verbindungen von Geräten zu beenden und HTTPS-Verkehr an den Emulationsserver weiterzuleiten. Balancer sind auf der ganzen Welt verteilt, nutzen aber den PoP-Server, der dem Gerät am nächsten liegt (dank Geolokalisierung).
Abbildung 7. Im zweiten Experiment wollten wir die Abschlusslatenz von TCP und QUIC vergleichen: mit Google Cloud und mit unserem Cloud-Proxy.
Infolgedessen erwarteten uns mehrere Enthüllungen:
- Terminierung über PoP verbesserte TCP-Leistung. Da Balancer TCP-Verbindungen näher an den Benutzern beenden und stark optimiert sind, führt dies zu niedrigeren RTTs, was die TCP-Leistung verbessert. Und obwohl QUIC weniger betroffen war, übertraf es TCP immer noch in Bezug auf die Reduzierung der Tail-Latenz (um 10–30 Prozent).
- Schwänze sind betroffen . Obwohl unser QUIC-Proxy weiter von den Geräten entfernt war (etwa 50 ms höhere Latenz) als die Load Balancer von Google, lieferte er eine ähnliche Leistung – eine Reduzierung der Latenz um 15 % gegenüber einer Reduzierung des 20. Perzentils für TCP um 99 %. Dies deutet darauf hin, dass der Übergang auf der letzten Meile einen Engpass im Netzwerk darstellt.
Abbildung 8: Ergebnisse aus zwei Experimenten zeigen, dass QUIC TCP deutlich übertrifft.
Bekämpfung des Verkehrs
Inspiriert durch Experimente haben wir die QUIC-Unterstützung in unsere Android- und iOS-Anwendungen implementiert. Wir haben A/B-Tests durchgeführt, um die Wirkung von QUIC in den Städten zu ermitteln, in denen Uber tätig ist. Im Allgemeinen konnten wir in beiden Regionen, bei den Telekommunikationsbetreibern und beim Netzwerktyp, einen deutlichen Rückgang der Verzögerungen feststellen.
Die folgenden Grafiken zeigen die prozentualen Verbesserungen in den Tails (95 und 99 Perzentile) nach Makroregion und verschiedenen Netzwerktypen – LTE, 3G, 2G.
Abbildung 9. In Kampftests übertraf QUIC TCP hinsichtlich der Latenz.
Nur vorwärts
Vielleicht ist dies erst der Anfang – die Veröffentlichung von QUIC in der Produktion hat erstaunliche Möglichkeiten zur Verbesserung der Anwendungsleistung sowohl in stabilen als auch instabilen Netzwerken eröffnet, nämlich:
Erhöhte Abdeckung
Nachdem wir die Leistung des Protokolls im realen Datenverkehr analysiert hatten, stellten wir fest, dass QUIC in etwa 80 % der Sitzungen erfolgreich eingesetzt wurde alle Anfragen, während 15 % der Sitzungen eine Kombination aus QUIC und TCP verwendeten. Wir gehen davon aus, dass die Kombination auf eine Zeitüberschreitung der Cronet-Bibliothek zurück zu TCP zurückzuführen ist, da sie nicht zwischen echten UDP-Ausfällen und schlechten Netzwerkbedingungen unterscheiden kann. Wir suchen derzeit nach einer Lösung für dieses Problem, während wir an der späteren Implementierung von QUIC arbeiten.
QUIC-Optimierung
Der Datenverkehr von mobilen Apps ist latenzempfindlich, jedoch nicht bandbreitenempfindlich. Außerdem werden unsere Anwendungen hauptsächlich in Mobilfunknetzen verwendet. Experimenten zufolge sind die Tail-Latenzen immer noch hoch, obwohl ein Proxy zum Beenden von TCP und QUIC in der Nähe von Benutzern verwendet wird. Wir suchen aktiv nach Möglichkeiten, das Überlastungsmanagement zu verbessern und die Effizienz der QUIC-Algorithmen zur Verlustwiederherstellung zu steigern.
Mit diesen und mehreren anderen Verbesserungen planen wir, das Benutzererlebnis unabhängig von Netzwerk und Region zu verbessern und den bequemen und nahtlosen Pakettransport weltweit zugänglicher zu machen.
Source: habr.com