Vývojáři nedávno kteří jsou pozadu z webového prohlížeče Google Chrome, vydal zprávu o přidání podpory protokolu HTTP / 3 k experimentálním sestavením Chrome Canary, který implementuje plugin umožňující HTTP přes QUIC.
Samotný protokol QUIC byl do prohlížeče přidán před pěti lety a od té doby se používá k optimalizaci práce se službami Google. Současně se QUIC verze Google použitá v prohlížeči Chrome v některých detailech lišila od verze specifikací IETF, ale implementace jsou nyní synchronizované.
Google Chrome Canary se stal prvním (dostupným) prohlížečem, který integroval (velmi) experimentální # RYCHLE a podpora HTTP / 3!
Přidejte příznaky „–enable-quic –quic-version = h3-23“ a v devtools byste měli vidět „http / 2 + quic / 99“, což je ve skutečnosti http3 v přestrojení! pic.twitter.com/5Fhui46h3x
- Robin Marx (@programmingart) Září 19, 2019
Je důležité to zdůraznit Google vyvinul QUIC (Rychlé internetové připojení UDP) od roku 2013 jako alternativa k balíčku TCP + TLS pro web, který řeší problémy s dlouhými časy konfigurace a vyjednávání pro připojení TCP a eliminuje zpoždění ztráty paketů během přenosu dat.
QUIC je doplňkem protokolu UDP, který podporuje multiplexování více připojení a poskytuje šifrovací metody ekvivalentní TLS / SSL.
Dotyčný protokol je již zabudován do serverové infrastruktury Google, je součástí Chromu, plánuje se jeho začlenění do Firefoxu a aktivně se používá k poskytování požadavků klientů na serverech Google.
Mezi hlavní charakteristiky QUIC, které vynikají, patří:
- Vysoké zabezpečení, podobné TLS (ve skutečnosti poskytuje QUIC možnost používat TLS přes UDP)
- Řízení integrity toku, které zabraňuje ztrátě paketů
- Schopnost navázat připojení okamžitě (0-RTT, v asi 75% případů lze data přenášet okamžitě po odeslání paketu nastavení připojení) a zajistit minimální zpoždění mezi odesláním požadavku a přijetím odpovědi (RTT, Round Trip Time)
- Nepoužívání stejného pořadového čísla při opětovném přenosu paketu, což zabrání nejednoznačnosti při určování přijatých paketů a eliminuje čekací doby
- Ztráta paketu ovlivní doručení pouze s ním spojeného streamu a nezastaví doručení dat v streamech přenášených paralelně přes aktuální připojení
- Nástroje pro opravu chyb, které minimalizují zpoždění v důsledku opakovaného přenosu ztracených paketů.
- Použití speciálních kódů pro opravu chyb na úrovni paketů ke snížení situací, které vyžadují opakovaný přenos ztracených dat paketů.
- Kryptografické limity bloků jsou zarovnány s limity paketů QUIC, což snižuje účinek ztráty paketů na dekódování obsahu následujících paketů
- Žádné problémy s blokováním fronty TCP
- Podpora identifikátoru připojení, která zkracuje dobu potřebnou k navázání opětovného připojení pro mobilní klienty
- Schopnost připojit pokročilé mechanismy pro řízení přetížení připojení
Je také zdůrazněno, že využívá techniku předpovídání šířky pásma v každém směru zajistit optimální intenzitu doručování paketů a zabránit tak dosažení stavu přetížení, při kterém je pozorována ztráta paketů;
Stejně jako pozoruhodný výkon a zvýšení výkonu přes TCP. U video služeb, jako je YouTube, vykázal QUIC 30% snížení operací opětovného ukládání do vyrovnávací paměti při sledování videí.
Protokol HTTP / 3 standardizuje použití QUIC jako přenosu pro HTTP / 2. Chcete-li povolit protokol HTTP / 3 a verzi QUIC 23 návrhů specifikací IETF, musí být Chrome spuštěn s možnostmi „–enable-quic –quic-version = h3-23“ a poté, když se otevře stránka pro rychlý test .rocks: 4433 in režim inspekce sítě v nástrojích pro vývojáře, aktivita HTTP / 3 se zobrazí jako „http / 2 + quic / 99“.
Ve srovnání s paketem ztraceným paralelním připojením HTTP bude zastaveno pouze 1 z mnoha připojení, což znamená, že QUIC může podporovat doručování mimo objednávku, takže ztracený paket bude mít menší dopad.
Si chcete o tom vědět víc o tom se můžete poradit následující odkaz.