IETF (Internet Engineering Task Force), der arbejder med udviklingen af internetprotokoller og arkitektur, har færdiggjort RFC for QUIC-protokollen og offentliggjort relaterede specifikationer under identifierene RFC 8999 (versionsuafhængige egenskaber ved protokollen), RFC 9000 (transport over UDP), RFC 9001 (TLS-kryptering af QUIC-forbindelsen) og RFC 9002 (overbelastningshåndtering og bestemmelse af pakktab under datatransmission).
RFC'erne har fået status som 'Forslået standard', hvorefter arbejdet med at opnå status som udkaststandard (Draft Standard) vil begynde, hvilket i praksis betyder en fuld stabilisering af protokollen og hensyntagen til alle fremsatte bemærkninger. Protokollen HTTP/3, som definerer brugen af QUIC-protokollen som transport for HTTP/2, er endnu i udkastsspecifikationsfasen, men snart vil den også blive endeligt standardiseret i IETF.
Det forventes, at standardiseringen af QUIC vil give et skub til bredere implementering af denne protokol samt udvikling af udvidelser baseret på den, såsom WebTransport (teknologi til afsendelse og modtagelse af data mellem browseren og serveren) og MASQUE (teknologi til proxyforbindelser, der udvider mulighederne for SOCKS og HTTP CONNECT, og bruger HTTPS over QUIC som transport).
Det skal bemærkes, at QUIC-protokollen (Quick UDP Internet Connections) har været under udvikling af Google siden 2013 som et alternativ til TCP+TLS for web, som løser problemerne med lang tid til etablering og forhandling af forbindelser i TCP og fjerner forsinkelser ved pakketab under datatransmission. QUIC er et lag oven på UDP-protokollen, der understøtter multiplexing af flere forbindelser og tilbyder krypteringsmetoder svarende til TLS/SSL. Under udviklingen af standarden i IETF er der blevet foretaget ændringer i protokollen, hvilket har ført til oprettelsen af to parallelt eksisterende grene, én til HTTP/3 og den anden understøttet af Google (Chrome understøtter begge versioner, mens Firefox understøtter IETF-versionen).
Hovedfunktionerne ved QUIC:
- Høj sikkerhed svarende til TLS (faktisk giver QUIC mulighed for brug af TLS oven på UDP);
- Overvågning af strømmens integritet, der forhindrer tab af pakker;
- Mulighed for straks at etablere en forbindelse (0-RTT, i cirka 75% af tilfældene kan data overføres umiddelbart efter, at forbindelsespakken er sendt) og sikre minimale forsinkelser mellem anmodningens afsendelse og modtagelsen af svar (RTT, Round Trip Time);
- Brug af et andet sekvensnummer ved genoverførsel af pakken, hvilket gør det muligt at undgå tvetydighed ved bestemmelse af modtagne pakker og eliminere timeouts;
- Pakketab påvirker kun leveringen af den tilknyttede strøm og stopper ikke dataoverførslen i parallelt overførte strømme gennem den aktuelle forbindelse;
- Fejlkorrektionsmidler, der minimerer forsinkelser på grund af genoverførsel af tabte pakker. Brug af specialiserede fejlkorrektionskoder på pakkeniveau for at reducere situationer, der kræver genoverførsel af data fra en tabt pakke.
- Grænserne for kryptografiske blokke er justeret med grænserne for QUIC-pakker, hvilket reducerer tabspakkernes indvirkning på afkodningen af indholdet i efterfølgende pakker;
- Ingen problemer med TCP-køblokering;
- Understøttelse af forbindelsesidentifikatoren, der reducerer tiden til at etablere en genforbindelse for mobile klienter;
- Mulighed for at tilslutte udvidede mekanismer til overvågning af forbindelsesoverbelastning;
- Brug af kapacitetsprognoseteknikker i hver retning for at sikre optimal intensitet i pakkeafsendelsen, hvilket forhindrer at glide ind i en overbelastningssituation, hvor pakkemister forekommer;
- Bemærkelsesværdige præstations- og kapacitetsforøgelser sammenlignet med TCP. For videotjenester såsom YouTube har anvendelsen af QUIC vist sig at reducere genbufferingsoperationer med 30% under videovisning.
Kilde: opennet.ru
