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
