QUIC vs TCP + TLS - a proč QUIC není další velká věc

Od Rui Costa

Pravděpodobně jste už slyšeli o QUIC. I když jste tak dosud neučinili, je velmi pravděpodobné, že jste ji již použili: Služby Google v Chromu používají QUIC již několik let. Proces normalizace QUIC je také velmi blízko k dokončení. QUIC je cenná iniciativa společnosti Google pro nový protokol o internetovém přenosu s konečným cílem snížit latenci. Dosahuje QUIC tohoto cíle? Je tomu tak, ale jen s přírůstkovým dopadem.

QUIC se zaměřuje na optimalizaci handshake (velmi důležité!), Ale nedokáže skutečně přehodnotit transportní protokoly ve své podstatě (transport!). Proč je toto důležité? Protože ve světě kabelových uživatelů byly definovány tradiční přepravní techniky. Tento svět je dávno pryč, s nespolehlivými a nepředvídatelnými bezdrátovými spoji dominujícími uživatelské zkušenosti. Existují i ​​jiné možnosti? Ano: smazat kódování, místo ARQ.

Jeden handshake namísto 2

Nakonec QUIC přinese (alespoň) dvakrát rychlejší navázání spojení a dramaticky snižuje dopad předávání mezi různými sítěmi. Velmi důležité vlastnosti, ale přírůstkový dopad. Trochu dále rozšířím své myšlenky na každou z těchto hlavních výhod.

Stručně řečeno, QUIC nahrazuje kombinaci TCP a TLS, přičemž k přepravě a zabezpečení zaujímá přístup napříč vrstvami. Pod QUIC je UDP používán jako „transport“. Proč UDP? Velmi praktické rozhodnutí: použití UDP umožňuje velmi rychlé nasazení v uživatelském prostoru, zatímco modifikace TCP by vyžadovala věky, než bude přijata (více o síťových protokolech zde).

Zdroj obrázku

Pro hlubší pochopení QUIC doporučuji podívat se na Chromium Projects (QUIC na 10 000 stop je vynikajícím výchozím bodem). Doporučuji také mimořádnou přednášku „QUIC: Nahrazení TCP pro web“, kterou provedla Jana Iyengar (rychle, bývalá společnost Google). Celkově jsou hlavní výhody připsané QUIC:

  • Latence navázání spojení
    Rozhodně tomu tak je! QUIC dosahuje 0-RTT pro známé servery.
  • Vylepšená kontrola přetížení
    Okrajové úpravy. Není jasné, co bude poslední možností, ale zdá se, že bude založen na protokolu TCP NewReno
  • Multiplexování bez blokování head-of-line
    QUIC snižuje problém blokování head-of-line. Ale ne úplně.
  • Oprava chyby vpřed
    Žádný praktický dopad, alespoň prozatím.
  • Migrace připojení
    Velmi cenná funkce: přechod z WiFi na LTE bez opětovného vyjednávání relace!

Nakonec QUIC přinese (alespoň) dvakrát rychlejší navázání spojení a dramaticky snižuje dopad předávání mezi různými sítěmi. Velmi důležité vlastnosti, ale přírůstkový dopad. Trochu dále rozšířím své myšlenky na každou z těchto hlavních výhod.

Latence navázání spojení

Ve standardním protokolu HTTP + TLS + TCP potřebuje protokol TCP k navázání relace mezi serverem a klientem handshake a protokol TLS vyžaduje vlastní handshake, aby se zajistilo zabezpečení relace. QUIC potřebuje pouze jeden handshake k vytvoření bezpečné relace. Tak jednoduché je, že se čas připojení zkrátí na polovinu.

Zdroj obrázku

Jak? Zjednodušuje (hodně!), Klient odešle ID připojení k serveru, který pak vrátí klientovi token a veřejné hodnoty Diffie-Hellman serveru, což umožňuje serveru a klientovi dohodnout se na počátečním klíči. Klient a server mohou okamžitě začít s výměnou dat, přičemž zároveň vytvoří klíč závěrečné relace. Chcete-li se dozvědět více o bezpečnostním podání ruky QUIC, doporučuji velmi jasnou prezentaci Roberta Lycheva (video, snímky).

Navíc, podobně jako TLS1.3, se server a klient poprvé „setkají“ s mezipaměťmi relačních klíčů a v době nového požadavku není nutné žádné handshake. Toto je tzv. Funkce 0-RTT.

Vylepšená kontrola přetížení

QUIC zavádí nový mechanismus číslování sekvencí. Každý paket má nové pořadové číslo, včetně paketů opětovného přenosu, což umožňuje přesnější výpočet času za letu (RTT). Řízení přetížení QUIC je však tradiční mechanismus podobný TCP. Zdá se, že poslední možností je NewReno, ale najdete odkazy na použití CUBIC nebo BBR. Jak víme z TCP, všechna mají svá omezení a vybrat si jeden z nich je kompromis.

Stejně jako TCP, QUIC je ve své podstatě protokol ARQ, tj. Pro zpětné získání ze ztrát paketů jsou vyžadovány zpětné vazby. A tato volba designu pak vede k neefektivnosti při hodnocení podmínek spojení. A ve vazbách, kde latence a ztráty jsou nestabilní, vedou tato omezení k významné ztrátě výkonu. Ano, mluvím o bezdrátových spojích, u nichž se očekává, že do roku 2021 podporují více než 63% celkového internetového provozu.

Existuje mnohem účinnější způsob, jak zacházet se ztrátami: mazací kódy. Více o tom později.

Multiplexování

Multiplexování je velmi důležité, protože zabraňuje blokování head-of-line (HOL). Blokování HOL je to, co se stane, když požádáte o více objektů, a malý objekt uvízne, protože předchozí velký objekt se zpozdil. Při použití více toků ztratí pakety přenášející data pro jednotlivý tok pouze tento konkrétní proud. QUIC proto významně snižuje blokování HOL, ale ne úplně.

Také umožnění vývojáři skutečně vybrat, jaké jsou nejdůležitější požadavky na základě jiných charakteristik, než je jejich velikost, by mohlo být nesmírně užitečné při zlepšování celkového uživatelského dojmu.

Oprava chyby vpřed

Kódy mazání jsem již zmínil jako chytřejší způsob, jak zvládnout ztráty paketů, a QUIC skutečně zvažuje možné použití technik dopředné korekce chyb (FEC). Experimenty s použitím FEC v QUIC však byly (ne) překvapivě demotivující. Přístupem bylo použít FEC na bázi XOR, které dokáže obnovit pouze jeden paket. To znamená, že pokud dojde ke ztrátě dvou nebo více paketů, paket FEC se stane zbytečným. Režie pak zhoršuje rychlost a nakonec byla podpora pro FEC založená na XOR odstraněna z QUIC na začátku roku 2016.

To vlastně není překvapující. Tradiční FEC je čistě proaktivní schéma obnovy ztrát, což znamená, že server odešle více paketů, než je nutné (klesající dobrá rychlost) nebo méně, než je nutné (nesnižující se zpoždění), přičemž optimálnosti se dosahuje velmi zřídka. Tradiční FEC má problém nepřizpůsobit se kolísajícím charakteristikám kanálu. Problémem jsou nespolehlivé a nepředvídatelné odkazy. Jo, bezdrátově.

Nedávný návrh IETF zmiňuje použití FEC ke zlepšení výkonu QUIC u relací v reálném čase, přičemž argumentuje, že FEC způsobuje, že obnova ztráty paketů je necitlivá na čas zpáteční cesty. To je slibný vývoj! Ještě příliš brzy na to, abychom mohli posoudit, jak se to bude chovat v divočině, ale přesto slibné.

Migrace připojení

Není toho moc co říci. QUIC přináší vlastní jedinečný identifikátor pro připojení, UUID připojení, který umožňuje předávat sítě a udržovat stejný UUID připojení. Předání tedy již není problém (s výjimkou dlouhých časů předání, ale to není něco, co může transportní protokol vyřešit).

Nevýhodou QUIC

Výkon

Google prohlašuje, že QUIC snížil latenci reakcí Vyhledávání Google o 3,6% a vyrovnávací paměť videa YouTube o 15,3% (což, i když malé, je stále zajímavé zlepšení, vzhledem k tomu, že na rychlosti skutečně záleží). Ve výše uvedené přednášce Jana Iyengara vidíme tato čísla podrobněji:

Tato čísla jsou v souladu se zjištěními uvedenými v článku 2016 „Jak rychle je QUIC?“, Kde autoři porovnávají QUIC s SPDY a HTTP. Výsledky ukazují, že QUIC funguje dobře za podmínek vysoké latence, zejména pro malou šířku pásma, což je v souladu s výsledky výkonnosti uvedenými v Indii (výše). Autoři také ukazují, že QUIC je nejlepší volbou, když mluvíme o malých objektech.

Výsledky současně ukazují, že QUIC nefunguje dobře pro velké množství dat ve velmi širokopásmových sítích. Nej překvapivější je, že autoři tvrdí, že při porovnání QUIC, SPDY a HTTP „žádný z těchto protokolů není jednoznačně lepší než ostatní dva a skutečné podmínky sítě určují, který protokol funguje nejlépe“.

UDP škrtící

QUIC funguje nad UDP, takže bude fungovat pouze tehdy, když je mezi klientem a serverem k dispozici UDP spojení. V opačném případě, pokud UDP není k dispozici, se QUIC vrací ke standardnímu HTTP, což zajišťuje, že koncový uživatel stále dostane požadovaný obsah. Co se však stane, když čelíme škrtícímu UDP, například v podnikové nebo veřejné síti? Protože UDP prochází, QUIC je schopen navázat spojení. Avšak díky škrtícímu UDP by se uchýlením k TCP zajistila mnohem vyšší rychlost!

Další příklad omezení UDP lze nalézt v pravidlech QoS v některých domácích směrovačích, což může vést k tomu, že se stránky Google v prohlížeči Chrome načítají velmi pomalu.

Řešení? Podle dokumentu společnosti Google z roku 2017 ručně deaktivujte QUIC, kontaktujte operátory a požádejte operátory, aby přestali škrtit. Nezní to moc prakticky. Mechanismus detekce škrtícího UDP by byl mnohem větším pomocníkem, protože by mohl spustit automatický výpadek TCP, čímž by zajistil, že koncový uživatel bude mít nejlepší možné zkušenosti.

Použitelnost

QUIC je stále v procesu standardizace. Samozřejmě to stále probíhá. Proto použití QUIC v této fázi stále vyžaduje poměrně značné úsilí. Při pohledu na seznam PacketZoom vyžaduje použití QUIC v mobilní aplikaci:

  • Nastavení serverů QUIC a nasazení globálně na distribuci koncového uživatele.
  • Přidejte do aplikace kód klienta QUIC
  • Protože není k dispozici žádná oficiální sada Mobile SDK, musí vývojáři budovat své vlastní, nebo se spolehnout na rámce třetích stran
  • Podpora více operačních systémů (iOS, Android, Windows)
  • Povolte záložní HTTP, protože některá aktiva nemusí mít prospěch z QUIC a potřebují HTTP
  • Některé sítě blokují QUIC, aby nedošlo k přerušení služby
  • Zjištění, jak zacházet s škrtením UDP (přidal jsem tento)

Se snahami, které vidíme od společností Google, Facebook, Cloudflare, Fastly a Uber (mezi mnoha jinými), je však standardizace na cestě a jsem si jist, že složitost používání QUIC bude velmi rychle klesat. Ve společnosti Codavel jsme odhodláni zlepšit poskytování obsahu a vzhledem k tomu, že QUIC představuje krok k tomuto cíli. Proto připravujeme několik nástrojů, které pomohou těm, kteří chtějí zkusit QUIC - zůstaňte naladěni!

QUIC: ARQ, znovu. A co mazací kódy?

Už jsem několikrát zmínil, že QUIC je ve své podstatě protokol založený na ARQ. Protokoly ARQ se v zásadě spoléhají na informace o zpětné vazbě, aby se zotavily ze ztráty paketů. Zjednodušeně odesílatel očekává, že příjemce individuálně potvrdí příjem každého paketu a nepojede dopředu, dokud toto potvrzení neobdrží. V případě, že je zjištěna ztráta, odesílatel pak znovu doručí ztracený paket, což zajistí spolehlivost. Jednoduchý příklad:

Problém s tímto přístupem je v tom, že je velmi narušen RTT odkazu, protože odesílatel musí čekat na potvrzení od příjemce. Jinými slovy, i když QUIC účinně zkracuje dobu navazování spojení, QUIC je velmi narušeno zpožděním při skutečném přenosu dat, jako u každé relace TCP!

Jak tedy překonat ztráty bez nutnosti potvrzení? S mazacími kódy! Pro ty, kteří nejsou seznámeni, sestává v podstatě smíchání původních paketů a použití lineární algebry, aby bylo zajištěno, že bez ohledu na to, co se n přijímá, je přijímač schopen obnovit všechny n původní pakety. Následující jednoduchý příklad pomůže:

Odesílatel nemusí čekat na potvrzení před odesláním nového (kódovaného) paketu, zatímco přijímač získá všechny 4 původní pakety. A neposíláme více dat ani větší pakety! Pro přehlednost P1 + P2 = 0101 + 1110 = 1011, tj. Kódovaný paket má stejnou velikost jako původní paket. (Tento příspěvek od Steinwurfa poskytuje velkolepé animace, které ilustrují výhody mazacích kódů oproti ARQ. Podívejte se!)

Vzhledem k tomu, že odesílatel se nespoléhá na potvrzení pro zajištění spolehlivého doručení všech paketů, je tento přístup ohromně robustnější vůči latenci nebo odchylce latence (jitter). Samozřejmě je také mnohem robustnější pro ztráty paketů. A kde vidíme latenci, jitter a ztrátu paketů? V bezdrátových sítích!

Rozchod s ARQ

Možná se divíte, „Proč FEC nepomohl QUIC?“. Odpověď je „jednoduchá“: protože i když QUIC předpokládá použití FEC, ve své podstatě je stále velmi závislá na poděkování. Navíc, jak jsem zmínil výše, ne všechny druhy mazacích kódů jsou vhodné pro scénáře, kde jsou ztráty nestabilní a nepředvídatelné.

Proto musíme zvolit techniku ​​kódování, která je schopna rychle se přizpůsobit kolísajícím podmínkám kanálu, a zajistit, aby nedošlo ke ztrátě přenosu paketů. Měl by být také schopen se učit s používáním a automaticky vylepšovat jeho rozhodnutí o kódování a přenosu. A to je přesně to, co jsme udělali v našem transportním protokolu, Bolino. Jeho tajná omáčka je speciální druh mazacích kódů nazývaných síťové kódy, které jsme přizpůsobili pro nestabilní spojení a požadavky na nízkou latenci. A máme něco takového:

Zdroj hlavního obrázku

Tento příspěvek byl původně zveřejněn na blog.codavel.com