QUIC-protokollen har fått status som foreslått standard.

Internet Engineering Task Force (IETF), som er ansvarlig for utviklingen av Internett-protokoller og arkitektur, har ferdigstilt RFC for QUIC-protokollen og publisert relaterte spesifikasjoner under identifikatorene RFC 8999 (versjonsuavhengige protokollegenskaper), RFC 9000 (transport). over UDP), RFC 9001 (TLS-kryptering av QUIC-kommunikasjonskanalen) og RFC 9002 (overbelastningskontroll og deteksjon av pakketap under dataoverføring).

RFC-ene fikk status som «Proposed Standard», hvoretter arbeidet vil starte med å gi RFC-status som et utkast til standard (Draft Standard), som faktisk betyr en fullstendig stabilisering av protokollen og tatt i betraktning alle kommentarer som er kommet. HTTP/3-protokollen, som definerer bruken av QUIC-protokollen som en transport for HTTP/2, er fortsatt på utkastet til spesifikasjonsstadiet, men den vil snart bli endelig standardisert av IETF.

Det forventes at standardiseringen av QUIC vil gi drivkraft til bredere bruk av denne protokollen, samt til utvikling av utvidelser basert på den, for eksempel WebTransport (en teknologi for å sende og motta data mellom en nettleser og server) og MASQUE (en tilkoblingsproxyteknologi som utvider funksjonaliteten til SOCKS og HTTP CONNECT og bruker HTTPS over QUIC som transport).

La oss huske at QUIC (Quick UDP Internet Connections)-protokollen har blitt utviklet av Google siden 2013 som et alternativ til TCP+TLS-kombinasjonen for nettet, og løser problemer med lange oppsett- og forhandlingstider for tilkoblinger i TCP og eliminerer forsinkelser når pakker går tapt under dataoverføring. QUIC er en utvidelse av UDP-protokollen som støtter multipleksing av flere tilkoblinger og gir krypteringsmetoder tilsvarende TLS/SSL. Under utviklingen av IETF-standarden ble det gjort endringer i protokollen, noe som førte til fremveksten av to parallelle grener, en for HTTP/3, og den andre støttet av Google (Chrome støtter begge alternativene, og Firefox støtter IETF-versjonen) .

Nøkkelfunksjoner til QUIC:

• Høy sikkerhet som ligner på TLS (i hovedsak gir QUIC muligheten til å bruke TLS over UDP);
• Flytintegritetskontroll, forhindrer pakketap;
• Muligheten til å umiddelbart opprette en forbindelse (0-RTT, i omtrent 75 % av tilfellene kan data overføres umiddelbart etter sending av tilkoblingsoppsettpakken) og gir minimale forsinkelser mellom sending av en forespørsel og mottak av svar (RTT, Round Trip Time);
• Bruk av et annet sekvensnummer når du sender en pakke på nytt, noe som unngår tvetydighet i å identifisere mottatte pakker og eliminerer tidsavbrudd;
• Tap av en pakke påvirker bare leveringen av strømmen knyttet til den og stopper ikke leveringen av data i parallelle strømmer som overføres gjennom den gjeldende forbindelsen;
• Feilrettingsfunksjoner som minimerer forsinkelser på grunn av reoverføring av tapte pakker. Bruk av spesielle feilrettingskoder på pakkenivå for å redusere situasjoner som krever reoverføring av tapte pakkedata.
• Kryptografiske blokkgrenser er justert med QUIC-pakkegrenser, noe som reduserer effekten av pakketap på dekoding av innholdet i påfølgende pakker;
• Ingen problemer med blokkering av TCP-kø;
• Støtte for tilkoblingsidentifikator, som reduserer tiden det tar å etablere en ny tilkobling for mobilklienter;
• Mulighet for å koble til avanserte mekanismer for kontroll av overbelastning;
• Bruker prognoseteknikker per retning for å sikre at pakker sendes med optimale hastigheter, og forhindrer at de blir overbelastet og forårsaker pakketap;
• Betydelig økning i ytelse og gjennomstrømning sammenlignet med TCP. For videotjenester som YouTube, har QUIC vist seg å redusere tilbakestillingsoperasjoner når du ser på videoer med 30 %.

Kilde: opennet.ru