I de nattliga och beta-versionerna av Firefox är stöd för HTTP/3 aktiverat som standard

I de nattsamlade versionerna av Firefox samt i beta-versionen är stödet för protokollet HTTP/3 som standard aktiverat. I den stabila versionen planeras aktiveringen av HTTP/3 för utgåvan av Firefox 88, som är schemalagd till den 20 april. I Chrome började selektiv aktivering av HTTP/3 i oktober 2020.

Stödet för HTTP/3 i Firefox baseras på det av Mozilla utvecklade projektet neqo, som tillhandahåller implementeringen av klienten och servern för protokollet QUIC. Koden för komponenterna för att stödja HTTP/3 och QUIC är skriven i Rust. För att styra aktiveringen av HTTP/3 i about:config finns det ett alternativ "network.http.http3.enabled". Inom klientprogramvaran har experimentellt stöd för HTTP/3 också redan lagts till i Chrome och curl, och för servrar är det tillgängligt i nginx, samt i form av en nginx-modul och en testserver från Cloudflare. För att kontrollera funktionen hos HTTP/3-klienter har flera testwebbplatser lanserats.

Protokollet HTTP/3 är fortfarande i stadiet för skissspecifikation och har ännu inte standardiserats inom IETF. HTTP/3 definierar användningen av protokollet QUIC som transport för HTTP/2. Protokollet QUIC (Quick UDP Internet Connections) har utvecklats av Google sedan 2013 som ett alternativ till TCP+TLS för webben, vilket löser problem med lång tid för att upprätta och förhandla anslutningar i TCP och eliminerar fördröjningar vid paketförluster under datatransmission. QUIC är en överbyggnad på UDP-protokollet som stöder multiplexering av flera anslutningar och tillhandahåller krypteringsmetoder som motsvarar TLS/SSL. Under utvecklingen av standarden i IETF har förändringar gjorts i protokollet, vilket har lett till att två parallella grenar existerar, en för HTTP/3 och den andra som stöds av Google (Chrome stöder båda varianterna).

Huvudfunktioner i QUIC:

• Hög säkerhet, liknande TLS (i praktiken ger QUIC möjlighet till användning av TLS över UDP);
• Kontroll av strömmens integritet, vilket förhindrar pak förlust;
• Möjlighet att omedelbart upprätta en anslutning (0-RTT, i ungefär 75% av fallen kan data överföras omedelbart efter att anslutningsinstallationspaketet skickats) och säkerställa minimala fördröjningar mellan begäran och svar (RTT, Round Trip Time);
• Användning av ett annat sekvensnummer vid omöverföring av paket, vilket undviker tvetydighet vid identifiering av mottagna paket och eliminerar tidsavbrott;
• Paketsförlust påverkar endast leveransen av den relaterade strömmen och stoppar inte dataöverföringen i parallella strömmar som sänds via den aktuella anslutningen;
• Felkorrekteringsmedel som minimerar förseningar på grund av återöverföring av förlorade paket. Användning av speciella felkorrekteringskoder på paketnivå för att minska situationer där återöverföring av förlorad data krävs.
• Gränserna för kryptografiska block överensstämmer med gränserna för QUIC-paketen, vilket minskar påverkan av paketförluster på avkodningen av innehållet i efterföljande paket;
• Ingen köblockering som uppstår i TCP;
• Stöd för anslutningsidentifierare som gör att tiden för att återansluta till mobila kunder minskar;
• Möjlighet att ansluta avancerade mekanismer för överbelastningskontroll;
• Användning av tekniker för kapacitetsprognoser i varje riktning för att säkerställa optimal paketöverföringstakt och förhindra att man hamnar i en överbelastad status där paketförluster observeras;
• En märkbar ökning av prestanda och kapacitet jämfört med TCP. För videotjänster såsom YouTube har användningen av QUIC visat en minskning av ombuffring under videovisning med 30%.

Källa: opennet.ru