De IETF (Internet Engineering Task Force), die verantwoordelijk is voor de ontwikkeling van internetprotocollen en -architectuur, heeft de oprichting van een RFC voor het HTTP/3.0-protocol voltooid en gerelateerde specificaties gepubliceerd onder de identificatiegegevens RFC 9114 (protocol) en RFC 9204 ( QPACK-headercompressietechnologie voor HTTP/3). De HTTP/3.0-specificatie heeft de status gekregen van een ‘Proposed Standard’, waarna het werk zal beginnen om de RFC de status van een conceptstandaard (Draft Standard) te geven, wat feitelijk een volledige stabilisatie van het protocol betekent en rekening houdend met alle de gemaakte opmerkingen. Tegelijkertijd werden bijgewerkte versies van de 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-caching-controleheaders definiëren. (RFC-9111).
Het HTTP/3-protocol definieert het gebruik van het QUIC-protocol (Quick UDP Internet Connections) als transport voor HTTP/2. QUIC is een uitbreiding van het UDP-protocol dat multiplexing van meerdere verbindingen ondersteunt en coderingsmethoden biedt die gelijkwaardig zijn aan TLS/SSL. Het protocol is in 2013 door Google gemaakt als alternatief voor de TCP+TLS-combinatie voor het web, waardoor problemen met lange verbindingsopbouw en onderhandelingstijden in TCP worden opgelost en vertragingen worden geëlimineerd wanneer pakketten verloren gaan tijdens gegevensoverdracht.
Momenteel is QUIC- en HTTP/3.0-ondersteuning al geïmplementeerd in alle populaire webbrowsers (in Chrome, Firefox en Edge is HTTP/3-ondersteuning standaard ingeschakeld, en in Safari is de instelling “Geavanceerd > Experimentele functies > HTTP/3” vereist ingeschakeld te worden). Aan de serverkant zijn HTTP/3-implementaties beschikbaar voor nginx (in een aparte branch en in de vorm van een aparte module), Caddy, IIS en LiteSpeed. HTTP/3-ondersteuning wordt ook geboden door het Cloudflare content delivery-netwerk.
Belangrijkste kenmerken van QUIC:
- Hoge beveiliging, vergelijkbaar met TLS (in feite biedt QUIC de mogelijkheid om TLS via UDP te gebruiken);
- Streamintegriteitscontrole om pakketverlies te voorkomen;
- De mogelijkheid om onmiddellijk een verbinding tot stand te brengen (0-RTT, in ongeveer 75% van de gevallen kunnen gegevens onmiddellijk na het verzenden van het verbindingsopbouwpakket worden verzonden) en minimale vertragingen bieden tussen het verzenden van een verzoek en het ontvangen van een antwoord (RTT, Round Trip Time);
- Het gebruik van een ander volgnummer bij het opnieuw verzenden van een pakket, waardoor dubbelzinnigheid bij het identificeren van ontvangen pakketten wordt vermeden en time-outs worden voorkomen;
- Pakketverlies heeft alleen invloed op de bezorging van de bijbehorende stream en stopt niet de bezorging van gegevens in streams die parallel worden verzonden via de huidige verbinding;
- Foutcorrectietools die vertragingen minimaliseren als gevolg van het opnieuw verzenden van verloren pakketten. Gebruik van speciale foutcorrectiecodes op pakketniveau om situaties te verminderen waarbij verloren pakketgegevens opnieuw moeten worden verzonden.
- Cryptografische blokgrenzen zijn uitgelijnd met QUIC-pakketgrenzen, waardoor de impact van pakketverliezen op het decoderen van de inhoud van volgende pakketten wordt verminderd;
- Geen problemen met het blokkeren van de TCP-wachtrij;
- Verbindings-ID-ondersteuning om de herverbindingstijd voor mobiele clients te verkorten;
- Mogelijkheid om geavanceerde mechanismen aan te sluiten voor controle over overbelasting van verbindingen;
- Het gebruik van bandbreedtevoorspellingstechnieken in elke richting om te zorgen voor optimale verzendsnelheden van pakketten, waardoor wordt voorkomen dat er congestie ontstaat waarbij pakketten verloren gaan;
- Aanzienlijke toename in prestaties en doorvoer vergeleken met TCP. Voor videodiensten zoals YouTube is aangetoond dat QUIC het herbufferen bij het bekijken van video's met 30% vermindert.
Onder de wijzigingen in de HTTP/1.1-specificatie valt het verbod op het geïsoleerde gebruik van het Carriage Return (CR)-teken buiten de hoofdtekst met inhoud op, d.w.z. In protocolelementen kan het CR-teken alleen worden gebruikt in combinatie met het line feed-teken (CRLF). Het indelingsalgoritme voor gefragmenteerde verzoeken is verbeterd om de scheiding van bijgevoegde velden en secties met kopteksten te vereenvoudigen. Aanbevelingen toegevoegd voor het omgaan met dubbelzinnige inhoud om “HTTP Request Smokkel”-aanvallen te blokkeren, waardoor we ons kunnen inleven in de inhoud van de verzoeken van andere gebruikers in de stroom tussen de frontend en de backend.
De HTTP/2.0-specificatie-update definieert expliciet ondersteuning voor TLS 1.3. Het prioriteringsschema en de bijbehorende koptekstvelden zijn verouderd. Het ongebruikte mechanisme voor het updaten van de verbinding met HTTP/1.1 is verouderd verklaard. Verminderde vereisten voor het controleren van veldnamen en waarden. Er worden enkele eerder gereserveerde frametypen en parameters voorgesteld voor gebruik. De verboden headervelden die verband houden met de verbinding zijn nauwkeuriger gedefinieerd.
Bron: opennet.ru