Chrome voegt experimentele HTTP/3-ondersteuning toe

Naar experimentele builds Chrome Canary toegevoegd ondersteuning voor het HTTP/3-protocol, dat een add-on implementeert om HTTP-werking via het QUIC-protocol te garanderen. Het QUIC-protocol zelf is vijf jaar geleden aan de browser toegevoegd en wordt sindsdien gebruikt om het werken met Google-services te optimaliseren. Tegelijkertijd verschilde de QUIC-variant van Google die in Chrome werd gebruikt op enkele details van de variant van specificaties IETF, maar de implementaties lopen nu synchroon.

HTTP/3 standaardiseert het gebruik van QUIC als transportmiddel voor HTTP/2. Om HTTP/3 en de QUIC-optie in te schakelen vanaf 23 ontwerpen IETF-specificaties vereisen dat Chrome wordt gestart met opties "--enable-quic --quic-version=h3-23", waarna bij het openen van een testsite snel.rocks:4433 in de netwerkinspectiemodus tonen de ontwikkelaarstools HTTP/3-activiteit als "http/2+quic/99".

Bedenk dat het protocol QUIC (Quick UDP Internet Connections) is sinds 2013 door Google ontwikkeld als alternatief voor TCP + TLS voor het web, waardoor problemen met lange installatie- en onderhandelingstijden voor verbindingen in TCP worden opgelost en vertragingen in geval van pakketverlies tijdens gegevensoverdracht worden geëlimineerd. QUIC is een add-on voor het UDP-protocol dat multiplexing van meerdere verbindingen ondersteunt en versleutelingsmethoden biedt die gelijkwaardig zijn aan TLS/SSL. Het betreffende protocol is al geïntegreerd in de serverinfrastructuur van Google, maakt deel uit van Chrome, gepland voor opname in Firefox en wordt actief gebruikt om klantverzoeken op Google-servers te verwerken.

De belangrijkste kenmerken SNEL:

  • 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 direct een verbinding tot stand te brengen (0-RTT, in ongeveer 75% van de gevallen kunnen gegevens direct worden verzonden na het verzenden van een verbindingssetuppakket) en zorgen voor minimale vertragingen tussen het verzenden van een verzoek en het ontvangen van een antwoord (RTT, Round Trip Time) ;
  • Gebruik niet hetzelfde volgnummer bij het opnieuw verzenden van een pakket, waardoor u dubbelzinnigheid bij het bepalen van de ontvangen pakketten kunt voorkomen en time-outs kunt verwijderen;
  • 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 pakketverlies op het decoderen van de inhoud van de 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;
  • Waarneembaar groei prestaties en doorvoer in vergelijking met TCP. Voor videoservices zoals YouTube is aangetoond dat QUIC het opnieuw bufferen van video's met 30% vermindert.

Bron: opennet.ru

Voeg een reactie