Het IETF-comité (Internet Engineering Task Force), dat zich bezighoudt met de ontwikkeling van protocollen en de architectuur van het internet, heeft de RFC voor het HTTP/3.0-protocol afgerond en gerelateerde specificaties gepubliceerd met de identificaties RFC 9114 (protocol) en RFC 9204 (technologie voor het comprimeren van headers QPACK voor HTTP/3). De specificatie HTTP/3.0 heeft de status 'Voorgesteld Standaard' gekregen, waarna het proces begint om de RFC de status van een draft standaard (Draft Standard) te geven, wat feitelijk betekent dat het protocol volledig gestabiliseerd is en rekening houdt met alle gemaakte opmerkingen. Tegelijkertijd zijn bijgewerkte versies van specificaties voor de protocollen HTTP/1.1 (RFC 9112) en HTTP/2.0 (RFC 9113) gepubliceerd, evenals documenten die de semantiek van HTTP-verzoeken (RFC 9110) en HTTP-headers voor cachebeheer (RFC 9111) definiëren.
Het HTTP/3-protocol definieert het gebruik van het QUIC (Quick UDP Internet Connections) protocol als transport voor HTTP/2. QUIC is een bovenlaag van het UDP-protocol dat multiplexing van meerdere connecties ondersteunt en versleutelingsmethoden biedt die gelijkwaardig zijn aan TLS/SSL. Het protocol is in 2013 ontwikkeld door Google als alternatief voor de combinatie TCP+TLS voor het web, en lost problemen op met lange verbindingsinstellingen en onderhandeling in TCP en elimineert vertragingen bij pakketverlies tijdens de gegevensoverdracht.
Momenteel is de ondersteuning voor QUIC en HTTP/3.0 al gerealiseerd in alle populaire webbrowser (in Chrome, Firefox en Edge is de ondersteuning voor HTTP/3 standaard ingeschakeld, terwijl het in Safari vereist is om de instelling 'Geavanceerd > Experimenten > HTTP/3' in te schakelen). Aan de serverzijde zijn implementaties van HTTP/3 beschikbaar voor nginx (in een aparte tak en in de vorm van een aparte module), Caddy, IIS en LiteSpeed. Ondersteuning voor HTTP/3 wordt ook geboden door het content delivery netwerk Cloudflare.
Belangrijkste kenmerken van QUIC:
- Hoge beveiliging, vergelijkbaar met TLS (in wezen biedt QUIC de mogelijkheid om TLS boven UDP te gebruiken);
- Integriteitscontrole van de stream, wat pakketverlies voorkomt;
- De mogelijkheid om onmiddellijk een verbinding op te zetten (0-RTT, in ongeveer 75% van de gevallen kunnen gegevens direct worden verzonden na het versturen van het verbindingsinstallatiepakket) en om minimale vertragingen te garanderen tussen het verzenden van een verzoek en het ontvangen van een antwoord (RTT, Round Trip Time);
- Gebruik van een ander volgnummer voor de opnieuw verzonden pakketten, waardoor verwarring bij de identificatie van ontvangen pakketten wordt vermeden en time-outs worden geëlimineerd;
- Pakketverlies heeft alleen invloed op de aflevering van de bijbehorende stroom en stopt de aflevering van gegevens in de parallelle stromen die via de huidige verbinding worden verzonden;
- Foutcorrectiemechanismen verminderen vertragingen door het opnieuw verzenden van verloren pakketten. Het gebruik van speciale foutcorrectiecodes op het niveau van pakketten om situaties te verkorten die opnieuw verzenden van verloren gegevens vereisen.
- De grenzen van cryptografische blokken zijn afgestemd op de grenzen van QUIC-pakketten, wat de impact van pakketverlies op de decodering van de inhoud van volgende pakketten vermindert.
- Geen problemen met TCP-queue blocking.
- Ondersteuning voor een connectie-ID, waardoor de tijd voor het opnieuw tot stand brengen van een verbinding voor mobiele clients kan worden verkort.
- De mogelijkheid om geavanceerde mechanismen voor congestiecontrole in te schakelen.
- Het gebruik van bandbreedtevoorspellingstechnieken in beide richtingen om een optimale verzendintensiteit van pakketten te waarborgen, en te voorkomen dat het systeem in een overbelastingsstaat terechtkomt waarin pakketverlies optreedt.
- Een significante toename van prestaties en bandbreedte in vergelijking met TCP. Voor videoservices zoals YouTube heeft het gebruik van QUIC geleid tot een vermindering van het aantal herbufferingsoperaties met 30% tijdens het bekijken van video's.
Een van de wijzigingen in de specificatie van HTTP/1.1 is het verbod op het afzonderlijk gebruik van het carriage return (CR) teken buiten de inhoud, dat wil zeggen, binnen protocol-elementen kan het CR teken alleen samen met het line feed (CRLF) teken worden gebruikt. Het algoritme voor het samenstellen van chunked-verzoeken is verbeterd om het splitsen van bijgevoegde velden en het hoofdkoppen te vereenvoudigen. Aanbevelingen zijn toegevoegd voor de verwerking van ambiguë inhoud om aanvallen van het type ‘HTTP Request Smuggling’ te blokkeren, die het mogelijk maken om in de inhoud van andere gebruikersverzoeken in de stroom tussen de frontend en backend te infiltreren.
In de update van de specificatie HTTP/2.0 is expliciet ondersteuning voor TLS 1.3 gedefinieerd. De methode voor het vaststellen van prioriteiten en de bijbehorende velden in de headers is geclassificeerd als verouderd. Een niet wijdverspreide methode voor het bijwerken van verbindingen naar HTTP/1.1 is verouderd verklaard. De vereisten voor het controleren van de namen van velden en waarden zijn verminderd. Bepaalde eerder gereserveerde frame-types en parameters zijn voorgesteld voor gebruik. Verboden header-velden met betrekking tot verbinding zijn nauwkeuriger gedefinieerd.
Bron: opennet.ru
