Přeskočit na obsah

QUIC

Z Wikipedie, otevřené encyklopedie
ikona
Tato stránka je právě ve výstavbě nebo prochází rozsáhlou přestavbou
Jste zváni, abyste s touto činností pomohli vlastními editacemi. Vyhledejte v historii vkladatele, nebo nahlédněte do diskuse, pokud se chcete seznámit s jeho představou o budoucí koncepci stránky. Pokud stránku právě editujete, zvláště v případě, že editace trvá jen krátkou dobu, použijte raději šablonu {{Pracuje se}}, abyste zabránili editačním konfliktům.
Tato šablona je určena pro užití v řádu dní. Pokud již uplynula vyžádaná lhůta 14 dní od jejího vložení Kolarp (diskuse) 18. 5. 2025, 23:01 (CEST), neváhejte šablonu odstranit.

Šablona:Infobox networking protocol 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.

Pozadí

[editovat | editovat zdroj]
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 nebud 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 samosttaný 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]

Vlastnosti

[editovat | editovat zdroj]
Handshake protokolu QUIC v porovnání s TCP s TLS 1.2

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]

HTTP/1Transport Layer SecurityTransmission Control ProtocolHTTP/2TLS 1.2Transmission Control ProtocolHTTP/3TLS 1.3QUICUser Datagram ProtocolInternetový protokol
Srovnání protokolových zásobníků HTTP/1.1, HTTP/2 a HTTP/3

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)

[editovat | editovat zdroj]
ikona
Tato část článku není dostatečně ozdrojována, a může tedy obsahovat informace, které je třeba ověřit.
Jste-li s popisovaným předmětem seznámeni, pomozte doložit uvedená tvrzení doplněním referencí na věrohodné zdroje.

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.

Aplikace

[editovat | editovat zdroj]

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í

[editovat | editovat zdroj]

Podpora prohlížečů

[editovat | editovat zdroj]

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 klentů

[editovat | editovat zdroj]

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ů

[editovat | editovat zdroj]

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]

Zdrojový kód

[editovat | editovat zdroj]
QUIC nebo gQUIC implementace dostupný v zdroj forma
Implementace Licence Jazyk Popis
Chromium BSD-3-Věta Licence C++ Zdrojový kód prohlížeče Google Chrome a referenční implementace gQUIC. Obsahuje samostatné gQUIC a QUIC klientské a serverové programy, které lze používat pro testování. Browsable source code. Tato verze je také základem LINE's stellite a Google's cronet.
MsQuic Licence MIT C Cross platformní QUIC implementace společnosti Microsoft navržená jako univerzální QUIC knihovna. Používán v Windows a cross platforma by .NET. Jsou dostupné vrstvy pro Rust a C# interop, stejně jako užitečnost C++ wrapper třídy.
QUIC Library (mvfst) Licence MIT C++ mvfst (move fast) je klientská a serverová implementace IETF protokolu QUIC v jazyce C++ společnosti Facebook.
LiteSpeed QUIC Library (lsquic) Licence MIT C Implementace QUIC a HTTP/3, kterou používá LiteSpeed Web Server a OpenLiteSpeed.
ngtcp2 Licence MIT C QUIC knihovna nezávislá na šifrovací knihovně, která funguje s OpenSSL nebo GnuTLS. Pro HTTP/3 potřebuje zvláštní knihovnu jako nghttp3.
Quiche BSD-2-Věta Licence Rust Zásuvka-agnostic a odhalí C API pro použití v aplikacích v C/C++.
quicly Licence MIT C QUIC implementace knihovny pro H2O web server.
quic-go Licence MIT Go Knihovna poskytuje QUIC podporu pro jazyk Go.
Quinn Apache Licence 2.0Licence MIT Rust Async-přátelská implementace QUIC v jazyce v Rust
Neqo Apache Licence 2.0Licence MIT Rust Implementace z Mozilla, která by měla být zabudována do síťové knihovny Necko používané v WWW prohlížeči Firefox
aioquic BSD-3-Věta Licence Python Tato knihovna vlastnosti I/O-volná API vhodný pro vložení v klienti i servery.
picoquic Licence MIT C Minimální implementace protokolu QUIC zarovnaný s IETF specifikacím
pquic Licence MIT C Rozšiřitelná implementace QUIC to obsahuje eBPF virtuální stroj, které je schopen dynamicky zavádět rozšíření jako pluginy
quic BSD-3-Věta Licence Haskell Balíček implementující QUIC pomocí odlehčených vláken jazyka Haskell.
netty-incubator-codec-quic Apache Licence 2.0 Java Implementace QUIC vycházející z netty na Quiche.
nodejs-quic Licence MIT NodeJs Experimentální balíček s implementací QUIC pro Nodejs.
s2n-quic Apache Licence 2.0 Rust Implementace v jazyce Rust s otevřeným zdrojovým textem z Amazon Web Services
swift-quic Apache Licence 2.0 Swift Implementace v jazyce Swift laděný pro incubation v Swift Server Workgroup.
TQUIC Apache Licence 2.0 Rust Vysoce výkonná, odlehčená a multiplatformní QUIC knihovna
Nginx BSD-2-Věta Licence C Implementace QUIC serveru s otevřeným zdrojovým textem
HAProxy GNU General Public License version 2 C Implementace QUIC serveru s otevřeným zdrojovým textem
kwik GNU Lesser General Public License version 3 Java Klientská a serverová implementace protokolu QUIC (RFC 9000) ve 100% Javě. Podporuje HTTP3 (RFC 9114) s "Flupke" přidaný.
OpenSSL Licence Apache C OpenSSL přidalo podporu QUIC od verze 3.2.[73]
GnuTLS GNU Lesser General Public License version 2.1 C GnuTLS přidalo podporu QUIC od verze 3.7.[74]

Odkazy

[editovat | editovat zdroj]

Reference

[editovat | editovat zdroj]

V tomto článku byl použit překlad textu z článku QUIC na anglické Wikipedii.

  1. ↑ a b
    • {{{označení}}}. {{{název}}}.
  2. ↑ a b
    • Nathan Willis. Connecting on the QUIC [online]. Linux Weekly News [cit. 2013-07-16]. Dostupné online. 
  3. ↑ a b c
    • QUIC: Design Document and Specification Rationale [online]. Jim Roskind, Chromium Contributor. Dostupné online. 
  4. ↑ a b
    • First Chromium Code Landing: CL 11125002: Add QuicFramer and friends. [online]. [cit. 2012-10-16]. Dostupné online. 
  5. ↑
    • Experimenting with QUIC [online]. Chromium Official Blog [cit. 2013-07-16]. Dostupné online. 
  6. ↑
    • QUIC, Google wants to make the web faster [online]. François Beaufort, Chromium Evangelist. Dostupné online. 
  7. ↑
    • QUIC: next generation multiplexed transport over UDP [online]. YouTube, 2014-02-11 [cit. 2014-04-04]. Dostupné online. 
  8. ↑ a b c d e
    • QUIC: IETF-88 TSV Area Presentation [online]. Jim Roskind, Google [cit. 2013-11-07]. Dostupné online. 
  9. ↑ a b c LARDINOIS, Frederic. Google Wants To Speed Up The Web With Its QUIC Protocol [online]. 2015-04-18 [cit. 2016-10-25]. Dostupné online. 
  10. ↑ a b MACKIE, Kurt; AUGUST 26, 2021. Microsoft Embracing Native QUIC in Newer Windows OSes and Edge Browser [online]. [cit. 2022-05-08]. Dostupné online. (anglicky) 
  11. ↑ Christopher Fernandes. Microsoft to add support for Google's QUIC fast internet protocol in Windows 10 Redstone 5 [online]. 2018-04-03 [cit. 2020-05-08]. Dostupné online. 
  12. ↑ a b Dragana Damjanovic. QUIC and HTTP/3 Support now in Firefox Nightly and Beta [online]. Mozilla, 2021-04-16 [cit. 2021-10-11]. Dostupné online. 
  13. ↑ a b BELSON, David; PARDUE, Lucas. Examining HTTP/3 usage one year on [online]. 2023-06-06 [cit. 2023-10-22]. Dostupné online. 
  14. ↑ LANGLEY, Adam; RIDDOCH, Alistair; WILK, Alyssa. The QUIC Transport Protocol: Design and Internet-Scale Deployment. In: SIGCOMM '17: Proceedings of the Conference of the ACM Special Interest Group on Data Communication. [s.l.]: ACM, 2017-08-07. Vývoj a využívání síťových protokolů v uživatelském prostoru přináší značné výhody, usnadňuje a zrychluje vývoj, testování a iterační cykly.. ISBN 978-1-4503-4653-5. doi:10.1145/3098822.3098842.
  15. ↑ Google Will Propose QUIC As IETF Standard [online]. [cit. 2016-10-25]. Dostupné online. 
  16. ↑ Šablona:Citace poštovní konference
  17. ↑ QUIC - IETF Working Group [online]. [cit. 2016-10-25]. Dostupné online. 
  18. ↑ a b c CIMPANU, Catalin. HTTP-over-QUIC to be renamed HTTP/3. www.zdnet.com. 2018-11-12. Dostupné online. 
  19. ↑ QUIC is now RFC 9000 [online]. 2021-05-27 [cit. 2021-05-28]. Dostupné online. (anglicky) 
  20. ↑ a b c d e f BRIGHT, Peter. The next version of HTTP won't be using TCP [online]. 2018-11-12. Dostupné online. 
  21. ↑ a b Thomson a Pauly 2021, A.5. TCP.
  22. ↑ Fairhurst a Perkins 2021, 4. Encryption and Authentication of Transport Headers.
  23. ↑ Edeline a Donnet 2019, s. 175–176.
  24. ↑ Raiciu et al. 2012, s. 1.
  25. ↑ Hesmans et al. 2013, s. 1.
  26. ↑ Rybczyńska 2020.
  27. ↑ BEHR, Michael; SWETT, Ian. Introducing QUIC support for HTTPS load balancing [online]. [cit. 2018-06-16]. Dostupné online. 
  28. ↑ a b SIMON, Clayton. QUIC: A UDP-Based Multiplexed and Secure Transport. datatracker.ietf.org. May 2021. Dostupné online. 
  29. ↑ Applicability of the QUIC Transport Protocol [online]. 2018-10-22. Dostupné online. 
  30. ↑ Corbet 2018.
  31. ↑ Trammell a Kuehlewind 2019, s. 2.
  32. ↑ , 2020. RFC8701; Applying Generate Random Extensions And Sustain Extensibility (GREASE) to TLS Extensibility [online]. Leden 2020. Dostupné online. 
  33. ↑ Thomson a Pauly 2021, 3.3. Falsifying Active Use.
  34. ↑ Thomson 2021, 2. Fixed Properties of All QUIC Versions.
  35. ↑ https://webthesis.biblio.polito.it/25561/1/tesi.pdf
  36. ↑ BISHOP, Mike. HTTP/3 and QUIC: Past, Present, and Future [online]. Akamai, 2021-06-21. Dostupné online. 
  37. ↑ a b DUKE, Martin; SARKER, Zaheduzzaman; WESTERLUND, Magnus. A new era in Internet transport [online]. IETF, 2021-06-03. Dostupné online. 
  38. ↑ {{{označení}}}. {{{název}}}.
  39. ↑ BRALLEY, Brett. What's the deal with Media Over QUIC? [online]. IETF, 2024-01-25. Dostupné online. 
  40. ↑ BURTRUM, Travis. XEP-0467: XMPP over QUIC [online]. 2022-07-13. Dostupné online. 
  41. ↑ PYLE, Ned. SMB over QUIC [online]. 2023-06-27 [cit. 2023-06-29]. Dostupné online. (anglicky) 
  42. ↑ LIEBETRAU, Etienne. How Google's QUIC Protocol Impacts Network Security and Reporting [online]. 2018-06-22 [cit. 2022-04-02]. Dostupné online. (anglicky) 
  43. ↑ CIMPANU, Catalin. Cloudflare, Google Chrome, and Firefox add HTTP/3 support [online]. 2019-09-26 [cit. 2019-09-27]. Dostupné online. 
  44. ↑ Release Notes for Safari Technology Preview 104 [online]. 2020-04-08 [cit. 2020-08-07]. Dostupné online. 
  45. ↑ Safari 14 Release Notes [online]. [cit. 2020-12-04]. Dostupné online. 
  46. ↑ How to enable HTTP3 in Chrome / Firefox / Safari [online]. 2020-04-08. Dostupné online. 
  47. ↑ Perform network operations using Cronet [online]. [cit. 2019-07-20]. Dostupné online. (anglicky) 
  48. ↑ curl – Changes [online]. [cit. 2019-09-30]. Dostupné online. 
  49. ↑ curl 7.66.0 – the parallel HTTP/3 future is here|daniel.haxx.se [online]. 2019-09-11 [cit. 2019-09-30]. Dostupné online. (anglicky) 
  50. ↑ How Facebook is bringing QUIC to billions [online]. 2020-10-21 [cit. 2020-10-23]. Dostupné online. (anglicky) 
  51. ↑ How Google's QUIC Protocol Impacts Network Security and Reporting [online]. 2020-10-21 [cit. 2021-06-26]. Dostupné online. (anglicky) 
  52. ↑ a b GREEN, Emily. This is what you need to know about the new QUIC protocol [online]. 2020-09-30 [cit. 2021-06-26]. Dostupné online. (anglicky) 
  53. ↑ , 2012. QUIC server [online]. 2012 [cit. 2022-08-17]. Dostupné online. 
  54. ↑ QUIC support by Akamai, Retrieved 20 May 2020.
  55. ↑ RÜTH, Jan; POESE, Ingmar; DIETZEL, Christoph; HOHLFELD, Oliver, 2018. Passive and Active Measurement. [s.l.]: [s.n.]. (Lecture Notes in Computer Science). ISBN 978-3-319-76480-1. doi:10.1007/978-3-319-76481-8_19. S2CID 3631501. arXiv 1801.05168. Kapitola A First Look at QUIC in the Wild, s. 255–268. 
  56. ↑ lucas-clemente/quic-go [online]. 2020-08-07 [cit. 2020-08-07]. Dostupné online. 
  57. ↑ QUIC support in Caddy, Retrieved 13 July 2016.
  58. ↑ LiteSpeed Web ADC – Load Balancer – LiteSpeed Technologies [online]. [cit. 2020-08-07]. Dostupné online. 
  59. ↑ LiteSpeed Technologies QUIC Blog Post, Retrieved July 11, 2017.
  60. ↑ Distribution of Web Servers among websites that use QUIC [online]. [cit. 2020-08-07]. Dostupné online. 
  61. ↑ Get a head start with QUIC [online]. 2018-09-25 [cit. 2019-07-16]. Dostupné online. 
  62. ↑ Announcing HAProxy 2.6 [online]. 2022-05-31 [cit. 2023-09-16]. Dostupné online. (anglicky) 
  63. ↑ [ANNOUNCE] haproxy-2.8.0 [online]. [cit. 2023-09-16]. Dostupné online. 
  64. ↑ Usage Statistics of QUIC for Websites, April 2023 [online]. [cit. 2023-04-03]. Dostupné online. 
  65. ↑ Enabling HTTP/3 support on Windows Server 2022 [online]. 2021-08-24. Dostupné online. 
  66. ↑ SMB over QUIC [online]. 2023-06-27. Dostupné online. 
  67. ↑ Policy configuration for HTTP/3 traffic | Citrix ADC 13.0 [online]. Dostupné online. 
  68. ↑ Need for speed? – Just an other Citrix ADC Blog [online]. Dostupné online. 
  69. ↑ devsisters/libquic [online]. 2020-08-05 [cit. 2020-08-07]. Dostupné online. 
  70. ↑ devsisters/goquic [online]. 2020-08-05 [cit. 2020-08-07]. Dostupné online. 
  71. ↑ Docker Hub [online]. [cit. 2020-08-07]. Dostupné online. 
  72. ↑ .NET 5 Networking Improvements [online]. 2021-01-11 [cit. 2021-01-26]. Dostupné online. (anglicky) 
  73. ↑ Openssl-quic - OpenSSL Documentation [online]. Dostupné online. 
  74. ↑ What's new in GnuTLS 3.7.0 – Daiki Ueno [online]. 2020-12-03. Dostupné online. 

Literatura

[editovat | editovat zdroj]
  • {{{označení}}}. {{{název}}}.
  • {{{označení}}}. {{{název}}}.
  • {{{označení}}}. {{{název}}}.
  • {{{označení}}}. {{{název}}}.
  • RAICIU; PAASCH; BARRE; FORD; HONDA; DUCHENE; BONAVENTURE, 2012. How Hard Can It Be? Designing and Implementing a Deployable Multipath TCP. Usenix NSDI. S. 399–412. Dostupné online. 
  • HESMANS, Benjamin; DUCHENE, Fabien; PAASCH, Christoph, 2013. Are TCP extensions middlebox-proof?. In: HotMiddlebox '13. [s.l.]: [s.n.]. doi:10.1145/2535828.2535830.
  • CORBET, Jonathan. QUIC as a solution to protocol ossification [online]. 2018-01-29. Dostupné online. 
  • EDELINE, Korian; DONNET, Benoit, 2019. A Bottom-Up Investigation of the Transport-Layer Ossification. In: 2019 Network Traffic Measurement and Analysis Conference (TMA). [s.l.]: [s.n.]. doi:10.23919/TMA.2019.8784690.
  • RYBCZYŃSKA, Marta. A QUIC look at HTTP/3 [online]. 2020-03-13. Dostupné online. 

Související články

[editovat | editovat zdroj]

Externí odkazy

[editovat | editovat zdroj]
Protokoly počítačových sítí a internetu podle modelu ISO/OSI
Aplikační vrstva – 7

BitTorrent • DNS • BOOTP • DHCP • FTP • Gopher • HTTP • HTTPS • IMAP • IRC • Ident • NNTP • NFS • NTP • POP3 • RTP • SIP • SMB • SMTP • SNMP • SSH • STUN • Telnet • XMPP

Prezentační vrstva – 6

NCP

Relační vrstva – 5

SPDY • SSL-TLS • NetBIOS • RPC • SMB • NFS

Transportní vrstva – 4

DCCP • QUIC • RUDP • SCTP • TCP • UDP

Síťová vrstva – 3

IPv4 • IPv6 • ICMP • IGMP … adresování • směrování

Linková vrstva – 2

Ethernet • FDDI • PPP • Token ring • Wi-Fi ... sběrnice • ARP • Proxy ARP • RARP

Fyzická vrstva – 1
topologie sítí
Citováno z „https://cs.wikipedia.org/w/index.php?title=QUIC&oldid=24917130“