Nästan allt du besöker på webben på ett eller annat sätt använder ett speciellt protokoll som kallas Hyptertext Transfer Protocol (HTTP). Ända sedan år 1999 har du använt HTTP-version 1.1. Detta har varit den pågående standarden i många år tills Google gjorde ett tillkännagivande den 10 februari 2015 att dess webbläsare kommer att lägga till fullt stöd för det som nu är känt som HTTP / 2. Det här låter som helt gibberiskt för vissa, men det beror på att det inte finns någon beskrivning av vad HTTP / 2 gör annorlunda. För att förstå detta måste vi utforska exakt vad den här nya protokollversionen gör och hur den liknar den version av HTTP som vi har använt i nästan två decennier.

Vad uppnår HTTP / 2?

När en ny protokollversion är utvecklad behöver den konkreta konkreta mål. Det uppenbara målet är bakåtkompatibelt med föregångaren HTTP 1.1. Utan den förmågan måste varje server i världen växla till HTTP / 2 för att kunna bläddra i sina webbplatser.

Medan det nya protokollet upprätthåller kompatibilitet med den äldre versionen kommer det att utnyttjas av avancerade tekniker som åtgärder mot latens, vilket gör att sidor laddas snabbare. Detta är det primära målet, det problem som HTTP / 2 planerar att hantera mest aggressivt.

Andra förbättringar inkluderar ökad säkerhet och kompatibilitet med omvända fullmakter.

I det stora schemat av saker kommer HTTP / 2 inte att vara så mycket annorlunda än HTTP 1.1. När du surfar på internet är den starkaste effekten du kommer att känna att webbsidor laddas betydligt snabbare så länge de stöder den nya versionen.

Hur gör HTTP / 2 på webben snabbare?

Att säga att "HTTP / 2 gör allt snabbare" är en missnöje till den mängd arbete som faktiskt sker bakom kulisserna för att uppnå detta. HTTP 1.1-protokollet löser sig med en serie frågor som var acceptabla under de första åren av det 21: a århundradet men inte längre meningsfullt att fortsätta att leva med i en tid där bandbredd är billigare och servrarna förväntas ladda sidor med mycket snabbare priser .

Det huvudsakliga sättet att HTTP / 2 planerar att adressera sidhämtningstider är att komprimera rubriken (en del data som skickas av din klient för att begära att en server ger dig uppgifterna på en webbsida du besöker). Detta minimerar den tid som datorn "skakar hand" med destinationsservern genom att minska mängden data som ska skickas. Numera är processorer kraftfulla för att hantera miljontals dekompressioner på kort tid. Det är mer meningsfullt att göra detta nu.

Medan ovanstående endast tar hand om latensen i den ursprungliga begäran finns det också sätt att HTTP / 2 planerar att ta hand om hela din interaktion med en webbplats. Det kommer att direkt implementera serverns push-teknik, vilket gör det möjligt för servrar att vara mer aktiva i kommunikationsprocessen. Fram till nyligen måste du skicka förfrågningar regelbundet till servern, vilket tolkar de rubriker du churn ut varje gång du begär information. Med HTTP / 2 skickar servern dig nya data när den visas.

Slutligen kommer HTTP / 2 att göra något som heter "multiplexing" när du skickar förfrågningar. I HTTP 1.1 var ett problem: Varje nytt paket hade företräde framför den sista. Alla av dem bearbetades linjärt, vilket ledde till ett problem som kallades "blockblockering". I grund och botten begränsades en servers prestanda av det faktum att det skulle behöva behandla det första paketet som kommer till det medan de lämnar resten i en kö. Om paketet tog lång tid att bearbeta, måste alla andra paket vänta i raden för sin tur. Med HTTP / 2 behandlas flera paket samtidigt.

Med denna kombination av olika "botemedel" kommer HTTP / 2 att göra allt för att undvika avbrott på grund av HTTP-specifika problem. Detta kommer att vara särskilt fördelaktigt för webbplatser med mindre servrar som inte är kopplade till så mycket bandbredd som de som kör Facebook och Google.

Om du har frågor eller idéer, var noga med att lämna en kommentar med dina tankar!