IETF (Internet Engineering Task Force), which is responsible for the development of internet protocols and architecture, has completed the formation of the RFC for the QUIC protocol and published related specifications under the identifiers RFC 8999 (version-independent properties of the protocol), RFC 9000 (transport over UDP), RFC 9001 (TLS encryption for the QUIC communication channel), and RFC 9002 (congestion control and packet loss detection during data transmission).
The RFCs have received the status of 'Proposed Standard', after which work will begin to elevate the RFCs to the status of Draft Standard, essentially meaning complete stabilization of the protocol and consideration of all expressed remarks. The HTTP/3 protocol, which defines the use of QUIC as transport for HTTP/2, is currently in draft specification stage, but it will soon be finalized and standardized in the IETF.
It is expected that the standardization of QUIC will boost the wider adoption of this protocol, as well as the development of extensions based on it, such as WebTransport (a technology for sending and receiving data between the browser and serverom) and MASQUE (a connection proxying technology that expands the capabilities of SOCKS and HTTP CONNECT, using HTTPS over QUIC as transport).
Recall that the QUIC (Quick UDP Internet Connections) protocol has been developed by Google since 2013 as an alternative to the TCP+TLS combination for the Web, addressing issues with long connection setup and negotiation times in TCP and eliminating delays during packet loss in data transmission. QUIC is a layer on top of the UDP protocol that supports multiplexing multiple connections and provides encryption methods equivalent to TLS/SSL. During the development of the standard in the IETF, changes were made to the protocol, leading to the emergence of two parallel branches, one for HTTP/3 and the other supported by Google (Chrome supports both versions, while Firefox supports the IETF version).
Key features of QUIC:
- High security comparable to TLS (essentially QUIC allows the use of TLS over UDP);
- Nadzor nad celovitostjo toka, ki preprečuje izgubo paketov;
- Možnost takojšnjega vzpostavljanja povezave (0-RTT, v približno 75% primerov se lahko podatki prenašajo takoj po pošiljanju paketa za vzpostavitev povezave) ter zagotavljanje minimalnih zamud med pošiljanjem zahtevka in prejemanjem odgovora (RTT, Round Trip Time);
- Uporaba druge številke zaporedja pri ponovnem pošiljanju paketa, kar omogoča izogibanje zmedenosti pri določanju prejetih paketov in odpravo časovnih zamud;
- Izguba paketa vpliva le na dostavo povezanega toka in ne ustavi dostave podatkov v hkrati poslanih tokovih preko trenutne povezave;
- Sredstva za korekcijo napak, ki minimizirajo zamude zaradi ponovnega pošiljanja izgubljenih paketov. Uporaba posebnih kod za korekcijo napak na nivoju paketa za zmanjšanje situacij, ki zahtevajo ponovno pošiljanje podatkov izgubljenega paketa.
- Meje kriptografskih blokov so poravnane z mejami QUIC paketov, kar zmanjšuje vpliv izgub paketov na dekodiranje vsebine naslednjih paketov;
- Brez težav z blokiranjem TCP vrstice;
- Podpora identifikatorju povezave, ki omogoča skrajšanje časa za ponovno vzpostavitev povezave za mobilne stranke;
- Možnost povezovanja razširjenih mehanizmov za nadzor obremenitve povezave;
- Uporaba tehnike napovedovanja propustnosti v vsaki smeri za zagotavljanje optimalne intenzivnosti pošiljanja paketov, preprečevanje preklopa v stanje obremenitve, pri katerem pride do izgube paketov;
- Opazno povečanje zmogljivosti in prepustnosti v primerjavi s TCP. Pri video storitvah, kot je YouTube, je uporaba QUIC pokazala 30% zmanjšanje operacij ponovnega buffiranja pri predvajanju videoposnetkov.
Izvor: opennet.ru
