Introduksjon
HTTP / 2 er den siste revisjonen av Hypertext Transfer Protocol eller HTTP [01], som brukes av nettlesere til å kommunisere med webservere. Avledet fra den eldre SPDY [02] protokoll, er HTTP / 2 den første nye versjonen av HTTP siden standardiseringen av HTTP / 1.1 i RFC 2068 i 1997.
Den ble utviklet av Internet Engineering Task Force (IETF) HTTP arbeidsgruppe httpbis (der "bis" betyr "to ganger"), og publisert som RFC 7540 [03] mai 2015.
HTTP / 2 adopsjon
HTTP / 2 har blitt stadig mer adoptert av fungerende nettsteder siden den offisielle publiseringen. Den elektroniske undersøkelsestjenesten W3Techs [04] bemerker at fra september 2017 til september 2018 økte HTTP / 2-støtten fra 16% til 30% av alle overvåkede nettsteder.
Videre gir store nettlesere (f.eks. Chrome, Firefox, Edge, etc) allerede full støtte for HTTP / 2 [05]. (Noen utviklet til og med eksperimentelle implementeringer før HTTP / 2 ble akseptert som standard.)
Denne utbredte adopsjonen betyr at HTTP / 2 har potensial til å bli de de facto kommunikasjonsprotokoller på nettet.
Motivasjon bak HTTP / 2
Httpbis' charter [06] nevner flere komponenter i HTTP / 1.1 som kan forbedres som motivasjon for HTTP / 2. Gruppens hovedmål var imidlertid å redusere ventetiden som oppfattes av sluttbrukeren.
Å gjøre dette, httpbis vurderte å minimere båndbredde overhead via headerkomprimering og aggressive forhåndshentingsteknikker (f.eks. server push), samtidig som du prøver å systematisk løse kjente ytelsesproblemer som tilkoblingsstopping og Head-of-Line (HoL) -blokkeringsproblemet [07].
Dessuten ble HTTP / 2 pålagt å være bakoverkompatible, noe som betyr at den måtte bruke samme metode verb, statuskoder, URIs og (de fleste) overskriftfelter som finnes i HTTP / 1.1. HTTP / 2 måtte også være designet for å støtte vanlige HTTP-brukstilfeller, for eksempel nettlesere på stasjonære og mobile nettsteder, programmeringsgrensesnitt, proxy og brannmurer.
For å opprettholde denne kompatibiliteten utviklet arbeidsgruppen en protokollforhandlingsmekanisme som lar klienter og servere velge mellom HTTP / 1.1, HTTP / 2 eller til og med ikke-HTTP-protokoller.
Så hva er nytt i HTTP / 2?
HTTP / 2 bruker fortsatt de samme URI-ordningene og portnumrene som ble brukt i HTTP / 1.1 (dvs. port 80 for http URI-er, og port 443 for https URI-er), men mange ting gjøres annerledes under panseret.
Den mest grunnleggende endringen er innføringen av rammer som grunnleggende dataenhet for HTTP / 2.
HTTP / 1.1 bruker tradisjonelt pakker å representere nettverksdata. En klient konstruerer en forespørselspakke med et metod verb (f.eks GET or POST), ved å legge til en liste med overskrifter som beskriver forbindelsen, og et organ som inneholder applikasjonsdata.
Når du mottar en forespørselspakke, svarer en HTTP / 1.1-server med en lignende responspakke som inneholder den forespurte informasjonen. Som et resultat krever hver forespørsel og svarssyklus en ny tilkobling.
Omvendt oppretter HTTP / 2-klienter en enkelt nettverkstilkobling med serveren, som de bruker for all påfølgende nettverkskommunikasjon. Overskrifter, brukerdata, feilmeldinger og all slik informasjon pakkes inn i distinkte binære datastrukturer kalt rammer, før de overføres over nettverket.
Dette virker som en liten endring, men det har betydelige implikasjoner.
Toppkomprimering
En stor fordel med å bruke rammer er at HTTP / 2-overskrifter pakkes i en HEADER ramme, som kan komprimeres ved bruk av normale komprimeringsmetoder. Overskrifter må overføres før data, så komprimering av topptekst kan redusere båndbredden overhead pålagt av HTTP / 2.
Toppkomprimering, sammen med følgende ytelser som forbedrer HTTP / 2-funksjoner, kan være spesielt nyttige i mobil- eller internet-ting-ting (IOT) -applikasjoner, der det kreves minimal nettverksbruk.
Strømmer og multipleksing
En uavhengig sekvens av semantisk relevante rammer kalles a stream. Strømmer tildeles en unik identifikator av sluttpunktet (dvs. klient eller server) som opprettet dem, slik at andre sluttpunkter kan skille mellom dem.
Endepunkter kan flette inn rammer fra flere strømmer over den samme HTTP / 2-tilkoblingen, slik at en enkelt nettverkstilkobling kan støtte flere åpne strømmer samtidig. Denne prosessen kalles multiplexing [08].
Å gjenbruke den samme tilkoblingen demper problemer som tilkoblingsstopp og HoL-problemet som er nevnt før, og gir bedre ytelse og jevnere brukeropplevelse enn tidligere HTTP-versjoner.
Strømavhengighet og prioritering
Å håndtere flere samtidige strømmer betyr at noen strømmer blir behandlet før andre. HTTP / 2 lar utvikleren (eller administratoren) finjustere denne oppførselen med en funksjon som heter strømavhengighet.
En strøm kan være avhengig av full overføring av en annen strøm før den blir håndtert. For eksempel, på et nettsted der hovedinnholdet på en webside skal lastes før noen anbefalinger for lignende innhold, lar HTTP / 2 anbefalingsstrømmen opprettes som avhengig av hovedinnholdsstrømmen.
HTTP / 2 støtter også strøm prioritering. Det vil si at hver strøm kan tildeles en prioritet for å foreslå hvor raskt endepunktene skal tildele ressurser til å håndtere strømens rammer.
Prioritering og strømavhengighet hjelper utviklere og eiere av nettsteder å optimalisere nettstedets nettverksbruk, noe som kan forbedre nettstedets brukeropplevelse betydelig.
Server Push
Til slutt kan HTTP / 2 forbedre ytelsen til et nettsted ved å tilby "push" -funksjonalitet. En HTTP / 2-webserver kan svare med data for flere spørsmål enn klienten opprinnelig har bedt om. Dette gjør at serveren kan levere data den vet at en nettleser trenger å gjengi en side uten å vente på at nettleseren skal undersøke det første svaret, og dermed uten overhead av en ekstra forespørselssyklus.
Server push gir utviklere full kontroll over antall forespørsler som kreves for at en nettleser skal gjengi sitt nettsted. Hvis den brukes riktig, kan denne funksjonen minimere nettverksomkostningene.
Naturlig kan misbruk av push-funksjonen også kaste bort mer båndbredde enn det som faktisk er nødvendig. Av denne grunn tillater HTTP / 2 en klient å be om at server push blir deaktivert når han først forhandler om en tilkobling.
HTTP / 2-sikkerhet
Hvis du har lest opp til dette punktet, bør det være klart at utviklerne av HTTP / 2 virkelig legger vekt på å forbedre ytelsen. Imidlertid bør det bemerkes at HTTP / 2 også kan bidra til å forbedre nettleserbrukernes sikkerhet generelt.
Mer spesifikt er HTTP / 2 definert for både HTTP URI (dvs. uten kryptering) og HTTPS URI (over TLS krypterte kanaler). Selv om standarden i seg selv ikke krever bruk av kryptering, er alle viktige nettleserimplementeringer (dvs. Firefox) [09], Chrome, Safari, Opera, IE, Edge) har bestemt at de vil gjøre det bare støtte HTTP / 2 over TLS.
Faktisk skiller nettlesere mellom klartekst HTTP / 2 og HTTP / 2 i forhold til kryptert TLS som to forskjellige protokoller. Kryptert HTTP / 2 heter h2 og klartekst h2c. Fra og med denne skrivingen støtter ingen av de store nettleserne h2c , Noe som betyr at TLS kryptering er obligatorisk for et nettsted å dra nytte av HTTP / 2s andre fordeler. Derfor, når HTTP / 2 blir standard nettverksprotokoll, vil eldre nettstedseiere som ennå ikke har oppgradert til SSL /TLS, vil være sterkt motivert for å endelig gjøre det.
konklusjonen
Utbredt bruk av HTTP / 2 vil føre til en ny og forbedret nett. Den er raskere, trenger mindre båndbredde og det hjelper nettsteder å holde seg sikre. Det er vanlig å bruke den generelle adopsjonen, slik at den generelle nettbrukeropplevelsen blir jevnere og tryggere.
Få et sertifikat i dag og bli med oss i fremtiden.
