IETF (Internet Engineering Task Force), som er ansvarlig for utviklingen av Internett-protokoller og arkitektur, har fullført dannelsen av en RFC for HTTP/3.0-protokollen og publisert relaterte spesifikasjoner under identifikatorene RFC 9114 (protokoll) og RFC 9204 ( QPACK header komprimeringsteknologi for HTTP/3) . HTTP/3.0-spesifikasjonen har fått status som «Proposed Standard», hvoretter arbeidet vil starte 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. Samtidig ble oppdaterte versjoner av spesifikasjonene for HTTP/1.1 (RFC 9112) og HTTP/2.0 (RFC 9113) protokollene publisert, samt dokumenter som definerer semantikken til HTTP-forespørsler (RFC 9110) og HTTP-bufringskontrollhoder (RFC 9111).
HTTP/3-protokollen definerer bruken av QUIC (Quick UDP Internet Connections)-protokollen som en transport for HTTP/2. QUIC er en utvidelse av 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-kombinasjonen for nettet, og løser problemer med lange tilkoblingsoppsett og forhandlingstider i TCP og eliminerer forsinkelser når pakker går tapt under dataoverføring.
For øyeblikket er QUIC og HTTP/3.0-støtte allerede implementert i alle populære nettlesere (i Chrome, Firefox og Edge er HTTP/3-støtte aktivert som standard, og i Safari krever det innstillingen "Avansert > Eksperimentelle funksjoner > HTTP/3" skal aktiveres). På serversiden er HTTP/3-implementeringer tilgjengelig for nginx (i en egen gren og i form av en egen modul), Caddy, IIS og LiteSpeed. HTTP/3-støtte er også levert av Cloudflare innholdsleveringsnettverk.
Nøkkelfunksjoner til QUIC:
- Høy sikkerhet som ligner på TLS (i hovedsak gir QUIC muligheten til å bruke TLS over UDP);
- Flytintegritetskontroll, forhindrer pakketap;
- Muligheten til å umiddelbart opprette en forbindelse (0-RTT, i omtrent 75 % av tilfellene kan data overføres umiddelbart etter sending av tilkoblingsoppsettpakken) og gir minimale forsinkelser mellom sending av en forespørsel og mottak av svar (RTT, Round Trip Time);
- Bruk av et annet sekvensnummer når du sender en pakke på nytt, noe som unngår tvetydighet i å identifisere mottatte pakker og eliminerer tidsavbrudd;
- Tap av en pakke påvirker bare leveringen av strømmen knyttet til den og stopper ikke leveringen av data i parallelle strømmer som overføres gjennom den gjeldende forbindelsen;
- Feilrettingsfunksjoner 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 justert med QUIC-pakkegrenser, noe som reduserer effekten av pakketap på dekoding av innholdet i påfølgende pakker;
- Ingen problemer med blokkering av TCP-kø;
- Støtte for tilkoblingsidentifikator, som reduserer tiden det tar å etablere en ny tilkobling for mobilklienter;
- Mulighet for å koble til avanserte mekanismer for kontroll av overbelastning;
- Bruker prognoseteknikker per retning for å sikre at pakker sendes med optimale hastigheter, og forhindrer at de blir overbelastet og forårsaker pakketap;
- Betydelig økning i ytelse og gjennomstrømning sammenlignet med TCP. For videotjenester som YouTube, har QUIC vist seg å redusere tilbakestillingsoperasjoner når du ser på videoer med 30 %.
Blant endringene i HTTP/1.1-spesifikasjonen kan man merke seg forbudet mot isolert bruk av vognretur (CR)-tegnet utenfor kroppen med innhold, dvs. I protokollelementer kan CR-tegnet bare brukes sammen med linjeskifttegnet (CRLF). Algoritmen for chunked request layout er forbedret for å forenkle separasjonen av vedlagte felt og seksjoner med overskrifter. Lagt til anbefalinger for håndtering av tvetydig innhold for å blokkere «HTTP Request Smuggling»-angrep, som lar oss kile oss inn i innholdet i andre brukeres forespørsler i flyten mellom frontend og backend.
HTTP/2.0-spesifikasjonsoppdateringen definerer eksplisitt støtte for TLS 1.3. Avviklet prioriteringsskjemaet og tilhørende overskriftsfelt. Den ubrukte mekanismen for å oppdatere forbindelsen med HTTP/1.1 har blitt erklært foreldet. Reduserte krav til kontroll av feltnavn og verdier. Noen tidligere reserverte rammetyper og parametere foreslås brukt. De forbudte overskriftsfeltene knyttet til forbindelsen er mer presist definert.
Kilde: opennet.ru