Firefox nightly builds ondersteun nou HTTP/3

В nagtelike bouwerk Firefox, wat die basis sal vorm vir die vrystelling van Firefox 72, geskeduleer vir 7 Januarie, bygevoeg HTTP/3 protokol ondersteuning. By verstek is HTTP/3 gedeaktiveer en vereis dat die "network.http.http3.enabled" opsie geaktiveer word in about:config.

HTTP/3-ondersteuning in Firefox is gebaseer op 'n projek wat deur Mozilla ontwikkel is nie, wat 'n kliënt- en bedienerimplementering vir die QUIC-protokol verskaf. Die komponentkode vir HTTP/3- en QUIC-ondersteuning is in Rust geskryf.
Van kliëntsagteware is eksperimentele ondersteuning vir HTTP/3 ook reeds bygevoeg in Chrome en krul, en vir bedieners is dit beskikbaar in die vorm модуля vir nginx en toets bediener biblioteek gebaseer quiche (implementering QUIC en HTTP/3 in Rust van Cloudflare). Om die werking van HTTP/3-kliënte te toets van stapel gestuur verskeie toetswebwerwe, waarvan die meeste nog nie korrek in Firefox oopmaak nie (HTTP/3 is in die stadium konsepspesifikasie en is nie heeltemal gestandaardiseer nie).

Onthou dat HTTP/3 die gebruik van die QUIC-protokol as 'n vervoer vir HTTP/2 standaardiseer. 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 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.
• Die grense van die kriptografiese blokke is in lyn met die grense van die QUIC-pakkies, 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