nylig IETF (Internet Engineering Task Force), som utvikler protokollene og arkitekturen til Internett, gjort det kjent nyheten som fullførte dannelsen av RFC for HTTP/3.0-protokollen og publiserte de relaterte spesifikasjonene under identifikatorene RFC 9114 og RFC 9204.
HTTP/3.0-spesifikasjonen mottok statusen "Foreslått standard", hvoretter arbeidet vil begynne med å gi RFC status som et utkast til standard (Draft Standard), som faktisk betyr en fullstendig stabilisering av protokollen og tar hensyn til alle kommentarene som er gitt.
protokollen HTTP/3 definerer bruken av QUIC-protokollen (Raske UDP Internett-tilkoblinger) som transport for HTTP/2. QUIC er en plugin til UDP-protokollen som støtter multipleksing av flere tilkoblinger og gir krypteringsmetoder tilsvarende TLS/SSL.
Protokollen ble opprettet i 2013 av Google som et alternativ til TCP + TLS for nettet, løser problemet med lang tilkoblingsoppsett og forhandlingstid i TCP og eliminerer forsinkelser på grunn av pakketap under dataoverføring.
Tiden, QUIC og HTTP/3.0-støtte er allerede implementert i alle nettlesere populære nettsteder. På serversiden er implementeringer av HTTP/3 tilgjengelig for nginx (i egen gren og som egen modul), Caddy , IIS og LiteSpeed. HTTP/3 støttes også av Cloudflares Content Delivery Network.
Hovedtrekk ved QUIC:
- Høy sikkerhet, lik TLS (faktisk gir QUIC muligheten til å bruke TLS over UDP)
- Overføringsintegritetskontroll for å forhindre pakketap
- Muligheten til å opprette en forbindelse umiddelbart og sikre minimale forsinkelser mellom sending av en forespørsel og mottak av svar (RTT, rundturstid)
- Bruk et annet sekvensnummer når du sender en pakke på nytt, slik at du kan unngå tvetydighet når du bestemmer mottatte pakker og bli kvitt tidsavbrudd
- Å miste en pakke påvirker levering av bare strømmen som er tilknyttet den, og stopper ikke levering av data i strømmer som overføres parallelt over den nåværende tilkoblingen
- Feilrettingsverktøy som minimerer forsinkelser på grunn av reoverføring av tapte pakker. Bruk av spesielle feilrettingskoder på pakkenivå for å redusere situasjoner som krever reoverføring av tapte pakkedata.
- Kryptografiske blokkgrenser er på linje med QUIC-pakkegrenser, noe som reduserer effekten av pakketap på dekoding av innholdet i påfølgende pakker
- Ingen problemer med å blokkere TCP-køen
- Støtte for tilkoblingsidentifikasjon for å redusere gjentilkoblingstiden for mobile klienter
- Mulighet for tilkobling av avanserte mekanismer for koblingsoverbelastningskontroll
- Bruk båndbreddeprediksjonsteknikker i hver retning for å sikre optimale pakkevideresendingshastigheter, unngå overbelastningsforhold der pakker går tapt.
- Bemerkelsesverdig ytelse og ytelsesgevinster i forhold til TCP. For videotjenester som YouTube har QUIC vist seg å redusere videobufferoperasjoner med 30 %.
I tillegg til dette ble det også samtidig publisert oppdaterte versjoner av spesifikasjonene for HTTP/1.1 (RFC 9112) og HTTP/2.0 (RFC 9113) protokollene, samt dokumenter som definerer semantikken til HTTP-forespørsler (RFC) 9110). og HTTP-bufringskontrollhoder (RFC 9111).
Av endringene i spesifikasjonen HTTP/1.1, du kan merke forbudet fra særskilt bruk av returkarakteren (CR) utenfor kroppen med innholdet, dvs. i protokollelementer, kan CR-tegnet bare brukes sammen med det nye linjetegnet (CRLF).
El chunked request layout-algoritme har blitt forbedret for å forenkle separasjonen av vedlagte felt og seksjoner med overskrifter. Lagt til retningslinjer for håndtering av tvetydig innhold for å blokkere "HTTP Request Smuggling" klasseangrep som kan trenge inn på innholdet i andre brukeres forespørsler i flyten mellom frontend og backend.
En oppdatering til spesifikasjonen HTTP/2.0 definerer eksplisitt støtte for TLS 1.3, utdatert prioriteringsskjema og relaterte overskriftsfelt og oppdateringsmekanisme utdatert HTTP/1.1-tilkobling har blitt avviklet.
Til slutt, hvis du er interessert i å kunne vite mer om det, kan du se detaljene i følgende lenke.