Chrome voeg eksperimentele HTTP/3-ondersteuning by

Na eksperimentele bouwerk Chrome-Kanarie bygevoeg ondersteuning vir die HTTP/3-protokol, wat 'n byvoeging implementeer om HTTP-werking oor die QUIC-protokol te verseker. Die QUIC-protokol self is vyf jaar gelede by die blaaier gevoeg en is sedertdien gebruik om werk met Google-dienste te optimaliseer. Terselfdertyd het Google se weergawe van QUIC wat in Chrome gebruik word in sekere besonderhede verskil van die weergawe van spesifikasies IETF, maar die implementerings is nou gesinchroniseer.

HTTP/3 standaardiseer die gebruik van QUIC as 'n vervoer vir HTTP/2. Om HTTP/3 en die QUIC-opsie te aktiveer vanaf 23 konsepte IETF-spesifikasies vereis dat Chrome bekendgestel moet word met opsies "--enable-quic --quic-version=h3-23", waarna wanneer 'n toetswerf oopgemaak word vinnige.rotse:4433 in Netwerkinspeksiemodus sal die ontwikkelaarnutsgoed HTTP/3-aktiwiteit as "http/2+quic/99" wys.

Onthou dat die protokol QUIC (Quick UDP Internet Connections) is sedert 2013 deur Google ontwikkel as 'n alternatief vir TCP + TLS vir die web, wat probleme oplos met lang opstel- en onderhandelingstye vir verbindings in TCP en om vertragings in die geval van pakkieverlies tydens data-oordrag uit te skakel. QUIC is 'n byvoeging tot die UDP-protokol wat multipleksing van veelvuldige verbindings ondersteun en enkripsiemetodes bied gelykstaande aan TLS/SSL. Die betrokke protokol is reeds geïntegreer in die Google-bedienerinfrastruktuur, is deel van Chrome, beplan vir insluiting in Firefox en word aktief gebruik om kliëntversoeke op Google-bedieners te bedien.

Die belangrikste kenmerke SNEL:

  • Hoë sekuriteit, soortgelyk aan TLS (in werklikheid bied QUIC die vermoë om TLS oor UDP te gebruik);
  • Stroomintegriteitsbeheer om pakkieverlies te voorkom;
  • Die vermoë om onmiddellik 'n verbinding tot stand te bring (0-RTT, in ongeveer 75% van die gevalle, data kan onmiddellik versend word nadat 'n verbindingsopstelpakkie gestuur is) en verseker minimale vertragings tussen die stuur van 'n versoek en die ontvangs van 'n antwoord (RTT, Round Trip Time) ;
  • Moenie dieselfde volgordenommer gebruik wanneer 'n pakkie herversend word nie, wat jou toelaat om onduidelikheid te vermy in die bepaling van die ontvangde pakkies en ontslae te raak van time-outs;
  • Pakkieverlies beïnvloed slegs die aflewering van die stroom wat daarmee geassosieer word en stop nie die aflewering van data in strome wat parallel oor die huidige verbinding versend word nie;
  • Foutregstellingnutsgoed wat vertragings as gevolg van herversending van verlore pakkies verminder. Gebruik van spesiale foutkorreksiekodes op die pakkievlak om situasies te verminder wat heruitsending van verlore pakkiedata vereis.
  • Kriptografiese blokgrense is in lyn met QUIC-pakkiegrense, wat die impak van pakkieverlies op die dekodering van die inhoud van die volgende pakkies verminder;
  • Geen probleme met die blokkering van die TCP-tou nie;
  • Verbindings-ID-ondersteuning om heraansluitingstyd vir mobiele kliënte te verminder;
  • Moontlikheid om gevorderde meganismes vir verbinding oorlading beheer te koppel;
  • Die gebruik van bandwydte-voorspellingstegnieke in elke rigting om die optimale intensiteit van die stuur van pakkies te verseker, wat voorkom dat dit in 'n toestand van opeenhoping inrol, waarin daar 'n verlies aan pakkies is;
  • Waarneembaar groei werkverrigting en deurset in vergelyking met TCP. Vir videodienste soos YouTube, is daar getoon dat QUIC video-weerkaatsingsoperasies met 30% verminder.

Bron: opennet.ru

Voeg 'n opmerking