Es ist Ă€uĂerst interessant, das QUIC-Protokoll zu beobachten, weshalb wir gerne darĂŒber schreiben. WĂ€hrend frĂŒhere Veröffentlichungen ĂŒber QUIC eher historischer (regionalhistorischer, wenn Sie so möchten) und materietechnischer Natur waren, freuen wir uns heute, eine Ăbersetzung anderer Art zu veröffentlichen â es geht um die tatsĂ€chliche Anwendung des Protokolls im Jahr 2019. Und es geht nicht um kleine Infrastrukturen, die in einer hypothetischen Garage basieren, sondern um Uber, das nahezu weltweit tĂ€tig ist. Wie die Ingenieure des Unternehmens zu der Entscheidung kamen, QUIC in der Produktion zu verwenden, wie sie Tests durchfĂŒhrten und was sie nach der Rollout in die Produktion sahen â mehr dazu im Folgenden.
Die Bilder sind anklickbar. Viel SpaĂ beim Lesen!
Uber ist von globaler Dimension, mit 600 StĂ€dten, in denen die App verfĂŒgbar ist, und in jeder dieser StĂ€dte verlĂ€sst sich die App vollstĂ€ndig auf drahtloses Internet von mehr als 4500 Mobilfunkanbietern. Die Benutzer erwarten, dass die App nicht nur schnell, sondern in Echtzeit funktioniert â um dies zu gewĂ€hrleisten, benötigt die Uber-App niedrige Latenzen und eine sehr zuverlĂ€ssige Verbindung. Leider verhĂ€lt sich der Stack schlecht in dynamischen und verlustanfĂ€lligen drahtlosen Netzwerken. Wir haben erkannt, dass in diesem Fall die geringe Leistung direkt mit den TCP-Implementierungen im Betriebssystemkern verbunden ist.
Um das Problem zu lösen, haben wir , ein modernes Protokoll mit Kanal-Multiplexing verwendet, das uns mehr Kontrolle ĂŒber die Leistung des Transportprotokolls gibt. Derzeit standardisiert die Arbeitsgruppe QUIC als .
Nach eingehenden Tests sind wir zu dem Schluss gekommen, dass die Implementierung von QUIC in unsere App die "Tail-Latenzen" im Vergleich zu TCP reduzieren wird. Wir haben eine Verringerung im Bereich von 10-30 % fĂŒr HTTPS-Verkehr anhand der Fahrer- und Passagieranwendungen beobachtet. AuĂerdem gab uns QUIC eine durchgĂ€ngige Kontrolle ĂŒber die Benutzerdatenpakete.
In diesem Artikel teilen wir unsere Erfahrungen bei der Optimierung von TCP fĂŒr Uber-Anwendungen mithilfe eines Stacks, der QUIC unterstĂŒtzt.
Das letzte Wort der Technik: TCP
Heute ist TCP das am hĂ€ufigsten verwendete Transportprotokoll fĂŒr die Lieferung von HTTPS-Traffic im Internet. TCP gewĂ€hrleistet einen zuverlĂ€ssigen Byte-Stream, wodurch es mit NetzwerkĂŒberlastungen und Verlusten auf der Kanalschicht fertig wird. Die weitreichende Anwendung von TCP fĂŒr HTTPS-Traffic ist auf die Allgegenwart des Protokolls zurĂŒckzufĂŒhren (so gut wie jedes Betriebssystem enthĂ€lt TCP), auf die VerfĂŒgbarkeit im GroĂteil der Infrastruktur (zum Beispiel auf Lastverteilern, HTTPS-Proxys und CDN) und auf die âOut-of-the-Boxâ-FunktionalitĂ€t, die fast auf den meisten Plattformen und Netzwerken verfĂŒgbar ist.
Die meisten Benutzer verwenden unsere Anwendung unterwegs, und die âSchwanzâ-Latenzen von TCP entsprachen nicht den Anforderungen unseres Echtzeit-HTTPS-Verkehrs. Einfach gesagt, dies war ein Problem, mit dem Benutzer weltweit konfrontiert waren â in Abbildung 1 sind die Latenzen in groĂen StĂ€dten dargestellt:
Abbildung 1. Die GröĂe der âSchwanzâ-Latenzen variiert in den wichtigen StĂ€dten, in denen Uber tĂ€tig ist.
Obwohl die Latenzen in indischen und brasilianischen Netzen höher waren als in den USA und GroĂbritannien, sind die Schwanzlatenzen deutlich höher als die durchschnittlichen Latenzen. Das gilt sogar fĂŒr die USA und GroĂbritannien.
Die Leistung von TCP ĂŒber Funk
TCP wurde fĂŒr kabelgebundene Netzwerke entwickelt, also mit einem Fokus auf gut vorhersagbaren Verbindungen. Allerdings haben drahtlose Netze ihre eigenen Eigenschaften und Schwierigkeiten. Erstens sind drahtlose Netzwerke empfindlich gegenĂŒber Verlusten durch Störungen und SignalabschwĂ€chung. Zum Beispiel sind Wi-Fi-Netze anfĂ€llig fĂŒr Mikrowellen, Bluetooth und andere Radiofrequenzen. Mobilfunknetze leiden unter Signalverlust () durch Reflexion/Absorption des Signals durch Objekte und GebĂ€ude sowie durch von benachbarten Dies fĂŒhrt zu bedeutenderen (4-10 mal) und vielfĂ€ltigeren und Packetverlusten im Vergleich zu kabelgebundenen Verbindungen.
Um mit den Schwankungen der Bandbreite und Verlusten umzugehen, nutzen Mobilfunknetze normalerweise groĂe Puffer fĂŒr Verkehrsspitzen. Dies kann zu ĂŒbermĂ€Ăigen Warteschlangen fĂŒhren, was gröĂere Latenzen bedeutet. Sehr oft interpretiert TCP eine solche Warteschlange als Verlust aufgrund des erhöhten Timeouts, weshalb TCP zum Retransmitieren neigt und dadurch den Puffer fĂŒllt. Dieses Problem ist bekannt als (), und das ist ein sehr modernen Internets.
Die Leistung des Mobilfunknetzes Ă€ndert sich je nach Betreiber, Region und Zeitpunkt. In Abbildung 2 haben wir die medialen Latenzen des HTTPS-Verkehrs ĂŒber Zellen im Umkreis von 2 Kilometer erfasst. Die Daten wurden fĂŒr die beiden gröĂten Mobilfunkanbieter in Delhi, Indien, gesammelt. Wie man feststellen kann, variiert die Leistung von Zelle zu Zelle. Auch die Leistung eines Anbieters unterscheidet sich von der des anderen. Dies wird durch Faktoren wie die Zugangsbedingungen zur Netzzeit und den Standort, die MobilitĂ€t der Nutzer und die Netzwerkinfrastruktur in Bezug auf die Dichte der Sendemasten und das VerhĂ€ltnis der Netztypen (LTE, 3G etc.) beeinflusst.
Abbildung 2. Latenzen im Beispiel eines 2-Kilometer-Radius. Delhi, Indien.
Auch die Leistung von Mobilfunknetzen Ă€ndert sich im Laufe der Zeit. In Abbildung 3 ist die mediane Latenz nach Wochentagen dargestellt. Wir haben auch Unterschiede im kleineren MaĂstab â im Zusammenhang mit einem Tag und einer Stunde â beobachtet.
Abbildung 3. Tail-Latenzen können zwischen verschiedenen Tagen erheblich variieren, aber beim gleichen Anbieter.
All dies fĂŒhrt dazu, dass die TCP-Leistung in drahtlosen Netzwerken ineffektiv ist. Bevor wir jedoch nach Alternativen zu TCP suchen, wollten wir ein genaues VerstĂ€ndnis fĂŒr die folgenden Punkte entwickeln:
- Ist TCP der Hauptverursacher der Tail-Latenzen in unseren Anwendungen?
- Haben moderne Netzwerke signifikante und vielfÀltige Round-Trip-Latenzen (RTT)?
- Wie wirken sich RTT und Verluste auf die TCP-Leistung aus?
Analyse der TCP-Leistung
Um zu verstehen, wie wir die TCP-Leistung analysiert haben, lassen Sie uns kurz daran erinnern, wie TCP Daten vom Sender zum EmpfĂ€nger ĂŒbertrĂ€gt. Zuerst stellt der Sender eine TCP-Verbindung her, indem er einen Drei-Wege- : der Sender sendet ein SYN-Paket, wartet auf ein SYN-ACK-Paket vom EmpfĂ€nger und sendet dann ein ACK-Paket. ZusĂ€tzliche zweite und dritte DurchgĂ€nge werden zur Herstellung der TCP-Verbindung benötigt. Der EmpfĂ€nger bestĂ€tigt den Erhalt jedes Pakets (ACK), um eine zuverlĂ€ssige Lieferung zu gewĂ€hrleisten.
Wenn ein Paket oder ACK verloren geht, ĂŒbertrĂ€gt der Sender es nach einer ZeitĂŒberschreitung (RTO, ). RTO wird dynamisch basierend auf verschiedenen Faktoren berechnet, beispielsweise auf der erwarteten RTT zwischen Sender und EmpfĂ€nger.
Abbildung 4. Der Paketwechsel ĂŒber TCP/TLS umfasst Mechanismen zur Retransmission.
Um zu bestimmen, wie TCP in unseren Anwendungen funktionierte, haben wir TCP-Pakete mithilfe von wĂ€hrend einer Woche im Echtverkehr von indischen Grenzservern verfolgt. AnschlieĂend haben wir die TCP-Verbindungen mit analysiert. DarĂŒber hinaus haben wir eine Android-App entwickelt, die emulierten Verkehr an einen Testserver sendet und dabei dem echten Verkehr möglichst genau nachempfĂ€ngt. Smartphones mit dieser App wurden mehreren Mitarbeitern zur VerfĂŒgung gestellt, die ĂŒber mehrere Tage Protokolle sammelten.
Die Ergebnisse beider Experimente standen im Einklang miteinander. Wir beobachteten hohe RTT-Verzögerungen; die Tail-Werte waren fast sechsmal höher als der Median; der Mittelwert der Verzögerungen betrug ĂŒber 1 Sekunde. Viele Verbindungen hatten Paketverluste, was dazu fĂŒhrte, dass TCP 3,5% aller Pakete retransmittierte. In ĂŒberlasteten Bereichen, wie FlughĂ€fen und Bahnhöfen, beobachteten wir Verlustquoten von 7%. Solche Ergebnisse stellen die gĂ€ngige Meinung in Frage, dass die in Mobilfunknetzen die Verluste auf Transportschichtniveau erheblich reduzieren. Nachfolgend die Testergebnisse aus der Simulations-App:
Netzwerkmetriken
Werte
RTT, Millisekunden [50%, 75%, 95%, 99%]
[350, 425, 725, 2300]
RTT-Abweichung, Sekunden
Im Durchschnitt ~1,2 s
Paketverlust in instabilen Verbindungen
Im Durchschnitt ~3,5% (7% in ĂŒberlasteten Bereichen)
In fast der HĂ€lfte dieser Verbindungen gab es mindestens einen Paketverlust, hauptsĂ€chlich bei SYN- und SYN-ACK-Paketen. Die meisten TCP-Implementierungen verwenden einen RTO-Wert von 1 Sekunde fĂŒr SYN-Pakete, der exponentiell fĂŒr nachfolgende Verluste erhöht wird. Die Ladezeiten der Anwendung können zunehmen, da TCP mehr Zeit fĂŒr die Einrichtung von Verbindungen benötigt.
Bei Datenpaketen verringern hohe RTO-Werte die nĂŒtzliche Netzwerkauslastung erheblich bei zeitweiligen Verlusten in drahtlosen Netzwerken. Wir haben festgestellt, dass die durchschnittliche Retransmissionszeit etwa 1 Sekunde betrĂ€gt, mit einer Tail-Verzögerung von fast 30 Sekunden. Solche hohen Verzögerungen auf TCP-Ebene fĂŒhrten zu HTTPS-Timeouts und Wiederholungsanfragen, was die Verzögerung und Ineffizienz des Netzwerks weiter 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. Das deutet darauf hin, dass Verluste dazu fĂŒhrten, dass TCP 7-10 DurchlĂ€ufe benötigte, um Daten erfolgreich zu ĂŒbertragen. Dies könnte auf eine ineffiziente Berechnung des RTO und die UnfĂ€higkeit von TCP zurĂŒckzufĂŒhren sein, schnell auf Verluste zu reagieren. im Fenster und der Ineffizienz des Staukontrollalgorithmus, der zwischen drahtlosen Verlusten und Verlusten aufgrund von NetzwerkĂŒberlastung nicht unterscheidet. Nachfolgend die Ergebnisse der TCP-Verlusttests:
Statistik der TCP-Paketverluste
Wert
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]
Einsatz von QUIC
UrsprĂŒnglich von Google entworfen, ist QUIC ein moderner, mehrstrĂ€ngiger Transportprotokoll, das auf UDP basiert. Derzeit befindet sich QUIC im (wir haben bereits erwĂ€hnt, dass es sozusagen zwei Versionen von QUIC gibt, Neugierige â Anm. des Ăbersetzers). Wie in Abbildung 5 gezeigt, befindet sich QUIC unter HTTP/3 (tatsĂ€chlich ist HTTP/2 ĂŒber QUIC das, was jetzt intensiv standardisiert wird). Es ersetzt teilweise die Ebenen von HTTPS und TCP, indem es UDP zur Paketbildung verwendet. QUIC unterstĂŒtzt nur sichere DatenĂŒbertragungen, da TLS vollstĂ€ndig in QUIC integriert ist.
Abbildung 5: QUIC funktioniert unter HTTP/3 und ersetzt TLS, das zuvor unter HTTP/2 arbeitete.
Im Folgenden geben wir die GrĂŒnde an, die uns ĂŒberzeugt haben, QUIC zur Verbesserung von TCP zu verwenden:
- 0-RTT-Verbindungsherstellung. QUIC ermöglicht die Wiederverwendung von Autorisierungen aus vorherigen Verbindungen, wodurch die Anzahl der Sicherheits-Handshakes reduziert wird. In Zukunft wird 0-RTT unterstĂŒtzen, jedoch wird das dreifache TCP-Handshake weiterhin obligatorisch sein.
- Ăberwindung der HoL-Blockierung. HTTP/2 verwendet eine einzelne TCP-Verbindung fĂŒr jeden Client, um die Leistung zu verbessern, aber das kann zu HoL (head-of-line) Blockierung fĂŒhren. QUIC erleichtert das Multiplexing und liefert Anfragen unabhĂ€ngig voneinander an die Anwendung.
- Staukontrolle. QUIC befindet sich auf der Anwendungsebene und ermöglicht eine vereinfachte Aktualisierung des Haupttransportalgorithmus, der die Ăbertragung basierend auf Netzwerkparametern (Verlustrate oder RTT) steuert. Die meisten TCP-Implementierungen verwenden den Algorithmus , der nicht optimal fĂŒr latenzempfindlichen Verkehr ist. Neu entwickelte Algorithmen wie modellieren das Netzwerk genauer und optimieren die Latenzen. QUIC ermöglicht die Nutzung von BBR und die Aktualisierung dieses Algorithmus im Zuge seiner .
- beim Verlustausgleich. QUIC löst zwei TLP () aus, bevor der RTO greift â selbst wenn die Verluste sehr spĂŒrbar sind. Dies unterscheidet sich von den TCP-Implementierungen. TLP ĂŒbertrĂ€gt in erster Linie das letzte Paket (oder ein neues, falls vorhanden), um eine schnelle Wiederherstellung zu initiieren. Die Verarbeitung von Verlusten am Ende ist besonders nĂŒtzlich fĂŒr die Art und Weise, wie Uber mit dem Netzwerk arbeitet, nĂ€mlich fĂŒr kurze, sporadische und latenzempfindliche DatenĂŒbertragungen.
- optimiertes ACK. Da jedes Paket eine eindeutige Sequenznummer hat, gibt es keine Probleme bei der von Paketen bei ihrer WiederĂŒbertragung. ACK-Pakete enthalten auch die Zeit fĂŒr die Verarbeitung des Pakets und die Generierung des ACKs auf der Client-Seite. Diese Eigenschaften sorgen dafĂŒr, dass QUIC RTT genauer berechnet. ACK in QUIC unterstĂŒtzt bis zu 256 Bereiche von , wodurch der Sender widerstandsfĂ€higer gegen Paketumsortierung ist und weniger Bytes im Prozess verwendet. Selektives ACK () in TCP löst dieses Problem nicht in allen FĂ€llen.
- Verbindungsmigration. QUIC-Verbindungen werden durch eine 64-Bit-ID identifiziert, sodass bei einer IP-AdressĂ€nderung des Clients die ID der alten Verbindung weiterhin ĂŒber die neue IP-Adresse verwendet werden kann, ohne Unterbrechungen. Dies ist eine sehr gĂ€ngige Praxis fĂŒr mobile Anwendungen, wenn der Nutzer zwischen Wi-Fi und mobilen Verbindungen wechselt.
Alternativen zu QUIC
Wir haben alternative AnsĂ€tze zur Lösung des Problems in Betracht gezogen, bevor wir uns fĂŒr QUIC entschieden haben.
ZunĂ€chst haben wir versucht, TPC PoPs (Points of Presence) einzurichten, um TCP-Verbindungen nĂ€her bei den Nutzern abzuschlieĂen. Im Grunde schlieĂt der PoP die TCP-Verbindung mit dem mobilen GerĂ€t nĂ€her am Mobilfunknetz ab und leitet den Verkehr zur ursprĂŒnglichen Infrastruktur weiter. Durch das Abschliessen von TCP nĂ€her können wir potenziell die RTT reduzieren und sicherstellen, dass TCP aktiver auf die dynamische drahtlose Umgebung reagiert. Unsere Experimente haben jedoch gezeigt, dass RTT und Verluste gröĂtenteils aus Mobilfunknetzen resultieren und die Verwendung von PoPs keine signifikante Verbesserung der Leistung bietet.
Wir haben uns auch mit der Feinabstimmung der TCP-Parameter beschĂ€ftigt. Die Anpassung des TCP-Stacks auf unseren heterogenen Edge-Servern erwies sich als schwierig, da TCP in verschiedenen OS-Versionen inkonsistente Implementierungen aufweist. Es war herausfordernd, verschiedene Netzwerk-Konfigurationen umzusetzen und zu testen. Zudem war eine direkte Einstellung von TCP auf mobilen GerĂ€ten aufgrund fehlender Berechtigungen nicht möglich. Noch wichtiger ist, dass Funktionen wie 0-RTT-Verbindungen und verbesserte RTT-Vorhersage entscheidend fĂŒr die Protokollarchitektur sind, sodass erhebliche Vorteile allein durch TCP-Anpassungen nicht erreichbar sind.
SchlieĂlich haben wir mehrere UDP-basierte Protokolle bewertet, die Probleme beim Video-Streaming beheben sollen â wir wollten herausfinden, ob diese Protokolle in unserem Fall hilfreich sind. Leider fehlten ihnen viele Sicherheitsanpassungen, und sie benötigten zudem eine zusĂ€tzliche TCP-Verbindung fĂŒr Metadaten und Steuerinformationen.
Unsere Forschungen haben ergeben, dass QUIC fast das einzige Protokoll ist, das zur Lösung des Internetverkehrsproblems beitragen kann und dabei sowohl Sicherheit als auch Leistung berĂŒcksichtigt.
Integration von QUIC in die Plattform
Um QUIC erfolgreich zu implementieren und die Leistung der Anwendung bei schlechten Verbindungen zu verbessern, haben wir den alten Stack (HTTP/2 ĂŒber TLS/TCP) durch das QUIC-Protokoll ersetzt. Wir haben die Netzwerkbibliothek aus , die die originale Google-Version des Protokolls â gQUIC â enthĂ€lt, eingesetzt. Diese Implementierung wird auch kontinuierlich weiterentwickelt, um der neuesten IETF-Spezifikation zu folgen.
ZunĂ€chst haben wir Cronet in unsere Android-Anwendungen integriert, um UnterstĂŒtzung fĂŒr QUIC hinzuzufĂŒgen. Die Integration wurde so vorgenommen, dass die Migrationskosten minimiert werden. Anstatt den alten Netzwerk-Stack, der die Bibliothek , vollstĂ€ndig zu ersetzen, haben wir Cronet UNTER dem OkHttp-API-Framework integriert. Durch diese Vorgehensweise haben wir Ănderungen an unseren Netzwerkaufrufen (die verwenden ) auf der API-Ebene vermieden.
Ăhnlich wie bei Android-GerĂ€ten haben wir Cronet in die Uber-Anwendungen auf iOS integriert, indem wir den HTTP-Verkehr ĂŒber die Netzwerke , unter Verwendung von abgefangen haben. Diese Abstraktion, die von iOS Foundation bereitgestellt wird, verarbeitet protokollspezifische URL-Daten und gewĂ€hrleistet, dass wir Cronet in unsere iOS-Anwendungen ohne wesentliche Migrationskosten integrieren können.
QUIC-Terminierung auf Google Cloud Load Balancers
Auf der Backend-Seite wird die QUIC-Terminierung 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-Anfrageheader den alt-svc-Header hinzu und validiert damit die QUIC-UnterstĂŒtzung fĂŒr die DomĂ€ne. Wenn der Cronet-Client eine HTTP-Antwort mit diesem Header erhĂ€lt, verwendet er QUIC fĂŒr nachfolgende HTTP-Anfragen an diese DomĂ€ne. Sobald der Load Balancer QUIC beendet, sendet unsere Infrastruktur diese Aktion ausdrĂŒcklich ĂŒber HTTP2/TCP an unsere Rechenzentren.
Leistung: Ergebnisse
Die erbrachte Leistung ist der Hauptgrund fĂŒr unsere Suche nach dem besten Protokoll. Zu Beginn haben wir eine Testumgebung mit , um herauszufinden, wie QUIC sich unter unterschiedlichen Netzwerkprofilen verhĂ€lt. Um die Funktionsweise von QUIC in realen Netzwerken zu ĂŒberprĂŒfen, fĂŒhrten wir Experimente durch, wĂ€hrend wir durch Neu-Delhi fuhren, wobei wir emulierten Netzwerkverkehr verwendeten, der sehr Ă€hnlich war wie HTTP-Anfragen in der Passagieranwendung.
Experiment 1
Inventar fĂŒr das Experiment:
- TestgerĂ€te auf Android mit den Stacks OkHttp und Cronet, um sicherzustellen, dass wir HTTPS-Verkehr ĂŒber TCP und QUIC entsprechend leiten;
- Java-basierter Emulationsserver, der identische HTTPS-Header in den Antworten sendet und die ClientgerÀte belastet, um Anfragen von ihnen zu erhalten;
- Cloud-Proxys, die physisch in der NĂ€he von Indien positioniert sind, um TCP- und QUIC-Verbindungen zu terminieren. WĂ€hrend wir fĂŒr die TCP-Terminierung einen Reverse-Proxy verwendet haben , es war schwierig, einen Open-Source-RĂŒckwĂ€rtproxy fĂŒr QUIC zu finden. Wir haben selbst einen RĂŒckwĂ€rtproxy fĂŒr QUIC erstellt, unter Verwendung des QUIC-Grundstapels aus Chromium und ihn als Open-Source in Chromium integriert.
Abbildung 6. Das Testset fĂŒr TCP vs. QUIC bestand aus Android-GerĂ€ten mit OkHttp und Cronet, Cloud-Proxys fĂŒr den Verbindungsabschluss und einem Emulationsserver.
Experiment 2
Als Google QUIC ĂŒber , zugĂ€nglich machte, verwendeten wir dasselbe Inventar, jedoch mit einer Modifikation: Statt NGINX nutzten wir Googles Lastausgleicher fĂŒr den Verbindungsabschluss von TCP und QUIC von den GerĂ€ten sowie zur Weiterleitung des HTTPS-Verkehrs an den Emulationsserver. Die Lastverteiler sind weltweit verteilt, verwenden aber den nĂ€chstgelegenen PoP-Server (danke Geolokalisierung).
Abbildung 7. Im zweiten Experiment wollten wir die Latenz des Verbindungsabschlusses von TCP und QUIC vergleichen: mithilfe von Google Cloud und unserem Cloud-Proxy.
Am Ende hatten wir einige EnthĂŒllungen:
- der Abschluss ĂŒber PoP verbesserte die TCP-Leistung. Da die Lastverteiler die TCP-Verbindung nĂ€her an den Benutzern abschlieĂen und hervorragend optimiert sind, fĂŒhrt das zu geringeren RTT, was die TCP-Leistung verbessert. Und obwohl dies QUIC weniger beeinflusste, ĂŒbertraf es dennoch TCP in Bezug auf die Reduzierung der Tail-Latenzen (um 10â30 Prozent).
- bei den Tails wirken sich . Obwohl unser QUIC-Proxy weiter von den GerĂ€ten entfernt war (etwa 50 ms höhere Latenz) als die Googleschen Lastverteiler, erzielte er eine Ă€hnliche Leistung â 15 % Reduzierung der Latenz im Vergleich zu 20 % Reduzierung im 99. Perzentil bei TCP. Dies deutet darauf hin, dass der Ăbergang auf der letzten Meile ein Engpass (Bottleneck) im Netzwerkbetrieb ist.
Abbildung 8. Die Ergebnisse der beiden Experimente zeigen, dass QUIC TCP deutlich ĂŒbertrifft.
Echtverkehr
Inspiriert von den Experimenten haben wir die UnterstĂŒtzung von QUIC in unsere Android- und iOS-Anwendungen integriert. Wir fĂŒhrten A/B-Tests durch, um die Auswirkungen von QUIC in den StĂ€dten zu bestimmen, in denen Uber prĂ€sent ist. Insgesamt beobachteten wir eine erhebliche Verringerung der Tail-Latenzen sowohl regional als auch nach Mobilfunkanbietern und Netztypen.
In den folgenden Grafiken sind die prozentualen Verbesserungen der Tails (95. und 99. Perzentil) nach Makroregionen und verschiedenen Netztypologien â LTE, 3G, 2G â dargestellt.
Abbildung 9. In den Echtzeittests ĂŒbertraf QUIC TCP in Bezug auf Latenzen.
Nur vorwÀrts
Vielleicht ist das erst der Anfang â die EinfĂŒhrung von QUIC in die Produktion hat erstaunliche Möglichkeiten zur Leistungssteigerung von Anwendungen sowohl in stabilen als auch in instabilen Netzwerken eröffnet, und zwar:
Erhöhung der Abdeckung
Durch die Analyse der Leistung des Protokolls im realen Datenverkehr haben wir festgestellt, dass etwa 80 % der Sessions erfolgreich QUIC fĂŒr Umgebungen und Clustern des Projekts verwendet wird. Dieses Prinzip bildet die Grundlage fĂŒr ein gutes Anfragen verwendet haben, wĂ€hrend 15 % der Sessions eine Kombination aus QUIC und TCP verwendet haben. Wir vermuten, dass diese Kombination entstanden ist, weil die Cronet-Bibliothek aufgrund von ZeitĂŒberschreitungen zurĂŒck auf TCP umschaltet, da sie echte UDP-Fehler und schlechte Netzwerkbedingungen nicht unterscheiden kann. Derzeit suchen wir nach einer Lösung fĂŒr dieses Problem, da wir an der weiteren Implementierung von QUIC arbeiten.
Optimierung von QUIC
Der Datenverkehr aus mobilen Anwendungen ist empfindlich gegenĂŒber Verzögerungen, nicht jedoch gegenĂŒber der Bandbreite. Zudem werden unsere Anwendungen hauptsĂ€chlich in Mobilfunknetzen genutzt. Basierend auf Experimenten sind die Warteschlangenverzögerungen weiterhin hoch, selbst wenn Proxys eingesetzt werden, um TCP und QUIC nahe an den Nutzern zu beenden. Wir suchen aktiv nach Möglichkeiten zur Verbesserung des Ăberlastungsmanagements und zur Steigerung der Effizienz von QUIC-Algorithmen zur Verlustkompensation.
Mit diesen und einigen anderen Verbesserungen planen wir, das Benutzererlebnis unabhÀngig vom Netzwerk und der Region zu verbessern und einen benutzerfreundlichen und nahtlosen Pakettransport weltweit zugÀnglicher zu machen.
Quelle: habr.com
