en English
X

Select Language

Powered by Google TranslateTranslate

We hope you will find the Google translation service helpful, but we don’t promise that Google’s translation will be accurate or complete. You should not rely on Google’s translation. English is the official language of our site.

en English
X

Select Language

Powered by Google TranslateTranslate

We hope you will find the Google translation service helpful, but we don’t promise that Google’s translation will be accurate or complete. You should not rely on Google’s translation. English is the official language of our site.

En introduktion till HTTP / 2

Beskrivning

HTTP / 2 är den senaste revisionen av HyperText-överföringsprotokoll eller HTTP [01], som används av webbläsare för att kommunicera med webbservrar. Härledd från den äldre SPDY [02] protokollet, HTTP / 2 är den första nya versionen av HTTP sedan standardiseringen av HTTP / 1.1 i RFC 2068 1997.

Det utvecklades av Internet Engineering Task Force (IETF) HTTP-arbetsgrupp httpbis (där "bis" betyder "två gånger") och publiceras som RFC 7540 [03] Maj 2015.

HTTP / 2-antagande

HTTP / 2 har alltmer antagits av fungerande webbplatser sedan dess officiella publicering. Onlinetjänsten W3Techs [04] noterar att HTTP / 2017-stöd från september 2018 till september 2 ökade från 16% till 30% av alla övervakade webbplatser.

Dessutom ger stora webbläsare (t.ex. Chrome, Firefox, Edge, etc.) redan fullt stöd för HTTP / 2 [05]. (Vissa utvecklade till och med experimentella implementationer innan HTTP / 2 accepterades som standard.)

Denna utbredda adoption innebär att HTTP / 2 har potential att bli de facto-kommunikationsprotokollet på webben.

Motivation bakom HTTP / 2

Httpbisstadga [06] nämner flera komponenter i HTTP / 1.1 som kan förbättras som motivation för HTTP / 2. Gruppens primära mål var dock att minska den latens som slutanvändaren upplevde.

Att göra detta, httpbis övervägde att minimera bandbreddskostnader via headerkomprimering och aggressiva förhämtningstekniker (t.ex. server push), samtidigt som man försöker systematiskt ta itu med kända prestandafrågor som anslutningstävling och HoL-blockeringsproblem (HoL) [07].

Dessutom krävdes att HTTP / 2 var bakåtkompatibla, vilket innebar att den måste använda samma metodverb, statuskoder, URI och (de flesta) rubrikfält som finns i HTTP / 1.1. HTTP / 2 måste också utformas för att stödja vanliga HTTP-användningsfall, till exempel webbläsare för stationära och mobila webbläsare, programmeringsgränssnitt, proxyer och brandväggar.

För att bibehålla denna kompatibilitet utvecklade arbetsgruppen en protokollförhandlingsmekanism som skulle göra det möjligt för klienter och servrar att välja bland HTTP / 1.1, HTTP / 2 eller till och med icke-HTTP-protokoll.

Så vad är nytt i HTTP / 2?

HTTP / 2 använder fortfarande samma URI-scheman och portnummer som används i HTTP / 1.1 (dvs. port 80 för http URI: er och port 443 för https URI: er), men många saker görs annorlunda under huven.

Den mest grundläggande förändringen är införandet av ramar som basdataenhet för HTTP / 2.

HTTP / 1.1 använder traditionellt paket för att representera nätverksdata. En klient konstruerar ett förfrågningspaket med ett metodverb (t.ex. GET or POST), lägg till en lista med rubriker som beskriver anslutningen och ett organ som innehåller applikationsdata.

Vid mottagning av ett förfrågningspaket svarar en HTTP / 1.1-server med ett liknande svarspaket som innehåller den begärda informationen. Som ett resultat kräver varje begäran och svarscykel en ny anslutning.

Omvänt skapar HTTP / 2-klienter en enda nätverksanslutning med servern, som de använder för all efterföljande nätverkskommunikation. Rubriker, användardata, felmeddelanden och all sådan information packas i distinkta binära datastrukturer som kallas ramar innan de överförs över nätverket.

Detta verkar som en liten förändring, men det har betydande konsekvenser.

Sidhuvudkomprimering

En stor fördel med att använda ramar är att HTTP / 2-rubriker är packade i en HEADER ram, som kan komprimeras med vanliga komprimeringsmetoder. Rubriker måste överföras före data, så att komprimering av rubriker kan minska bandbreddens overhead som HTTP / 2 sätter på.

Header-komprimering, tillsammans med följande prestanda som förbättrar HTTP / 2-funktioner, kan vara särskilt användbara i mobil- eller internet-of-ting-applikationer (IOT), där minimal nätverksanvändning krävs.

Strömmar och multiplexering

En oberoende sekvens av semantiskt relevanta ramar kallas a ström. Strömmar tilldelas en unik identifierare av slutpunkten (dvs. klient eller server) som skapade dem, så att andra slutpunkter kan skilja mellan dem.

Endpoints kan sammanfoga ramar från flera strömmar över samma HTTP / 2-anslutning, vilket gör att en enda nätverksanslutning kan stödja flera samtidigt öppna strömmar. Denna process kallas multiplexering [08].

Återanvändning av samma anslutning minskar problem som anslutningstävling och HoL-problemet som nämnts tidigare och erbjuder bättre prestanda och mjukare användarupplevelse än tidigare HTTP-versioner.

Strömavhängighet och prioritering

Att hantera flera samtidiga strömmar innebär att vissa strömmar behandlas före andra. HTTP / 2 gör det möjligt för utvecklaren (eller administratören) att finjustera detta beteende med en funktion som heter strömberoende.

En ström kan bero på fullständig överföring av en annan ström innan den hanteras. Till exempel på en webbplats där huvudinnehållet på en webbsida bör laddas innan några rekommendationer för liknande innehåll tillåter HTTP / 2 att rekommendationsströmmen skapas beroende på huvudinnehållsströmmen.

HTTP / 2 stöder också strömprioritering. Det vill säga att varje ström kan tilldelas en prioritet för att föreslå hur snabbt slutpunkterna ska tilldela resurser för att hantera strömens ramar.

Prioritering och strömberoende hjälper utvecklare och webbplatsägare att optimera webbplatsens nätverksanvändning, vilket kan förbättra webbplatsens användarupplevelse avsevärt.

server Push

Slutligen kan HTTP / 2 förbättra webbplatsens prestanda genom att tillhandahålla "push" -funktionalitet. En HTTP / 2-webbserver kan svara med data för fler frågor än klienten ursprungligen begärde. Detta gör det möjligt för servern att leverera data som den vet att en webbläsare kommer att behöva göra en sida utan att vänta på att webbläsaren ska undersöka det första svaret och därmed utan en extra begärandecykel.

Server push ger utvecklarna full kontroll över antalet förfrågningar som krävs för att en webbläsare ska göra sin webbplats. Om den används korrekt kan den här funktionen minimera nätverksomkostnader.

Naturligtvis kan missbruk av push-funktionen också slösa mer bandbredd än vad som faktiskt är nödvändigt. Av detta skäl tillåter HTTP / 2 en klient att begära att server push inaktiveras när man först förhandlar om en anslutning.

HTTP / 2-säkerhet

Om du har läst till denna punkt bör det vara tydligt att utvecklarna av HTTP / 2 verkligen satsar på att förbättra prestanda. Det bör dock noteras att HTTP / 2 också kan bidra till att förbättra webbläsaranvändarnas säkerhet totalt sett.

Mer specifikt definieras HTTP / 2 för både HTTP URI: er (utan kryptering) och HTTPS URI: er ( TLS krypterade kanaler). Även om standarden inte kräver användning av kryptering, är alla större webbläsarimplementeringar (dvs. Firefox) [09], Chrome, Safari, Opera, IE, Edge) har beslutat att de kommer att göra det endast stödja HTTP / 2 över TLS.

Faktum är att webbläsare skiljer mellan klartekst HTTP / 2 och HTTP / 2 jämfört med krypterade TLS som två olika protokoll. Krypterad HTTP / 2 heter h2 och tydlig text h2c. Från detta skrivande stöder ingen av de stora webbläsarna h2c , Vilket innebär att TLS kryptering är obligatoriskt för en webbplats att dra nytta av HTTP / 2: s andra fördelar. Därför, när HTTP / 2 blir standardnätverksprotokollet, äldre webbplatsägare som ännu inte har uppgraderat till SSL /TLS, kommer att vara starkt motiverade att äntligen göra det.

Slutsats

Ett utbrett antagande av HTTP / 2 kommer att leda till en ny och förbättrad webb. Det är snabbare, behöver mindre bandbredd och det hjälper webbplatser att hålla sig säkra. Dess mainstream-antagande kommer säkert att göra den totala användarupplevelsen på webben smidigare och säkrare.

Få ett certifikat idag och gå med oss ​​i framtiden.

referenser

  1. HTTP-protokoll
  2. SPDY-protokoll
  3. HTTP / 2-specifikation
  4. W3Techs HTTP / 2-adoptionsundersökning
  5. HTTP / 2-antagande i webbläsare
  6. httpbis stadga
  7. HOL-blockering
  8. multiplexering
  9. Firefox på HTTP / 2

Relaterade artiklar

Prenumerera på SSL.coms nyhetsbrev

Vad är SSL /TLS?

Spela filmen

Prenumerera på SSL.coms nyhetsbrev

Missa inte nya artiklar och uppdateringar från SSL.com