Das QUIC-Protokoll ist äußerst faszinierend, und wir schreiben gerne darüber. Während frühere Beiträge über QUIC eher historischer (lokalgeschichtlicher, wenn Sie so wollen) und technischer Natur waren, freuen wir uns heute, eine andere Art von Übersetzung zu präsentieren – es geht um die tatsächliche Anwendung des Protokolls im Jahr 2019. Und hier sprechen wir nicht von einer kleinen Infrastruktur in einer garageähnlichen Umgebung, sondern von Uber, das fast weltweit agiert. Wie die Ingenieure des Unternehmens zur Entscheidung kamen, QUIC in der Produktion einzusetzen, welche Tests sie durchführten und was sie nach dem Rollout in der Produktion sahen – unter dem Link.
Bilder sind anklickbar. Viel Spaß beim Lesen!
Uber hat ein weltweites Netzwerk mit einer Präsenz in 600 Städten, in denen die App vollständig auf kabellose Internetverbindungen von mehr als 4500 Mobilfunkanbietern angewiesen ist. Die Benutzer erwarten nicht nur eine schnelle, sondern eine Echtzeit-Anwendung – um dies zu gewährleisten, benötigt die Uber-App niedrige Latenzzeiten und eine äußerst zuverlässige Verbindung. Leider ist jedoch das Protokoll hat Schwierigkeiten in dynamischen und verlustanfälligen drahtlosen Netzwerken. Wir haben festgestellt, dass in diesem Fall die niedrige Leistung direkt mit der Implementierung von TCP in den Betriebssystemkernen zusammenhängt.
Um das Problem zu lösen, haben wir , ein modernes Protokoll mit Kanal-Multiplexing, das uns mehr Kontrolle über die Leistung des Transportprotokolls gibt. Momentan arbeitet die Gruppe an der Standardisierung von QUIC als .
Nach detaillierten Tests sind wir zu dem Schluss gekommen, dass die Implementierung von QUIC in unsere Anwendung die "Tail"-Latenzen im Vergleich zu TCP verringern wird. Wir beobachteten eine Reduzierung im Bereich von 10-30 % für HTTPS-Verkehr am Beispiel der Fahrdienst- und Passagieranwendungen. Außerdem gab uns QUIC die vollständige Kontrolle über die Benutzerpakete.
In diesem Artikel teilen wir unsere Erfahrungen bei der Optimierung von TCP für Uber-Anwendungen mit einem Stack, der QUIC unterstützt.
Das letzte Wort der Technik: TCP.
Heute ist TCP das meistgenutzte Transportprotokoll für die Bereitstellung von HTTPS-Verkehr im Internet. TCP gewährleistet einen zuverlässigen Byte-Stream, der damit Netzwerküberlastungen und Verluste auf der Kanalebene bewältigt. Die weit verbreitete Nutzung von TCP für HTTPS-Verkehr erklärt sich aus der Allgegenwärtigkeit des Protokolls (fast jedes Betriebssystem enthält TCP), der Verfügbarkeit in einem Großteil der Infrastruktur (z. B. auf Lastenausgleichern, HTTPS-Proxys und CDNs) und der "Out-of-the-Box"-Funktionalität, die in den meisten Plattformen und Netzwerken verfügbar ist.
Die meisten Nutzer verwenden unsere Anwendung mobil, und die "Tail"-Latenzen von TCP entsprachen nicht den Anforderungen unseres Echtzeit-HTTPS-Verkehrs. Einfach gesagt, dieses Problem betrifft Nutzer weltweit – Abbildung 1 zeigt die Latenzen in großen Städten:
Abbildung 1. Die Höhe der „Tail“-Latenzen variiert in den Hauptstädten, in denen Uber präsent ist.
Obwohl die Latenzen in indischen und brasilianischen Netzwerken höher waren als in den USA und Großbritannien, sind die Tail-Latenzen deutlich größer als die durchschnittlichen Latenzen. Dies gilt auch für die USA und Großbritannien.
Die Leistung von TCP über Luftschnittstellen
TCP wurde für kabelgebundene Netzwerke entwickelt, das bedeutet, dass es auf gut vorhersehbare Verbindungen ausgerichtet ist. Bei drahtlosen Netzen sieht die Situation jedoch anders aus und bringt ihre eigenen Herausforderungen mit sich. Erstens sind drahtlose Netzwerke empfindlich gegenüber Verlusten aufgrund von Störungen und Signalabschwächung. Zum Beispiel sind Wi-Fi-Netzwerke anfällig für Mikrowellen, Bluetooth und andere Radiofrequenzen. Mobilfunknetze leiden unter Signalverlust () durch Reflexionen/Absorption von Signalen durch Objekte und Gebäude sowie durch von benachbarten . Dies führt zu signifikant höheren (4-10 Mal) und variierenden und Paketverlusten im Vergleich zu kabelgebundenen Verbindungen.
Um mit Schwankungen der Bandbreite und Verlusten umzugehen, verwenden Mobilfunknetze normalerweise große Puffer für Traffic-Spitzen. Dies kann zu übermäßiger Warteschlangenbildung führen, was größere Verzögerungen bedeutet. Oft interpretiert TCP eine solche Warteschlangenbildung als Verlust aufgrund der verlängerten Zeitüberschreitung, weshalb TCP dazu neigt, Retransmissionen durchzuführen und so den Puffer zu füllen. Dieses Problem ist bekannt als (, und es stellt ein sehr modernen Internet.
Die Leistung von Mobilfunknetzen variiert je nach Anbieter, Region und Tageszeit. In Abbildung 2 haben wir die medianen Latenzen des HTTPS-Verkehrs aus Zellen im Radius von 2 Kilometern zusammengetragen. Die Daten stammen von den beiden größten Mobilfunkanbietern in Delhi, Indien. Wie zu erkennen ist, variiert die Leistung von Zelle zu Zelle. Außerdem unterscheidet sich die Leistung des einen Anbieters von der des anderen. Einfluss darauf haben unter anderem die Zugangs-muster unter Berücksichtigung von Zeit und Standort, die Mobilität der Nutzer sowie die Netzwerkinfrastruktur in Bezug auf die Dichte der Türme und das Verhältnis der Netztypen (LTE, 3G usw.).
Abbildung 2. Latenzen im Beispiel eines 2-Kilometer-Radius. Delhi, Indien.
Zusätzlich variiert die Leistung der Mobilfunknetze im Zeitverlauf. In Abbildung 3 wird die mediane Latenz nach Wochentagen dargestellt. Wir beobachteten auch Unterschiede im kleineren Maßstab – innerhalb eines einzigen Tages und einer Stunde.
Abbildung 3. Die Latenzen können an verschiedenen Tagen erheblich schwanken, selbst bei demselben Anbieter.
All das führt dazu, dass die TCP-Leistung in drahtlosen Netzwerken ineffektiv ist. Bevor wir jedoch nach Alternativen zu TCP suchen, möchten wir ein genaues Verständnis zu den folgenden Punkten entwickeln:
- Ist TCP der Hauptgrund für Verzögerungen in unseren Anwendungen?
- Haben moderne Netzwerke bedeutende und vielfältige Rundlaufzeiten (RTT)?
- Wie wirken sich RTT und Verluste auf die Leistung von TCP aus?
Analyse der TCP-Leistung
Um zu verstehen, wie wir die Leistung von TCP analysiert haben, erinnern wir uns kurz daran, wie TCP Daten vom Sender zum Empfänger überträgt. Zunächst stellt der Sender eine TCP-Verbindung her, indem er einen dreifachen : Der Sender sendet ein SYN-Paket, wartet auf ein SYN-ACK-Paket vom Empfänger und sendet dann ein ACK-Paket. Weitere zweite und dritte Durchläufe sind erforderlich, um die TCP-Verbindung herzustellen. Der Empfänger bestätigt den Empfang jedes Pakets (ACK), um eine zuverlässige Lieferung zu gewährleisten.
Wenn ein Paket oder ACK verloren geht, sendet der Sender nach einer Zeitüberschreitung (RTO, ). Die RTO wird dynamisch berechnet, basierend auf verschiedenen Faktoren, wie z.B. der erwarteten RTT-Verzögerung zwischen Sender und Empfänger.
Abb. 4. Der Paketwechsel über TCP/TLS umfasst Retransmit-Mechanismen.
Um zu bestimmen, wie TCP in unseren Anwendungen funktioniert hat, haben wir TCP-Pakete mit Hilfe von über eine Woche hinweg auf dem Live-Verkehr von indischen Border-Servern verfolgt. Anschließend analysierten wir die TCP-Verbindungen mit . Darüber hinaus erstellten wir eine Android-App, die emulierten Verkehr an einen Testserver sendet und dabei den realen Verkehr möglichst genau nachahmt. Smartphones mit dieser App wurden an mehrere Mitarbeiter verteilt, die über mehrere Tage Protokolle sammelten.
Die Ergebnisse beider Experimente standen im Einklang miteinander. Wir beobachteten hohe RTT-Verzögerungen; die Spitzenwerte lagen fast sechsmal über dem Medianwert; der Durchschnitt der Verzögerungen betrug mehr als 1 Sekunde. Viele Verbindungen hatten Packetverluste, was dazu führte, dass TCP 3,5 % aller Pakete neu übertrug. In stark frequentierten Bereichen wie Flughäfen und Bahnhöfen sahen wir einen Verlust von 7 %. Solche Ergebnisse stellen die weitverbreitete Annahme in Frage, dass die in Mobilfunknetzen verwendeten die Verluste auf Transportebene erheblich reduzieren. Im Folgenden die Testergebnisse aus der Simulator-App:
Netzwerkmetriken
Werte
RTT, Millisekunden [50%, 75%, 95%, 99%]
[350, 425, 725, 2300]
RTT-Abweichung, Sekunden
Im Durchschnitt ~1,2 s
Packetverlust bei instabilen Verbindungen
Im Durchschnitt ~3,5 % (7 % in überlasteten Bereichen)
Fast die Hälfte dieser Verbindungen wies mindestens einen Paketverlust auf, wobei es sich hauptsächlich um SYN- und SYN-ACK-Pakete handelte. Die meisten TCP-Implementierungen verwenden einen RTO-Wert von 1 Sekunde für SYN-Pakete, der sich exponentiell für nachfolgende Verluste erhöht. Die Ladezeiten von Anwendungen können sich dadurch verlängern, dass TCP mehr Zeit benötigt, um Verbindungen herzustellen.
Bei Datenpaketen verringern hohe RTO-Werte die nützliche Auslastung des Netzwerks erheblich, insbesondere bei sporadischen Verlusten in drahtlosen Netzwerken. Wir haben festgestellt, dass die durchschnittliche Retransmissionszeit etwa 1 Sekunde beträgt, mit einer Nachlaufverzögerung von fast 30 Sekunden. Solche hohen TCP-Verzögerungen führten zu HTTPS-Timeouts und erneuten Anfragen, was die Verzögerung und Ineffizienz im Netzwerk zusätzlich erhöhte.
Während der 75. Perzentil der gemessenen RTT bei etwa 425 ms lag, betrug der 75. Perzentil für TCP fast 3 Sekunden. Dies deutet darauf hin, dass Verluste TCP dazu zwangen, 7-10 Durchgänge zu machen, um Daten erfolgreich zu übertragen. Dies könnte auf eine ineffiziente RTO-Berechnung oder die Unfähigkeit von TCP hinweisen, schnell auf Verluste zu reagieren. im Fenster und der Ineffizienz des Lastenmanagementalgorithmus, der drahtlose Verluste und Verluste aufgrund von Netzwerküberlastung nicht unterscheidet. Unten stehen die Ergebnisse der TCP-Verlusttests:
TCP-Paketverluststatistik
Bedeutung
Prozentsatz der Verbindungen mit mindestens 1 Paketverlust
45%
Prozentsatz der Verbindungen mit Verlusten während der Verbindungsherstellung
30%
Prozentsatz der Verbindungen mit Verlusten während des Datenaustauschs
76%
Verteilung der Verzögerungen bei der Retransmission, Sekunden [50%, 75%, 95%, 99%]
[1, 2.8, 15, 28]
Verteilung der Anzahl der Retransmissionen für ein Paket oder TCP-Segment
[1,3,6,7]
Anwendung von QUIC
Ursprünglich von Google entwickelt, ist QUIC ein moderner, mehrsträngiger Transportprotokoll, das über UDP arbeitet. Derzeit befindet sich QUIC in (wir haben bereits erwähnt, dass es sozusagen zwei Versionen von QUIC gibt, Neugierige – Anmerkung des Übersetzers). Wie in Abbildung 5 dargestellt, läuft QUIC unter HTTP/3 (eigentlich ist HTTP/2 über QUIC das, was jetzt als HTTP/3 standardisiert wird). Es ersetzt teilweise die Ebenen von HTTPS und TCP, indem es UDP zur Paketbildung verwendet. QUIC unterstützt nur die sichere Datenübertragung, da TLS vollständig in QUIC integriert ist.
Abbildung 5: QUIC arbeitet unter HTTP/3 und ersetzt TLS, das zuvor unter HTTP/2 lief.
Im Folgenden erläutern wir die Gründe, die uns überzeugt haben, QUIC zur Verbesserung von TCP einzusetzen:
- 0-RTT Verbindungsaufbau. QUIC ermöglicht die Wiederverwendung von Autorisierungen aus vorherigen Verbindungen und reduziert die Anzahl der Sicherheits-Handshakes. In Zukunft Überwindung von HoL-Blocking.
- HTTP/2 verwendet eine TCP-Verbindung für jeden Client, um die Leistung zu verbessern, was jedoch zu HoL (Head-of-Line) Blocking führen kann. QUIC vereinfacht das Multiplexing und liefert Anfragen unabhängig voneinander an die Anwendung. Überlastungssteuerung.
- Überlastungsmanagement. QUIC operiert auf der Anwendungsebene und ermöglicht eine einfachere Aktualisierung des Haupttransportalgorithmus, der die Datenübertragung basierend auf Netzwerkparametern (Paketverlust oder RTT) steuert. Die meisten TCP-Implementierungen nutzen den Algorithmus , der nicht optimal für latenzempfindlichen Datenverkehr ist. Neuere Algorithmen wie modellieren das Netzwerk präziser und optimieren die Latenz. QUIC ermöglicht die Verwendung von BBR und die Aktualisierung dieses Algorithmus, während er sich .
- Verlustausgleich. QUIC initiiert zwei TLP () bevor der RTO auslöst – selbst bei spürbarem Verlust. Dies unterscheidet sich von TCP-Implementierungen. TLP überträgt hauptsächlich das letzte Paket (oder ein neues, falls vorhanden), um einen schnellen Verlustausgleich einzuleiten. Die Verarbeitung von Tail-Loss ist besonders nützlich für die Art und Weise, wie Uber mit dem Netzwerk arbeitet, insbesondere für kurze, episodische und latenzempfindliche Datenübertragungen.
- optimiertes ACK. Da jedes Paket eine einzigartige Seriennummer hat, gibt es kein Problem bei der Pakete bei ihrer Weiterleitung. ACK-Pakete enthalten ebenfalls die Zeit für die Verarbeitung des Pakets und die Generierung des ACK auf der Client-Seite. Diese Eigenschaften gewährleisten, dass QUIC die RTT genauer berechnet. ACK in QUIC unterstützt bis zu 256 Bereiche. , was dem Sender hilft, robuster gegen Paketverlust zu sein und weniger Bytes im Prozess zu verwenden. Selektives ACK () in TCP löst dieses Problem nicht in allen Fällen.
- Verbindungs-Migration. QUIC-Verbindungen werden über eine 64-Bit-ID identifiziert, sodass der Client seine IP-Adressen wechseln kann und die ID der alten Verbindung weiterhin bei der neuen IP-Adresse verwendet werden kann, ohne Unterbrechungen. Dies ist eine häufige Praxis bei mobilen Anwendungen, wenn der Benutzer zwischen Wi-Fi- und Mobilverbindungen wechselt.
Alternativen zu QUIC
Wir haben alternative Ansätze zur Lösung des Problems betrachtet, bevor wir uns für QUIC entschieden haben.
Zunächst haben wir versucht, TPC PoPs (Points of Presence) zu implementieren, um TCP-Verbindungen näher bei den Nutzern zu beenden. Im Grunde genommen beendet der PoP die TCP-Verbindung mit dem mobilen Gerät näher am Mobilfunknetz und leitet den Datenverkehr zur ursprünglichen Infrastruktur weiter. Indem wir TCP näher beenden, können wir potenziell die RTT reduzieren und sicherstellen, dass TCP aktiver auf die dynamische drahtlose Umgebung reagiert. Unsere Experimente haben jedoch gezeigt, dass die RTT und Verluste größtenteils aus den Mobilfunknetzen stammen und die Nutzung von PoPs keine signifikante Leistungsverbesserung bietet.
Wir haben auch die Optimierung von TCP-Parametern in Betracht gezogen. Die Anpassung des TCP-Stacks auf unseren heterogenen Border-Servern war herausfordernd, da TCP in verschiedenen Betriebssystemversionen unterschiedlich implementiert ist. Es war schwierig, verschiedene Netzwerk-Konfigurationen zu implementieren und zu testen. Eine direkte Anpassung von TCP auf mobilen Geräten war wegen fehlender Berechtigungen nicht möglich. Noch wichtiger ist, dass Funktionen wie 0-RTT-Verbindungen und verbesserte RTT-Vorhersagen entscheidend für die Protokollarchitektur sind und daher kein wesentlicher Vorteil nur durch die Anpassung von TCP erzielt werden kann.
Schließlich haben wir mehrere auf UDP basierende Protokolle evaluiert, die Probleme im Video-Streaming beheben – wir wollten herausfinden, ob diese Protokolle in unserem Fall helfen würden. Leider fehlten ihnen zahlreiche Sicherheitsanpassungen, und sie benötigten zudem eine zusätzliche TCP-Verbindung für Metadaten und Steuerinformationen.
Unsere Untersuchungen haben gezeigt, dass QUIC wohl das einzige Protokoll ist, das bei Internetverkehrsproblemen helfen kann, während sowohl Sicherheit als auch Leistung berücksichtigt werden.
Integration von QUIC in die Plattform
Um QUIC erfolgreich zu integrieren und die Leistung der Anwendung bei schlechten Verbindungsbedingungen zu verbessern, haben wir den alten Stack (HTTP/2 über TLS/TCP) durch das QUIC-Protokoll ersetzt. Wir haben die Netzwerkbibliothek von , die die originale Google-Version des Protokolls – gQUIC – enthält. Diese Implementierung wird ständig verbessert, um der neuesten IETF-Spezifikation zu folgen.
Zuerst haben wir Cronet in unsere Android-Anwendungen integriert, um QUIC-Unterstützung hinzuzufügen. Die Integration wurde so umgesetzt, dass die Migrationskosten minimiert werden. , haben wir Cronet UNTER dem OkHttp API-Rahmen integriert. Durch diese Art der Integration haben wir Änderungen an unseren Netzwerkaufrufen (die ) auf API-Ebene vermieden.
Ähnlich wie bei Android-Geräten haben wir Cronet in die Uber-Anwendungen für iOS integriert, indem wir HTTP-Verkehr über Netzwerke abgefangen haben, , unter Verwendung von . Diese Abstraktion, die von der iOS Foundation bereitgestellt wird, verarbeitet protocollspezifische URL-Daten und stellt sicher, dass wir Cronet in unsere iOS-Anwendungen integrieren können, ohne erhebliche Migrationskosten.
QUIC-Abschluss auf Google Cloud Load Balancern
Der QUIC-Abschluss wird auf der Backend-Seite durch die Infrastruktur des Google Cloud Load Balancing bereitgestellt, die Header in den Antworten verwendet, um QUIC zu unterstützen. Im Allgemeinen fügt der Load Balancer jedem HTTP-Anfrage einen alt-svc-Header hinzu, der die Unterstützung von QUIC für die Domain validiert. Wenn der Cronet-Client eine HTTP-Antwort mit einem solchen Header erhält, nutzt er QUIC für nachfolgende HTTP-Anfragen an diese Domain. Sobald der Load Balancer QUIC beendet, sendet unsere Infrastruktur diese Aktion explizit über HTTP2/TCP an unsere Rechenzentren.
Leistung: Ergebnisse
Die bereitgestellte Leistung ist der Hauptgrund für unsere Suche nach dem besten Protokoll. Zu Beginn haben wir eine Testumgebung mit , um herauszufinden, wie sich QUIC unter verschiedenen Netzwerkprofilen verhält. Um die Leistung von QUIC in realen Netzwerken zu überprüfen, haben wir Experimente durchgeführt, während wir durch Neu-Delhi gefahren sind und dabei simulierten Netzwerkverkehr verwendet haben, der den HTTP-Anfragen in der Passagieranwendung sehr ähnlich ist.
Experiment 1
Ausstattung für das Experiment:
- Testgeräte mit Android, die die OkHttp- und Cronet-Stacks nutzen, um sicherzustellen, dass wir HTTPS-Verkehr über TCP und QUIC entsprechend ermöglichen;
- Ein Java-basierter Emulationsserver, der identische HTTPS-Header in den Antworten sendet und die Clientgeräte belastet, um Anfragen von ihnen zu erhalten;
- Cloud-Proxy-Server, die physisch in der Nähe von Indien liegen, um TCP- und QUIC-Verbindungen abzuschließen. Während wir für das TCP-Abschluss den Reverse-Proxy auf , benutzen konnten, war es schwierig, einen Open-Source-Reverse-Proxy für QUIC zu finden. Daher haben wir selbst einen Reverse-Proxy für QUIC entwickelt, der auf dem QUIC-Stack von Chromium basiert und dies als Open-Source in Chromium integriert.
Abbildung 6. Das Test-Setup für TCP vs QUIC bestand aus Android-Geräten mit OkHttp und Cronet, Cloud-Proxys zum Abschluss der Verbindungen und dem Emulationsserver.
Experiment 2
Als Google QUIC mit Hilfe von , wir haben dasselbe Inventar verwendet, jedoch mit einer Modifikation: Anstelle von NGINX haben wir die Google-Load-Balancer zur Beendigung von TCP- und QUIC-Verbindungen von Geräten sowie zur Weiterleitung von HTTPS-Verkehr an den Emulationsserver eingesetzt. Die Load-Balancer sind weltweit verteilt, verwenden jedoch den nächstgelegenen PoP-Server zum Gerät (danke an die Geolokalisierung).
Abbildung 7. Im zweiten Experiment wollten wir die Latenz der Beendigung von TCP und QUIC vergleichen: mit Google Cloud und unserem Cloud-Proxy.
Am Ende hatten wir einige Enthüllungen:
- Die Beendigung über PoP verbesserte die TCP-Leistung. Da die Load-Balancer die TCP-Verbindung näher bei den Benutzern beenden und hervorragend optimiert sind, resultiert dies in geringeren RTT, was die TCP-Leistung verbessert. Und obwohl sich dies weniger auf QUIC auswirkte, übertraf es dennoch TCP hinsichtlich der Reduzierung von Schlusslatenzen (um 10–30 Prozent).
- Die Schlusslatenzen werden beeinflusst von . Auch wenn unser QUIC-Proxy mit etwa 50 ms höheren Latenzen weiter von den Geräten entfernt war als die Google-Lastenausgleicher, erzielte er eine vergleichbare Leistung – ein Rückgang der Latenz um 15 % im Vergleich zu einem Rückgang von 20 % im 99. Percentil bei TCP. Dies weist darauf hin, dass der Übergang auf der letzten Meile ein Engpass in der Netzwerkleistung ist.
Abbildung 8. Die Ergebnisse zweier Experimente zeigen, dass QUIC TCP deutlich übertrifft.
Echtzeitverkehr
Inspiriert durch die Experimente haben wir die Unterstützung von QUIC in unsere Android- und iOS-Anwendungen integriert. Wir führten A/B-Tests durch, um den Einfluss von QUIC in den Städten, in denen Uber präsent ist, zu prüfen. Insgesamt beobachteten wir einen signifikanten Rückgang der Verzögerungen an den Enden sowohl in Bezug auf Regionen als auch auf Mobilfunkanbieter und Netztypen.
Die Grafiken unten zeigen die prozentualen Verbesserungen der Endverzögerungen (95. und 99. Percentil) nach Makroregionen und unterschiedlichen Netztypen – LTE, 3G, 2G.
Abbildung 9. In den Echtzeittests übertraf QUIC TCP in Bezug auf die Latenzen.
Nur nach vorne
Dies ist wohl erst der Anfang – die Einführung von QUIC in der Produktion bietet erstaunliche Möglichkeiten zur Verbesserung der Anwendungsleistung sowohl in stabilen als auch in instabilen Netzwerken, nämlich:
Erhöhung der Abdeckung
Nach der Analyse der Protokollleistung mit echtem Datenverkehr haben wir festgestellt, dass etwa 80 % der Sitzungen erfolgreich QUIC für alle Anfragen verwendet haben, während 15 % der Sitzungen eine Kombination aus QUIC und TCP genutzt haben. Wir gehen davon aus, dass diese Kombination auftritt, weil die Cronet-Bibliothek bei Timeouts auf TCP zurückschaltet, da sie echte UDP-Ausfälle und schlechte Netzwerkbedingungen nicht unterscheiden kann. Derzeit suchen wir nach einer Lösung für dieses Problem, während wir das nachfolgende QUIC-Deployment vorantreiben.
QUIC-Optimierung
Datenverkehr aus mobilen Anwendungen ist empfindlich gegenüber Verzögerungen, jedoch nicht gegenüber der Bandbreite. Zudem werden unsere Anwendungen hauptsächlich in Mobilfunknetzen genutzt. Basierend auf unseren Experimenten sind die Schlussverzögerungen immer noch hoch, selbst mit Proxys, die TCP und QUIC nahe am Benutzer beenden. Wir suchen aktiv nach Möglichkeiten, das Überlastmanagement zu verbessern und die Effizienz der QUIC-Verlustkompensationsalgorithmen zu steigern.
Mit diesen und weiteren Verbesserungen beabsichtigen wir, die Benutzererfahrung unabhängig vom Netzwerk und der Region zu optimieren, indem wir den bequemen und nahtlosen Pakettransport weltweit zugänglicher machen.
Quelle: habr.com
