Internet Engineering Task Force (IETF), den kommitté som utvecklar protokoll och arkitektur för internet, har färdigställt 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 detektering av paketförlust under dataöverföring).
RFC:erna har fått statusen "Proposed Standard", varefter arbetet med att ge RFC:erna statusen som ett utkast till standard (Draft Standard) kommer att påbörjas, vilket i själva verket innebär att protokollet har stabiliserats helt och alla kommentarer har beaktats. HTTP/3-protokollet, som definierar användningen av QUIC-protokollet som transport för HTTP/2, är fortfarande i ett utkast till specifikation, men det kommer snart att slutgiltigt standardiseras i IETF.
Det förväntas att standardiseringen av QUIC kommer att ge drivkraft till ett bredare införande av detta protokoll, såväl som till utveckling av tillägg baserade på det, såsom WebTransport (en teknik för att skicka och ta emot data mellan en webbläsare och server) och MASQUE (en anslutningsproxyteknik som utökar funktionerna hos 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
