QUIC
transportní síťový protokol From Wikipedia, the free encyclopedia
Remove ads
QUIC (vyslovuje se kwɪk) je univerzální protokol transportní vrstvy, jehož první verzi vytvořil Jim Roskind ze společnosti Google.[1][2][3] První implementace byla nasazen v roce 2012,[4] v roce 2013 byl veřejně ohlášen jako experimentální rozšíření a prezentován na schůzi IETF.[5][6][7][8] V roce 2016 jej používala více než polovina spojení mezi prohlížeči Chrome a servery společnosti Google.[9] V roce 2020 jej podporovaly všechny nejpoužívanější WWW prohlížeče – Google Chrome,[9] Microsoft Edge,[10][11] Mozilla Firefox[12] a Safari.[13]
Vytvořením několika multiplexovaných spojení mezi oběma koncovými body pomocí User Datagram Protocol (UDP) QUIC zlepšuje výkonnost spojovaných webových aplikací, které dříve používaly Transmission Control Protocol (TCP),[2][9] takže pro mnoho aplikací odbourává použitíl protokolu TCP v transportní vrstvě. Jméno QUIC bylo vysvětlováno jako zkratka anglického Quick UDP Internet Connections (rychlá internetová UDP spojení), ale podle IETF QUIC je prostě jméno protokolu, nikoli zkratka.[3][8][1]
QUIC poskytuje multiplexované spojení protokolu HTTP/3, které umožňuje souběžný přenos několika proudů dat, a je tedy imunní vůči ztrátě paketů v jiných proudech. Protokol HTTP/2, který multiplexuje několik proudů přes jedno TCP spojení může trpět blokováním čela fronty, k němuž dochází, když se některé z TCP paketů v rámci spojení opozdí nebo ztratí.
Druhým cílem protokolu QUIC je snížit latenci spojení a přenosu, a zabraňovat zahlcení sítě díky odhadu šířky pásma v obou směrech. Algoritmy omezující zahlcení sítě nejsou realizovány v operačním systému jako v protokolu TCP, ale v uživatelském prostoru v obou koncových bodech, což umožňuje tyto algoritmy pružněji vylepšovat.[14] Protokol lze navíc rozšířit o používání dopředné opravy chyb (FEC) pro další zlepšení výkonnosti na linkách s větším výskytem chyb. Protokol QUIC je navržen tak, aby byl odolný proti osifikaci protokolu.
V červnu 2015 byl IETF podán internetový draft specifikace QUIC ke standardizaci.[15][16] V roce 2016 byla založena pracovní skupina QUIC.[17] V říjnu 2018 pracovní skupiny IETF pro HTTP a QUIC ještě před zveřejněním jako celosvětového standardu rozhodly přenos HTTP přes QUIC nazvat HTTP/3.[18] V květnu 2021 IETF vydal QUIC jako internetový standard RFC 9000, s doprovodnými dokumenty RFC 8999, RFC 9001 a RFC 9002.[19] Další aplikací je DNS-over-QUIC.
Remove ads
Pozadí
Podrobnější informace naleznete v článku Transmission Control Protocol.
Transmission Control Protocol (TCP) poskytuje komunikaci mezi dvěma koncovými body v podobě jednoho proudu dat z jednoho koncového bodu do druhého a druhého proudu opačným směrem. Odesílaná data jsou předávána TCP systému, který zajišťuje jejich přenos na opačný konec v nezměněném tvaru; chyby při přenosu TCP opravuje opakovaným přenosem; pokud přenos dat není možný, TCP bude signalizovat chybu.[20]
K tomuto účelu TCP rozkládá proud dat na segmenty, ke kterým přidává malé množství hlaviček, čímž se vytváří paket. Hlavičky obsahují pořadové číslo, které slouží k odhalení ztracených paketů a paketů doručených ve špatném pořadí, a kontrolní součet, který umožňuje detekovat chyby v datech paketu. Pokud se objeví problém, TCP použije zpětnou vazbu s automatickým opakováním pro vyžádání, aby odesilatel znovu poslal ztracený nebo poškozený paket.[20]
Ve většině implementací způsobí komunikační problémy (ztráta nebo poškození paketu) pozastavení komunikace, dokud není problém odstraněn opakovaným přenosem dat nebo spojení není uznáno za nepoužitelné. Při použití jediného spojení pro přenos několika proudů dat, jako je tomu u protokolu HTTP/2, dojde k pozastavení všech proudů, přestože problém může být pouze v jednom z nich. Pokud například dojde k chybě při načítání GIF obrázku, který je použit jako favicon, načítání zbytku stránky bude pozdrženo, dokud nebude problém vyřešen.[20] Tento jev se nazývá blokování čela fronty.
Protože TCP protokol je navržen tak, aby komunikace vypadala jako „datová roura“ nebo proud, úmyslně nevyužívá informace o datech, která přenáší. Případné další požadavky, např. na šifrování pomocí TLS, je třeba je řešit systémy běžícími nad TCP, které používají TCP ke komunikaci s obdobným softwarem na opačném konci spojení. Každý z těchto druhů vytvoření spojení vyžaduje samostatný handshake proces. Díky tomu může navázání spojení vyžadovat několik obrátek požadavek-odezva. Neodstranitelná latence dálkových spojů může způsobovat významné zpoždění hned na začátku přenosu.[20]
Přenos dat protokolem TCP je negativně ovlivňován osifikací protokolu,[21] protože data jsou přenášena nezašifrovaná a proto je jejich obsah viditelný na všech zařízeních, přes která pakety procházejí (tzv. middleboxy), a mohou být těmito zařízeními změněna.[22] V jednom experimentu bylo zjištěno, že třetina tras přes Internet obsahuje nejméně jeden prvek, který mění TCP metadata, a na 6.5 % tras dochází k nebezpečným jevům způsobeným zastaralými prvky.[23] Takto byla ovlivněna rozšíření TCP: návrh Multipath TCP (MPTCP) byl omezován chováním middleboxů,[24][25] stejně jako nasazení TCP Fast Open.[26][21]
Remove ads
Vlastnosti
Z perspektivy podpory šifrovaného HTTP provozu má QUIC podobnou roli jako TCP, ale s menší latencí při vytváření spojení a efektivnějším zotavením při komunikačních problémech, když je několik HTTP proudů multiplexováno v jediném spojení. Toho se dosahuje dvěma změnami, které vycházejí ze znalostí HTTP komunikace.[20]
Hlavní změnou je významné snížení režie při vytváření spojení. Protože většina HTTP spojení používá TLS, QUIC provádí úvodní výměnu klíčů a seznamu podporovaných protokolů v rámci úvodního handshaku. Když klient otevře spojení, paket odezvy obsahuje data potřebná pro šifrování dalších paketů. To je významné zrychlení proti postupu, kdy se nejdříve vytvoří našifrovaná roura a až poté se vyjednává protokol datové bezpečnosti. Zkombinováním několika kroků do jediné dvojice požadavek–odezva lze obsloužit i jiné protokoly. Tato data lze pak použít jak pro následující požadavky v rámci daného spojení, tak pro jiná spojení.[20]
Druhou změnou je použití protokolu UDP, který na rozdíl od protokolu TCP nezajišťuje zotavení při ztrátě paketů. Toto zotavení zajišťuje protokol QUIC spolu s řízením toku dat samostatně pro každý proud dat včetně opakovaného přenosu ztracených paketů. To znamená, že pokud dojde k chybě v jednom proudu, jako ve výše uvedeném příkladu s favicon, přenos v dalších proudech není nijak narušen. To může značně zrychlovat komunikaci na spojích náchylných k chybám, protože velká část dodatečných dat může být přijata než TCP zjistí, že chybí paket je nebo rozbitý, a všechna tato data jsou blokována, dokud není chyba opravena, případně mohou být dokonce zahozena. Při použití protolu QUIC mohou být data z jiných proudů zpracována, zatímco se provádí oprava postiženého proudu.[27]
QUIC obsahuje řadu dalších změn pro snížení celkové latence a zvýšení propustnosti. Každý paket je například šifrován samostatně, takže nedochází k tomu, že by se pro dešifrování čekalo na další pakety. To by při použití TCP bylo komplikované, protože TCP poskytuje nečleněný proud dat, v němž se původní hranice jednotlivých segmentů mohou měnit. Některé vlastnosti by bylo možné realizovat ve vyšších vrstvách, ale QUIC se snaží vše potřebné provést v jediném procesu handshake.[8]
Dalším cílem protokolu QUIC bylo zlepšit výkonnost při změnách v síti, například když mobilní zařízení ukončí komunikaci s lokálním hotspotem a začne používat mobilní síť. Když k něčemu takovému dojde při použití TCP, začne zdlouhavý proces, při němž se jednotlivá spojení po vypršení prodlevy přeruší a na žádost jsou znovu navázána. Pro překlenutí tohoto problému QUIC používá 64bitový identifikátor spojení (ID)[8], který jednoznačně identifikuje spojení se serverem bez ohledu na adresu. To umožňuje, aby bylo spojení znovu navázáno jednoduše odesláním paketu, který vždy obsahuje toto ID, protože původní ID spojení bude stále platný, i když se změní IP adresa klienta.[28]
QUIC je možné implementovat v uživatelském prostoru aplikace, nikoli v jádru operačního systému. To obecně způsobuje další režii kvůli přepínání kontextu, když se data přesouvají mezi jádrem a aplikacemi. Protokolový zásobník pro QUIC je však určený které mají být použity jedinou aplikací, s každý aplikace pomocí/použití QUIC mající vlastní spojení hosted na UDP. Jednoznačně rozdíl by mohl být velmi malý, protože větší část zásobníku HTTP/2 již je v aplikaci (nebo spíše v jejích knihovnách). Přidání zbývajících složek do této knihovny, v zásadě oprava chyb, má malý vliv na velikost HTTP/2 zásobníku a na celkovou složitost.[8]
Tato organizace usnadňuje budoucí úpravy, protože při změnách není třeba měnit jádra operačního systému. Jedním z dlouhodobějších cílů protokolu QUIC je přidat nové systémy pro dopřednou opravu chyb (FEC) a vylepšenou ochranu proti zahlcení.[28]
Jednou z námitek proti přechodu z TCP na UDP je, že v Internetu je TCP dominantním transportním protokolem, takže mnoho routerů a jiných „middleboxes“ v internetové infrastruktuře je zaměřeno na optimální propustnost TCP, a mohou omezovat rychlost UDP provozu nebo jej dokonce blokovat. Google provedl řadu experimentů, a zjistil, že tímto způsobem je blokována pouze malá část spojení.[3] Toto vedlo k použití systému pro velmi rychlý návrat k TCP; síťový zásobník prohlížeče Chromium začíná současně jak QUIC tak obvyklé TCP spojení, což mu umožňuje přepnout na TCP se zanedbatelnou latencí.[29]
Protokol QUIC byl navržen tak, aby jeho nasazení a vývoj bylo jednoduché a aby odolával osifikaci;[30] jde o první transportní protokol od IETF, který z těchto důvodů úmyslně minimalizuje svůj wire image.[31] Kromě šifrovaných hlaviček, vyhovuje [32][33] a má explicitně specifikované invarianty protokolu.[34]
Vrstva datové bezpečnosti protokolu QUIC vychází z TLS 1.2 a TLS 1.3.[35] Starší nebezpečná verze protokolu TLS 1.0 není v QUIC zásobníku povolena.
Google QUIC (gQUIC)
Protokol, který vytvořila společnost Google a který převzalo IETF pod jménem QUIC (v roce 2012 okolo QUIC verze 20), se výrazně lišil od nové verze QUIC vyvíjené IETF. Původní QUIC společnosti Google (gQUIC) byl nasazen jako podporova HTTP(S) v prohlížeči Chromium a měl se stát protokolem pro WWW. IETF však vyvíjí QUIC (iQUIC) jako univerzální transportní protokol. Vývojáři prohlížeče Chromium sledují vývoj standardizačního úsilí IETF, aby prohlížeč používal a plně odpovídal posledním internetovým standardům protokolu QUIC.
Remove ads
Aplikace
QUIC byl původně vyvíjen jako transportní protokol pro HTTP, a HTTP/3 byla jeho první aplikace.[36][37] DNS-over-QUIC je aplikace protokolu QUIC pro systém internetových doménových jmen, který poskytuje datovou bezpečnost pro data přenášená mezi resolvery podobně jako DNS-over-TLS.[38] IETF vyvíjí aplikační protokoly QUIC pro bezpečné síťové tunelování[37] a streaming.[39] Extensible Messaging and Presence Protocol byl experimentálně upraven pro použití protokolu QUIC.[40] Další aplikací je SMB přes QUIC, která bude podle Microsoftu transparentně poskytovat „SMB VPN“.[41] SMB klienti používají implicitně TCP a budou zkoušet QUIC, pokud TCP selže nebo pokud bude přímo vyžádáno.
Přijetí
Podpora prohlížečů
Kód protokolu QUIC byl experimentálně vyvinut v Google Chrome počínaje rokem 2012,[4] a byl ohlásil jako část prohlížeče Chromium verze 29 (vydané 20. srpna 2013).[18] V prohlížečích Chromium a Chrome je aktuálně implicitně povolen.[42]
Podpora v Mozilla Firefox se objevila v květnu 2021.[43][12]
Apple přidal experimentální podporu v dubnu 2020 ve WebKit engine prostřednictvím Safari Technology Preview 104.[44] Oficiální podpora byla přidána v Safari 14, které je v macOS Big Sur a v iOS 14,[45] ale její použití je třeba ručně zapnout.[46] Později byl v Safari 16 implicitně povolen.[13]
Podpora klientů
Knihovna Cronet pro QUIC a jiné protokoly pro aplikace v systému Android je k dispozici v podobě modulu dostupného na Google Play.[47]
CURL 7.66 vydaný 11. září 2019 podporuje HTTP/3 (a tedy QUIC).[48][49]
V říjnu 2020 Facebook ohlásil[50] že úspěšně migroval své aplikace, včetně Instagramu, a serverovou infrastrukturu na QUIC, přičemž 75 % internetového provozu používá QUIC. Všechny mobilní aplikace společnosti Google podporují QUIC, včetně YouTube a Gmailu.[51][52] Mobilní aplikace společnosti Uber používá i QUIC.[52]
Podpora serverů
V roce 2017 existovalo několik aktivně udržovaných implementací. Google servery podporují QUIC a Google publikoval prototyp serveru.[53] Akamai Technologie bylo podporující QUIC od července 2016.[54][55] Je dostupná implementace pro jazyk Go nazývaná quic-go,[56] která zajišťuje experimentální podporu QUIC v Caddy server.[57] 11. července 2017 začala společnost LiteSpeed Technologie oficiálně podporovat QUIC ve svém vyvažovači zátěže (WebADC)[58] a v LiteSpeed Web Server.[59] V říjnu 2019 88,6 % webových sídel podporujících QUIC používalo LiteSpeed a 10,8 % Nginx.[60] Spojení HTTP-over-QUIC zpočátku podporovaly pouze Google servery; Facebook spustil tuto technologii v roce 2018,[18] a Cloudflare nabízel podporu QUIC v beta verzi od roku 2018.[61] Vyvažovače zátěže HAProxy přidaly experimentální podporu QUIC v březnu 2022[62] a uvedly, že bude připravena pro produkční použití v březnu 2023.[63] V dubnu 2023 používalo QUIC 8,9 % všech webových sídel,[64] oproti 5 % v březnu 2021. Microsoft Windows Server 2022 podporuje jak HTTP/3[65] tak SMB přes QUIC[66][10] protokoly přes MsQuic. The Application Delivery Controller společnosti Citrix (Citrix ADC, NetScaler) může od verze 13 fungovat jako QUIC proxy.[67][68]
Navíc existuje několik již nevyvíjených komunitních projektů: libquic[69] vznikl extrakcí implementace protokolu QUIC z prohlížeče Chromium a jeho úpravami, aby se minimalizovaly závislosti, a goquic[70] poskytuje jazykové vazby knihovny libquic pro jazyk Go. A konečně, quic-reverse-proxy[71] je Dockerový obraz, který funguje jako reverzní proxy server a překládá pořadavky QUIC do obyčejného HTTP, kterému rozumí původní server.
.NET 5 přináší experimentální podporu pro QUIC v podobě knihovny MsQuic.[72]
Remove ads
Zdrojový kód
Remove ads
Odkazy
Wikiwand - on
Seamless Wikipedia browsing. On steroids.
Remove ads