Introduktion
HTTP / 2 er den seneste revision af HyperText-overførselsprotokol eller HTTP [01], som bruges af browsere til at kommunikere med webservere. Afledt af den ældre SPDY [02] protokol, HTTP / 2 er den første nye version af HTTP siden standardiseringen af HTTP / 1.1 i RFC 2068 i 1997.
Det blev udviklet af Internet Engineering Task Force (IETF) HTTP-arbejdsgruppe httpbis (hvor "bis" betyder "to gange") og udgivet som RFC 7540 [03] maj 2015.
HTTP / 2-vedtagelse
HTTP / 2 er i stigende grad blevet vedtaget af arbejdswebsteder siden dets officielle offentliggørelse. Online-undersøgelsestjenesten W3Techs [04] bemærker, at HTTP / 2017-support fra september 2018 til september 2 steg fra 16% til 30% af alle overvågede websteder.
Desuden giver store browsere (f.eks. Chrome, Firefox, Edge osv.) Allerede fuld support til HTTP / 2 [05]. (Nogle udviklede endda eksperimentelle implementeringer, før HTTP / 2 blev accepteret som standard.)
Denne udbredte vedtagelse betyder, at HTTP / 2 har potentialet til at blive de facto kommunikationsprotokol på Internettet.
Motivation bag HTTP / 2
Httpbis' charter [06] nævner flere komponenter i HTTP / 1.1, der kunne forbedres som motivation for HTTP / 2. Gruppens primære mål var imidlertid at mindske den latens, der opfattes af slutbrugeren.
At gøre dette, httpbis overvejet at minimere båndbredde overhead via headerkomprimering og aggressiv forhåndsudtagningsteknikker (f.eks. server-push), samtidig med at man systematisk prøver at løse kendte ydelsesproblemer, som f.eks. forbindelse med overbelastning og HoL-spærringsproblemet [07].
Derudover blev HTTP / 2 påkrævet at være bagudkompatible, hvilket betyder, at det var nødvendigt at bruge samme metode verb, statuskoder, URI'er og (de fleste) header felter, der findes i HTTP / 1.1. HTTP / 2 skulle også være designet til at understøtte almindelige HTTP-brugssager, såsom desktop- og mobile webbrowsere, programmeringsgrænseflader, proxies og firewalls.
For at opretholde denne kompatibilitet udviklede arbejdsgruppen en protokolforhandlingsmekanisme, der giver klienter og servere mulighed for at vælge blandt HTTP / 1.1, HTTP / 2 eller endda ikke-HTTP-protokoller.
Så hvad er nyt i HTTP / 2?
HTTP / 2 bruger stadig de samme URI-skemaer og portnumre, der bruges i HTTP / 1.1 (dvs. port 80 til http URI'er og port 443 til https URI'er), men mange ting gøres anderledes under hætten.
Den mest grundlæggende ændring er introduktionen af rammer som den basale dataenhed for HTTP / 2.
HTTP / 1.1 bruger traditionelt pakker at repræsentere netværksdata. En klient konstruerer en anmodningspakke med et metodeverb (f.eks GET or POST), ved at tilføje en liste med overskrifter, der beskriver forbindelsen, og et organ, der indeholder applikationsdata.
Efter modtagelse af en anmodningspakke svarer en HTTP / 1.1-server med en lignende svarspakke, der indeholder den anmodede information. Som et resultat kræver hver anmodning og svarcyklus en ny forbindelse.
Omvendt opretter HTTP / 2-klienter en enkelt netværksforbindelse med serveren, som de bruger til al efterfølgende netværkskommunikation. Overskrifter, brugerdata, fejlmeddelelser og al sådan information pakkes i forskellige binære datastrukturer kaldet rammer, inden de overføres over netværket.
Dette virker som en lille ændring, men det har betydelige konsekvenser.
Header-komprimering
En stor fordel ved at bruge rammer er, at HTTP / 2-overskrifter er pakket i en HEADER ramme, som kan komprimeres ved hjælp af normale komprimeringsmetoder. Overskrifter skal overføres inden data, så headerkomprimering kan reducere båndbreddens overhead pålagt af HTTP / 2.
Header-komprimering sammen med følgende ydelse, der forbedrer HTTP / 2-funktioner, kan være særligt nyttige i mobil- eller internet-of-ting-applikationer (IOT) -applikationer, hvor der kræves minimal netværksbrug.
Streams og multiplexing
En uafhængig række af semantisk relevante rammer kaldes a strøm. Streams tildeles en unik identifikation af endepunktet (dvs. klient eller server), der oprettede dem, så andre slutpunkter kan skelne mellem dem.
Endepunkter kan sammenflette rammer fra flere streams over den samme HTTP / 2-forbindelse, så en enkelt netværksforbindelse understøtter flere samtidigt åbne streams. Denne proces kaldes multiplexing [08].
Genanvendelse af den samme forbindelse mindsker problemer såsom forbindelsesproblemer og HoL-problemet, der er nævnt før, og tilbyder bedre ydelse og glatere brugeroplevelse end tidligere HTTP-versioner.
Stream afhængighed og prioritering
Håndtering af flere samtidige strømme betyder, at nogle streams behandles før andre. HTTP / 2 giver udvikleren (eller administratoren) mulighed for at finjustere denne opførsel med en kaldet funktion strøm afhængighed.
En strøm kan afhænge af den komplette overførsel af en anden strøm, før den håndteres. F.eks. På et sted, hvor hovedindholdet på en webside skal indlæses, før eventuelle anbefalinger til lignende indhold, tillader HTTP / 2, at anbefalingsstrømmen oprettes som afhængig af hovedindholdsstrømmen.
HTTP / 2 understøtter også stream prioritering. Det vil sige, at hver stream kan tildeles en prioritet til at foreslå, hvor hurtigt slutpunkterne skal tildele ressourcer til at håndtere streamens rammer.
Prioritering og strømafhængighed hjælper udviklere og webstedsejere med at optimere deres websteds netværksbrug, hvilket kan forbedre deres websteds brugeroplevelse betydeligt.
Server push
Endelig kan HTTP / 2 forbedre et websteds ydeevne ved at give “push” -funktionalitet. En HTTP / 2-webserver kan svare med data for flere forespørgsler, end klienten oprindeligt har anmodet om. Dette gør det muligt for serveren at levere data, som den ved, at en webbrowser skal gengive en side uden at vente på, at browseren undersøger det første svar og dermed uden omkostningerne ved en yderligere anmodningscyklus.
Server push giver udviklere fuld kontrol over antallet af anmodninger, der kræves for at en browser skal gengive deres websted. Når den bruges korrekt, kan denne funktion minimere netværksomkostninger.
Naturligvis kan misbrug af push-funktionen også spilde mere båndbredde, end der faktisk er nødvendigt. Af denne grund tillader HTTP / 2 en klient at anmode om, at server-push deaktiveres, når der først forhandles om en forbindelse.
HTTP / 2-sikkerhed
Hvis du har læst op til dette punkt, bør det være klart, at udviklerne af HTTP / 2 virkelig lægger vægt på at forbedre ydeevnen. Det skal dog bemærkes, at HTTP / 2 også kan hjælpe med at forbedre browserbrugernes sikkerhed generelt.
Mere specifikt er HTTP / 2 defineret for både HTTP URI'er (dvs. uden kryptering) og HTTPS URI'er (over TLS krypterede kanaler). Selvom standarden i sig selv ikke kræver brug af kryptering, er alle større browserimplementeringer (dvs. Firefox) [09], Chrome, Safari, Opera, IE, Edge) har besluttet, at de vil kun understøtt HTTP / 2 over TLS.
Faktisk skelner browsere mellem klartekst HTTP / 2 og HTTP / 2 i forhold til krypteret TLS som to forskellige protokoller. Krypteret HTTP / 2 kaldes h2 og klartekst h2c. Fra denne skrivning understøtter ingen af de store browsere h2c , Hvilket betyder, at TLS kryptering er obligatorisk for et websted at drage fordel af HTTP / 2's andre fordele. Derfor, når HTTP / 2 bliver standardwebnetværksprotokol, er ældre webstedsejere, der endnu ikke er opgraderet til SSL /TLS, vil være stærkt motiverede til endelig at gøre det.
Konklusion
Udbredt vedtagelse af HTTP / 2 vil medføre et nyt og forbedret web. Det er hurtigere, har brug for mindre båndbredde, og det hjælper websteder med at forblive sikre. Dens mainstream-vedtagelse er sikker på at gøre den samlede webbrugeroplevelse glattere og sikrere.
Få et certifikat i dag, og vær med i fremtiden.
