Die IETF (Internet Engineering Task Force), wat verantwoordelik is vir die ontwikkeling van internetprotokolle en argitektuur, het die vorming van 'n RFC vir die HTTP/3.0-protokol voltooi en verwante spesifikasies gepubliseer onder die identifiseerders RFC 9114 (protokol) en RFC 9204 ( QPACK koptekst kompressie tegnologie vir HTTP/3) . Die HTTP/3.0-spesifikasie het die status van 'n "Voorgestelde Standaard" ontvang, waarna werk sal begin om die RFC die status van 'n konsepstandaard (Draft Standard) te gee, wat eintlik 'n volledige stabilisering van die protokol beteken en met inagneming van alle die opmerkings wat gemaak is. Terselfdertyd is opgedateerde weergawes van die spesifikasies vir die HTTP/1.1 (RFC 9112) en HTTP/2.0 (RFC 9113) protokolle gepubliseer, sowel as dokumente wat die semantiek van HTTP-versoeke (RFC 9110) en HTTP-kasbeheeropskrifte definieer (RFC 9111).
Die HTTP/3-protokol definieer die gebruik van die QUIC (Quick UDP Internet Connections) protokol as 'n vervoer vir HTTP/2. QUIC is 'n uitbreiding van die UDP-protokol wat multipleksing van veelvuldige verbindings ondersteun en enkripsiemetodes bied gelykstaande aan TLS/SSL. Die protokol is in 2013 deur Google geskep as 'n alternatief vir die TCP+TLS-kombinasie vir die web, wat probleme met lang verbinding-opstelling en onderhandelingstye in TCP oplos en vertragings uitskakel wanneer pakkies tydens data-oordrag verlore gaan.
Tans is QUIC- en HTTP/3.0-ondersteuning reeds in alle gewilde webblaaiers geïmplementeer (in Chrome, Firefox en Edge is HTTP/3-ondersteuning by verstek geaktiveer, en in Safari vereis dit die "Gevorderde > Eksperimentele kenmerke > HTTP/3"-instelling geaktiveer te word). Aan die bedienerkant is HTTP/3-implementerings beskikbaar vir nginx (in 'n aparte tak en in die vorm van 'n aparte module), Caddy, IIS en LiteSpeed. HTTP/3-ondersteuning word ook verskaf deur die Cloudflare-inhoudafleweringsnetwerk.
Sleutel kenmerke van QUIC:
- 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 te bewerkstellig (0-RTT, in ongeveer 75% van die gevalle kan data onmiddellik versend word nadat die konneksie-opstellingpakket gestuur is) en minimale vertragings verskaf tussen die stuur van 'n versoek en die ontvangs van 'n antwoord (RTT, Round Trip Time);
- Die gebruik van 'n ander volgordenommer wanneer 'n pakkie herversend word, wat onduidelikheid in die identifisering van ontvangde pakkies vermy en ontslae 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;
- Aansienlike toename in werkverrigting en deurset in vergelyking met TCP. Vir videodienste soos YouTube, is daar getoon dat QUIC die terugstootbewerkings met 30% verminder wanneer na video's gekyk word.
Onder die veranderinge in die HTTP/1.1-spesifikasie kan 'n mens let op die verbod op die geïsoleerde gebruik van die koetsretur (CR) karakter buite die liggaam met inhoud, d.w.s. In protokolelemente kan die CR-karakter slegs saam met die lynvoerkarakter (CRLF) gebruik word. Die algoritme vir gebroke versoekuitleg is verbeter om die skeiding van aangehegte velde en afdelings met opskrifte te vereenvoudig. Bygevoeg aanbevelings vir die hantering van dubbelsinnige inhoud om "HTTP Request Smuggling"-aanvalle te blokkeer, wat ons in staat stel om onsself in die inhoud van ander gebruikers se versoeke in die vloei tussen die frontend en backend te wig.
Die HTTP/2.0-spesifikasie-opdatering definieer uitdruklik ondersteuning vir TLS 1.3. Het die prioritiseringskema en gepaardgaande opskrifvelde opgeskort. Die ongebruikte meganisme vir die opdatering van die verbinding met HTTP/1.1 is verouderd verklaar. Verminderde vereistes vir die nagaan van veldname en waardes. Sommige voorheen gereserveerde raamtipes en parameters word vir gebruik voorgestel. Die verbode opskrifvelde wat met die verbinding verband hou, word meer presies gedefinieer.
Bron: opennet.ru