Het QUIC-protocol is buitengewoon interessant om naar te kijken en daarom schrijven we er graag over. Maar als eerdere publicaties over QUIC meer van historische (lokale geschiedenis, als je wilt) aard en hardware waren, publiceren we vandaag graag een vertaling van een ander soort - we zullen in 2019 praten over de echte toepassing van het protocol. Bovendien hebben we het niet over kleine infrastructuur gevestigd in een zogenaamde garage, maar over Uber, dat vrijwel over de hele wereld actief is. Hoe de ingenieurs van het bedrijf tot de beslissing kwamen om QUIC in de productie te gebruiken, hoe ze de tests uitvoerden en wat ze zagen nadat ze het in productie hadden geïntroduceerd - onder de snede.
De foto's zijn klikbaar. Veel plezier met lezen!
Uber heeft een mondiale schaal, namelijk 600 aanwezigheidssteden, waarbij de toepassing in elke stad volledig afhankelijk is van draadloos internet van meer dan 4500 mobiele operators. Gebruikers verwachten dat de app niet alleen snel is, maar ook in realtime. Om dit te bereiken heeft de Uber-app een lage latentie en een zeer betrouwbare verbinding nodig. Helaas, maar de stapel doet het niet goed in dynamische en verliesgevoelige draadloze netwerken. We realiseerden ons dat in dit geval lage prestaties rechtstreeks verband houden met TCP-implementaties in besturingssysteemkernels.
Om het probleem op te lossen, hebben we een aanvraag ingediend , een modern kanaalmultiplexprotocol dat ons meer controle geeft over de prestaties van het transportprotocol. Momenteel de werkgroep standaardiseert QUIC als .
Na uitgebreide tests kwamen we tot de conclusie dat het implementeren van QUIC in onze applicatie zou resulteren in lagere staartlatenties vergeleken met TCP. We hebben een vermindering van het bereik van 10-30% waargenomen voor HTTPS-verkeer in de chauffeurs- en passagiersapplicaties. QUIC gaf ons ook end-to-end controle over gebruikerspakketten.
In dit artikel delen we onze ervaring met het optimaliseren van TCP voor Uber-applicaties met behulp van een stack die QUIC ondersteunt.
De nieuwste technologie: TCP
Tegenwoordig is TCP het meest gebruikte transportprotocol voor het leveren van HTTPS-verkeer op internet. TCP zorgt voor een betrouwbare bytestroom en kan daarmee netwerkcongestie en verlies van verbindingslagen opvangen. Het wijdverbreide gebruik van TCP voor HTTPS-verkeer is te danken aan de alomtegenwoordigheid van TCP (bijna elk besturingssysteem bevat TCP), de beschikbaarheid op de meeste infrastructuur (zoals load balancers, HTTPS-proxy's en CDN's) en kant-en-klare functionaliteit die beschikbaar is. op bijna de meeste platforms en netwerken.
De meeste gebruikers gebruiken onze app onderweg, en de TCP-staartlatenties kwamen niet in de buurt van de eisen van ons realtime HTTPS-verkeer. Simpel gezegd hebben gebruikers over de hele wereld dit ervaren. Figuur 1 toont vertragingen in grote steden:
Figuur 1: De staartlatentie varieert in de belangrijkste steden van Uber.
Hoewel de latentie in Indiase en Braziliaanse netwerken hoger was dan in de VS en het VK, is de staartlatentie aanzienlijk hoger dan de gemiddelde latentie. En dit geldt zelfs voor de VS en Groot-Brittannië.
TCP-over-the-air-prestaties
TCP is gemaakt voor bedrade netwerken, dat wil zeggen met de nadruk op zeer voorspelbare verbindingen. Echter, draadloze netwerken hebben hun eigen kenmerken en moeilijkheden. Ten eerste zijn draadloze netwerken gevoelig voor verliezen als gevolg van interferentie en signaalverzwakking. Wi-Fi-netwerken zijn bijvoorbeeld gevoelig voor microgolven, bluetooth en andere radiogolven. Mobiele netwerken hebben last van signaalverlies () door reflectie/absorptie van het signaal door objecten en gebouwen, maar ook door uit buurland . Dit leidt tot significanter (4-10 keer) en diverser en pakketverlies in vergelijking met een bekabelde verbinding.
Om bandbreedteschommelingen en -verliezen tegen te gaan, gebruiken mobiele netwerken doorgaans grote buffers voor verkeersuitbarstingen. Dit kan leiden tot overmatige wachtrijen, wat langere vertragingen betekent. Heel vaak beschouwt TCP deze wachtrijen als verspilling vanwege een langere time-out, dus TCP heeft de neiging om door te geven en daardoor de buffer te vullen. Dit probleem staat bekend als (), en dit is erg moderne internet.
Ten slotte variëren de prestaties van mobiele netwerken per provider, regio en tijd. In Figuur 2 hebben we de gemiddelde vertragingen van HTTPS-verkeer tussen cellen binnen een bereik van 2 kilometer verzameld. Gegevens verzameld voor twee grote mobiele operators in Delhi, India. Zoals u kunt zien, variëren de prestaties van cel tot cel. Ook verschilt de productiviteit van de ene operator van de productiviteit van de tweede. Dit wordt beïnvloed door factoren zoals netwerktoegangspatronen waarbij rekening wordt gehouden met tijd en locatie, gebruikersmobiliteit, evenals netwerkinfrastructuur waarbij rekening wordt gehouden met torendichtheid en de verhouding tussen netwerktypen (LTE, 3G, enz.).
Figuur 2. Vertragingen met een straal van 2 km als voorbeeld. Delhi, India.
Bovendien variëren de prestaties van mobiele netwerken in de loop van de tijd. Figuur 3 toont de mediane latentie per dag van de week. Ook op kleinere schaal zagen we verschillen, binnen één dag en uur.
Figuur 3. Vertragingen in de staart kunnen aanzienlijk variëren tussen dagen, maar voor dezelfde operator.
Al het bovenstaande zorgt ervoor dat de TCP-prestaties in draadloze netwerken niet effectief zijn. Voordat we echter naar alternatieven voor TCP gingen zoeken, wilden we een nauwkeurig begrip ontwikkelen van de volgende punten:
- is TCP de belangrijkste boosdoener achter staartlatenties in onze applicaties?
- Hebben moderne netwerken aanzienlijke en gevarieerde retourvertragingen (RTT)?
- Wat is de impact van RTT en verlies op de TCP-prestaties?
TCP-prestatieanalyse
Om te begrijpen hoe we de TCP-prestaties hebben geanalyseerd, gaan we even kijken hoe TCP gegevens overdraagt van een zender naar een ontvanger. Eerst brengt de afzender een TCP-verbinding tot stand, waarbij een driewegverbinding wordt uitgevoerd : De afzender verzendt een SYN-pakket, wacht op een SYN-ACK-pakket van de ontvanger en verzendt vervolgens een ACK-pakket. Er wordt nog een tweede en derde keer besteed aan het tot stand brengen van de TCP-verbinding. De ontvanger bevestigt de ontvangst van elk pakket (ACK) om een betrouwbare bezorging te garanderen.
Als een pakket of ACK verloren gaat, verzendt de afzender het opnieuw na een time-out (RTO, ). RTO wordt dynamisch berekend op basis van verschillende factoren, zoals de verwachte RTT-vertraging tussen de afzender en de ontvanger.
Figuur 4. Pakketuitwisseling via TCP/TLS omvat een mechanisme voor hertransmissie.
Om te bepalen hoe TCP in onze applicaties presteerde, hebben we TCP-pakketten gemonitord met behulp van een week lang op gevechtsverkeer afkomstig van Indiase edge-servers. Vervolgens hebben we de TCP-verbindingen geanalyseerd met behulp van . Daarnaast hebben we een Android-applicatie gemaakt die geëmuleerd verkeer naar een testserver stuurt, waarbij echt verkeer zoveel mogelijk wordt nagebootst. Smartphones met deze applicatie werden uitgedeeld aan verschillende medewerkers, die gedurende meerdere dagen logs verzamelden.
De resultaten van beide experimenten waren consistent met elkaar. We zagen hoge RTT-latenties; staartwaarden waren bijna 6 keer hoger dan de mediaanwaarde; het rekenkundig gemiddelde van de vertragingen bedraagt meer dan 1 seconde. Veel verbindingen gingen verloren, waardoor TCP 3,5% van alle pakketten opnieuw verzond. In drukke gebieden zoals luchthavens en treinstations zagen we verliezen van 7%. Deze resultaten doen twijfel rijzen over de conventionele wijsheid die wordt gebruikt in mobiele netwerken de verliezen op transportniveau aanzienlijk verminderen. Hieronder staan de testresultaten van de “simulator”-applicatie:
Netwerkstatistieken
betekenis
RTT, milliseconden [50%,75%, 95%,99%]
[350, 425, 725, 2300]
RTT-divergentie, seconden
Gemiddeld ~1,2 s
Pakketverlies bij onstabiele verbindingen
Gemiddeld ~3.5% (7% in overbelaste gebieden)
Bijna de helft van deze verbindingen had ten minste één pakketverlies, de meeste daarvan waren SYN- en SYN-ACK-pakketten. De meeste TCP-implementaties gebruiken een RTO-waarde van 1 seconde voor SYN-pakketten, die exponentieel toeneemt bij daaropvolgende verliezen. Het laden van applicaties kan langer duren omdat TCP langer nodig heeft om verbindingen tot stand te brengen.
In het geval van datapakketten verminderen hoge RTO-waarden het nuttige gebruik van het netwerk in aanwezigheid van voorbijgaande verliezen in draadloze netwerken aanzienlijk. We ontdekten dat de gemiddelde hertransmissietijd ongeveer 1 seconde bedraagt, met een staartvertraging van bijna 30 seconden. Deze hoge latenties op TCP-niveau veroorzaakten HTTPS-time-outs en nieuwe verzoeken, waardoor de netwerklatentie en inefficiëntie verder toenamen.
Terwijl het 75e percentiel van de gemeten RTT ongeveer 425 ms bedroeg, was het 75e percentiel voor TCP bijna 3 seconden. Dit duidt erop dat het verlies ervoor zorgde dat TCP zeven tot tien keer nodig had om gegevens succesvol te verzenden. Dit kan een gevolg zijn van inefficiënte RTO-berekeningen, het onvermogen van TCP om snel te reageren op verliezen in het venster en de inefficiëntie van het algoritme voor congestiecontrole, dat geen onderscheid maakt tussen draadloze verliezen en verliezen als gevolg van netwerkcongestie. Hieronder staan de resultaten van TCP-verliestests:
Statistieken over TCP-pakketverlies
Waarde
Percentage verbindingen met minimaal 1 pakketverlies
45%
Percentage verbindingen met verliezen tijdens het tot stand brengen van de verbinding
30%
Percentage verbindingen met verliezen tijdens gegevensuitwisseling
76%
Verdeling van vertragingen bij doorgifte, seconden [50%, 75%, 95%,99%] [1, 2.8, 15, 28]
Verdeling van het aantal hertransmissies voor één pakket of TCP-segment
[1,3,6,7]
Toepassing van QUIC
QUIC, oorspronkelijk ontwikkeld door Google, is een multi-threaded modern transportprotocol dat bovenop UDP draait. Momenteel is QUIC binnen (we schreven al dat er als het ware twee versies van QUIC zijn, nieuwsgierig – ca. vertaler). Zoals weergegeven in Figuur 5, wordt QUIC onder HTTP/3 geplaatst (in feite is HTTP/2 bovenop QUIC HTTP/3, dat nu intensief wordt gestandaardiseerd). Het vervangt gedeeltelijk de HTTPS- en TCP-lagen door UDP te gebruiken om pakketten te vormen. QUIC ondersteunt alleen veilige gegevensoverdracht omdat TLS volledig in QUIC is ingebouwd.
Figuur 5: QUIC draait onder HTTP/3 en vervangt TLS, dat voorheen onder HTTP/2 draaide.
Hieronder staan de redenen die ons hebben overtuigd om QUIC te gebruiken voor TCP-versterking:
- 0-RTT-verbinding tot stand gebracht. QUIC maakt het hergebruik van autorisaties van eerdere verbindingen mogelijk, waardoor het aantal beveiligingshandshakes wordt verminderd. In de toekomst ondersteunt 0-RTT, maar een drieweg-TCP-handshake is nog steeds vereist.
- het overwinnen van HoL-blokkering. HTTP/2 gebruikt één TCP-verbinding per client om de prestaties te verbeteren, maar dit kan leiden tot HoL-blokkering (head-of-line). QUIC vereenvoudigt multiplexing en levert verzoeken onafhankelijk aan de applicatie af.
- congestiecontrole. QUIC bevindt zich op de applicatielaag, waardoor het gemakkelijker wordt om het hoofdtransportalgoritme bij te werken dat het verzenden regelt op basis van netwerkparameters (aantal verliezen of RTT). De meeste TCP-implementaties gebruiken het algoritme , wat niet optimaal is voor latentiegevoelig verkeer. Recent ontwikkelde algoritmen zoals , modelleer het netwerk nauwkeuriger en optimaliseer de latentie. Met QUIC kunt u BBR gebruiken en dit algoritme bijwerken zodra het wordt gebruikt. .
- aanvulling van verliezen. QUIC roept twee TLP's aan () voordat de RTO wordt geactiveerd, zelfs als de verliezen zeer merkbaar zijn. Dit verschilt van TCP-implementaties. TLP verzendt hoofdzakelijk het laatste pakket opnieuw (of het nieuwe pakket, als dat er is) om een snelle aanvulling te bewerkstelligen. Het omgaan met staartvertragingen is vooral nuttig voor de manier waarop Uber zijn netwerk exploiteert, namelijk voor korte, sporadische en latentiegevoelige gegevensoverdrachten.
- geoptimaliseerde ACK. Omdat elk pakket een uniek volgnummer heeft, is er geen probleem pakketten wanneer ze opnieuw worden verzonden. ACK-pakketten bevatten ook tijd om het pakket te verwerken en een ACK aan de clientzijde te genereren. Deze functies zorgen ervoor dat QUIC RTT nauwkeuriger berekent. ACK in QUIC ondersteunt maximaal 256 banden , waardoor de afzender beter bestand is tegen het shuffelen van pakketten en daarbij minder bytes gebruikt. Selectieve ACK () in TCP lost dit probleem niet in alle gevallen op.
- verbinding migratie. QUIC-verbindingen worden geïdentificeerd door een 64-bits ID, dus als een client van IP-adres verandert, kan het oude verbindings-ID zonder onderbreking op het nieuwe IP-adres worden gebruikt. Dit is een veel voorkomende praktijk voor mobiele toepassingen waarbij de gebruiker schakelt tussen Wi-Fi en mobiele verbindingen.
Alternatieven voor QUIC
We hebben alternatieve benaderingen overwogen om het probleem op te lossen voordat we voor QUIC kozen.
Het eerste dat we probeerden was het inzetten van TPC PoPs (Points of Presence) om TCP-verbindingen dichter bij de gebruikers te beëindigen. In wezen beëindigen PoP's een TCP-verbinding met een mobiel apparaat dat zich dichter bij het mobiele netwerk bevindt en sturen het verkeer terug naar de oorspronkelijke infrastructuur. Door TCP dichterbij te beëindigen, kunnen we mogelijk de RTT verminderen en ervoor zorgen dat TCP beter reageert op een dynamische draadloze omgeving. Onze experimenten hebben echter aangetoond dat het grootste deel van de RTT en het verlies afkomstig is van mobiele netwerken en dat het gebruik van PoP's geen significante prestatieverbetering oplevert.
We hebben ook gekeken naar het afstemmen van TCP-parameters. Het opzetten van een TCP-stack op onze heterogene edge-servers was moeilijk omdat TCP ongelijksoortige implementaties heeft in verschillende besturingssysteemversies. Het was lastig om dit te implementeren en verschillende netwerkconfiguraties te testen. TCP rechtstreeks op mobiele apparaten configureren was niet mogelijk vanwege een gebrek aan machtigingen. Belangrijker nog is dat functies zoals 0-RTT-verbindingen en verbeterde RTT-voorspelling van cruciaal belang zijn voor de architectuur van het protocol, en daarom is het onmogelijk om aanzienlijke voordelen te behalen door alleen TCP af te stemmen.
Ten slotte hebben we verschillende op UDP gebaseerde protocollen geëvalueerd die problemen met videostreaming oplossen. We wilden zien of deze protocollen in ons geval zouden helpen. Helaas ontbraken ze ernstig in veel beveiligingsinstellingen en vereisten ze ook een extra TCP-verbinding voor metagegevens en besturingsinformatie.
Uit ons onderzoek is gebleken dat QUIC misschien wel het enige protocol is dat kan helpen bij het probleem van internetverkeer, waarbij rekening wordt gehouden met zowel de veiligheid als de prestaties.
Integratie van QUIC in het platform
Om QUIC succesvol te integreren en de applicatieprestaties in omgevingen met slechte connectiviteit te verbeteren, hebben we de oude stack (HTTP/2 via TLS/TCP) vervangen door het QUIC-protocol. We gebruikten de netwerkbibliotheek van , dat de originele Google-versie van het protocol bevat: gQUIC. Deze implementatie wordt ook voortdurend verbeterd om de nieuwste IETF-specificatie te volgen.
We hebben Cronet eerst in onze Android-apps geïntegreerd om ondersteuning voor QUIC toe te voegen. De integratie is zo uitgevoerd dat de migratiekosten zoveel mogelijk beperkt werden. In plaats van de oude netwerkstack die de bibliotheek gebruikte volledig te vervangen , hebben we Cronet ONDER het OkHttp API-framework geïntegreerd. Door de integratie op deze manier uit te voeren, vermeden we wijzigingen in onze netwerkoproepen (die worden gebruikt door ) op API-niveau.
Vergelijkbaar met de aanpak voor Android-apparaten hebben we Cronet geïmplementeerd in Uber-apps op iOS, waarbij we HTTP-verkeer van het netwerk onderscheppen gebruik makend van . Deze abstractie, geleverd door de iOS Foundation, verwerkt protocolspecifieke URL-gegevens en zorgt ervoor dat we Cronet in onze iOS-applicaties kunnen integreren zonder noemenswaardige migratiekosten.
QUIC voltooien op Google Cloud Balancers
Aan de backendkant wordt QUIC-voltooiing verzorgd door de Google Cloud Load-balancing-infrastructuur, die gebruikmaakt van headers in reacties ter ondersteuning van QUIC. Over het algemeen voegt de balancer een alt-svc-header toe aan elk HTTP-verzoek, en dit valideert al de QUIC-ondersteuning voor het domein. Wanneer een Cronet-client een HTTP-antwoord met deze header ontvangt, gebruikt deze QUIC voor daaropvolgende HTTP-verzoeken aan dat domein. Zodra de balancer de QUIC voltooit, verzendt onze infrastructuur deze actie expliciet via HTTP2/TCP naar onze datacenters.
Prestaties: resultaten
Outputprestaties zijn de belangrijkste reden voor onze zoektocht naar een beter protocol. Om te beginnen hebben we een stand gemaakt om erachter te komen hoe QUIC zich zal gedragen onder verschillende netwerkprofielen. Om de prestaties van QUIC op echte netwerken te testen, hebben we experimenten uitgevoerd terwijl we door New Delhi reden met behulp van geëmuleerd netwerkverkeer dat sterk leek op HTTP-oproepen in de passagiersapp.
Experiment 1
Apparatuur voor het experiment:
- test Android-apparaten met OkHttp- en Cronet-stacks om er zeker van te zijn dat we HTTPS-verkeer via respectievelijk TCP en QUIC toestaan;
- een op Java gebaseerde emulatieserver die hetzelfde type HTTPS-headers in antwoorden verzendt en clientapparaten laadt om verzoeken van hen te ontvangen;
- cloudproxy's die zich fysiek in de buurt van India bevinden om TCP- en QUIC-verbindingen te beëindigen. Terwijl we voor TCP-beëindiging een reverse proxy gebruikten , was het moeilijk om een open source reverse proxy voor QUIC te vinden. We hebben zelf een reverse proxy voor QUIC gebouwd met behulp van de basis QUIC-stack van Chromium en omzetten in chroom als open source.
Figuur 6. Het TCP versus QUIC-roadtestpakket bestond uit Android-apparaten met OkHttp en Cronet, cloudproxy's voor het beëindigen van verbindingen en een emulatieserver.
Experiment 2
Toen Google QUIC beschikbaar maakte met , gebruikten we dezelfde inventaris, maar met één wijziging: in plaats van NGINX gebruikten we load balancers van Google om TCP- en QUIC-verbindingen vanaf apparaten te beëindigen, en om HTTPS-verkeer naar de emulatieserver te routeren. Balancers zijn over de hele wereld verspreid, maar gebruiken de PoP-server die zich het dichtst bij het apparaat bevindt (dankzij geolocatie).
Figuur 7. In het tweede experiment wilden we de voltooiingslatentie van TCP en QUIC vergelijken: met behulp van Google Cloud en met behulp van onze cloudproxy.
Als gevolg hiervan wachtten ons verschillende onthullingen:
- beëindiging via PoP verbeterde TCP-prestaties. Omdat balancers TCP-verbindingen dichter bij gebruikers beëindigen en sterk geoptimaliseerd zijn, resulteert dit in lagere RTT's, wat de TCP-prestaties verbetert. En hoewel QUIC minder werd getroffen, presteerde het nog steeds beter dan TCP wat betreft het verminderen van de staartlatentie (met 10-30 procent).
- staarten worden aangetast . Hoewel onze QUIC-proxy verder van de apparaten verwijderd was (ongeveer 50 ms hogere latentie) dan de load balancers van Google, leverde deze vergelijkbare prestaties: een reductie van 15% in latentie versus een reductie van 20% in het 99e percentiel voor TCP. Dit suggereert dat de last mile-overgang een knelpunt in het netwerk is.
Figuur 8: Resultaten van twee experimenten laten zien dat QUIC aanzienlijk beter presteert dan TCP.
Bestrijd het verkeer
Geïnspireerd door experimenten hebben we QUIC-ondersteuning geïmplementeerd in onze Android- en iOS-applicaties. We hebben A/B-testen uitgevoerd om de impact van QUIC te bepalen in de steden waar Uber actief is. Over het algemeen zagen we een aanzienlijke vermindering van de staartvertragingen in beide regio's, telecomoperatoren en netwerktypes.
De onderstaande grafieken tonen de procentuele verbeteringen in staarten (95 en 99 percentielen) per macroregio en verschillende netwerktypen: LTE, 3G, 2G.
Figuur 9. In gevechtstests presteerde QUIC beter dan TCP wat betreft latentie.
Alleen voorwaards
Misschien is dit nog maar het begin: de release van QUIC in productie heeft geweldige mogelijkheden geboden om de applicatieprestaties in zowel stabiele als onstabiele netwerken te verbeteren, namelijk:
Verhoogde dekking
Nadat we de prestaties van het protocol op echt verkeer hadden geanalyseerd, zagen we dat ongeveer 80% van de sessies met succes QUIC gebruikte Alle verzoeken, terwijl 15% van de sessies een combinatie van QUIC en TCP gebruikte. We nemen aan dat de combinatie te wijten is aan een time-out van de Cronet-bibliotheek naar TCP, omdat deze geen onderscheid kan maken tussen echte UDP-fouten en slechte netwerkomstandigheden. We onderzoeken momenteel een oplossing voor dit probleem terwijl we werken aan de daaropvolgende implementatie van QUIC.
QUIC-optimalisatie
Verkeer van mobiele apps is latentiegevoelig, maar niet bandbreedtegevoelig. Bovendien worden onze applicaties voornamelijk gebruikt op mobiele netwerken. Op basis van experimenten zijn de staartlatenties nog steeds hoog, ook al wordt een proxy gebruikt om TCP en QUIC dicht bij gebruikers te beëindigen. We zijn actief op zoek naar manieren om het congestiebeheer te verbeteren en de efficiëntie van QUIC-algoritmen voor verliesherstel te verbeteren.
Met deze en verschillende andere verbeteringen zijn we van plan de gebruikerservaring te verbeteren, ongeacht het netwerk en de regio, waardoor handig en naadloos pakketvervoer over de hele wereld toegankelijker wordt.
Bron: www.habr.com