IETF (Internet Engineering Task Force), som utvecklar Internetprotokoll och arkitektur, har slutfört RFC för QUIC-protokollet och publicerat relaterade specifikationer under identifierarna RFC 8999 (versionsoberoende protokollegenskaper), RFC 9000 (transport över UDP), RFC 9001 (TLS-kryptering av QUIC-kommunikationskanalen) och RFC 9002 (överbelastningskontroll och paketförlustdetektering under dataöverföring).
RFC:erna fick statusen ”Proposed Standard”, varefter arbetet påbörjas för att ge RFC status som ett utkast till standard (Draft Standard), vilket egentligen innebär en fullständig stabilisering av protokollet och med hänsyn tagen till alla kommentarer som gjorts. HTTP/3-protokollet, som definierar användningen av QUIC-protokollet som en transport för HTTP/2, är fortfarande på utkast till specifikationsstadiet, men det kommer snart att slutligen standardiseras av IETF.
Det förväntas att standardiseringen av QUIC kommer att ge impulser till ett bredare antagande av detta protokoll, såväl som till utvecklingen av tillägg baserade på det, såsom WebTransport (en teknik för att skicka och ta emot data mellan en webbläsare och en server) och MASQUE (en anslutningsproxyteknik som utökar kapaciteten för SOCKS och HTTP CONNECT, och använder HTTPS över QUIC som transport).
Låt oss komma ihåg att protokollet QUIC (Quick UDP Internet Connections) har utvecklats av Google sedan 2013 som ett alternativ till TCP+TLS-kombinationen för webben, vilket löser problem med den långa installations- och förhandlingstiden för anslutningar i TCP och eliminerar förseningar när paket går förlorade under dataöverföring. QUIC är en förlängning av UDP-protokollet som stöder multiplexering av flera anslutningar och tillhandahåller krypteringsmetoder motsvarande TLS/SSL. Under utvecklingen av IETF-standarden gjordes ändringar i protokollet, vilket ledde till uppkomsten av två parallella grenar, en för HTTP/3, och den andra som stöds av Google (Chrome stöder båda alternativen, och Firefox stöder IETF-versionen) .
Nyckelfunktioner hos QUIC:
- Hög säkerhet liknande TLS (QUIC ger i huvudsak möjlighet att använda TLS över UDP);
- Flödesintegritetskontroll, förhindrar paketförlust;
- Möjligheten att omedelbart upprätta en anslutning (0-RTT, i cirka 75 % av fallen kan data överföras omedelbart efter att anslutningspaketet har skickats) och ger minimala förseningar mellan att skicka en förfrågan och ta emot ett svar (RTT, Round Trip Time);
- Användning av ett annat sekvensnummer vid återsändning av ett paket, vilket undviker tvetydighet vid identifiering av mottagna paket och tar bort timeouts;
- Förlust av ett paket påverkar endast leveransen av strömmen som är associerad med den och stoppar inte leveransen av data i parallella strömmar som överförs genom den aktuella anslutningen;
- Felkorrigeringsfunktioner som minimerar förseningar på grund av återsändning av förlorade paket. Användning av speciella felkorrigeringskoder på paketnivå för att minska situationer som kräver återsändning av förlorad paketdata.
- Kryptografiska blockgränser är anpassade till QUIC-paketgränser, vilket minskar effekten av paketförluster på avkodning av innehållet i efterföljande paket;
- Inga problem med TCP-köblockering;
- Stöd för anslutningsidentifierare, vilket minskar tiden det tar att upprätta en återanslutning för mobila klienter;
- Möjlighet att ansluta avancerade mekanismer för kontroll av överbelastning av anslutningar;
- Använder tekniker för prognostisering av genomströmning per riktning för att säkerställa att paket skickas med optimala hastigheter, vilket förhindrar att de blir överbelastade och orsakar paketförlust;
- Betydande ökning av prestanda och genomströmning jämfört med TCP. För videotjänster som YouTube har QUIC visat sig minska återlagringsoperationer när du tittar på videor med 30 %.
Källa: opennet.ru