Det kan ibland tyckas att utvecklingen av tekniker och protokoll på låg nivå för webben rör sig långsamt. I alla fall om vi bortser från den rasande takten med vilken Javascript-ramverk blir till och överges till förmån för den här veckans nya, heta ramverk.
För att ta ett exempel från webbens underliggande tekniker så används fortfarande HTTP 1.1, ett protokoll som fastställdes som en internationell standard av HTTP Working Group 1997. Det protokollet, liksom många andra vanliga webbtekniker, har fungerat bra under många år, men det har inte hindrat såväl företag som forskare från att experimentera med nya tekniker i jakt efter förbättringar.
HTTP/2
Ursprungligen bestod webbsidor nästan uteslutande av statiska sidor bestående av text och bilder som länkade till varandra. I dag blandar webbsidorna ofta olika former av media och hämtar innehåll från olika källor och vid olika tillfällen. Det har gjort att HTTP1.1-protokollet blivit mer och mer av en flaskhals ur prestandasynpunkt. En mängd olika projekt och tekniker har genom årens lopp tagits fram i syfte att arbeta runt många av dessa problem. Det är mot bakgrund av detta som arbetet på en ny version av protokollet påbörjades, rätt och slätt döpt till HTTP/2.
Tre av målen med den nya versionen av protokollet var att lägga till stöd för header-komprimering, server push och multiplexing.
Header-komprimering innebär att HTTP-paketens headers komprimeras med en komprimeringsalgoritm vid namn HPACK. Tidigare komprimerades främst HTTP-paketens innehåll, exempelvis med komprimeringstekniker som GZIP eller Deflate.
Server push eller Server initiated push (SSI) innebär att webbservrar kan skicka till klienter efter endast ett begynnande anrop. Detta gör att klienten slipper göra ytterligare rundturer till servern för att ta emot ny data.
Multiplexing, ibland även kallat pipelining, innebär att klient och server bibehåller samma anslutning för flera transaktioner istället för att upprätta många olika anslutningar för varje överföring som måste göras.
Den nuvarande standarden för HTTP/2 är även utformad så att den nya versionen av protokollet är bakåtkompatibel med HTTP 1.1, vilket förenklar migration av kod som är byggd enligt den gamla standarden. Stora delar av HTTP/2-standarden bygger på en tidigare standard vid namn SPDY som togs fram av Google, innan IETF valde att införliva arbetet på SPDY i HTTP/2 standarden.
På klientsidan har standarden fått fäste och idag har Firefox, Chrome, Internet Explorer 11, Edge och Safari stöd för HTTP/2. På serversidan har det gått långsammare: I Javavärlden har både Tomcat och Jetty stöd för HTTP/2 och Googles Go har stöd för protokollet i sitt standardbibliotek. När det gäller Python och Nodejs pågår arbetet med att implementera protokollet i såväl standardbibliotek som i tredjepartsbibliotek.
Fokuset för HTTP/2 har till mycket stor del varit att förbättra prestandan, bland annat genom att anpassa metoderna med vilka protokollet hanterar trafik för att passa moderna webbapplikationers trafikmönster. Om du utvecklar webbapplikationer som skickar stora mängder data i små delar till webbläsare, om du vill använda server push tekniken eller om du använder HTTP för att kommunicera mellan mikrotjänster så kan det mycket väl vara värt att läsa på om de nya verktygen som HTTP/2 bidrar med.
QUIC
QUIC, eller Quick UDP Internet Connections, är ett experimentellt protokoll under utveckling hos Google. Syftet med QUIC i likhet med HTTP/2 är att förbättra prestandan för kommunikation på webben. Angreppssättet skaparna valt för detta är att minska det relativt höga antal roundtrips (dvs att klient och server skickar en serie frågor och svar, exempelvis vid upprättandet en TCP anslutning) som det i HTTP underliggande TCP-protokollet kräver vid kommunikation samt att möjliggöra multiplexing (att låta en anslutning skicka och ta emot flera anrop och svar). Anledningen att man valt att skapa ett nytt protokoll vid sidan om HTTP/2 är enligt skaparna för att de ändringar på TCP som skulle krävas för uppnå prestandamålen kräver ändringar på nätverksteknikerna på operativsystemsnivå, något som sker med relativt låg takt.
Som namnet antyder ämnar QUIC att uppnå sina mål genom att ersätta TCP med UDP för kommunikation men samtidigt också kombinera UDP-protokollet med en mängd olika tekniker för felkorrigering och trafikhantering, vilket UDP-protokollet i sitt grundutförande saknar. En av dessa tekniker är “proactive speculative retransmission” vilket innebär att paket som bedöms vara särskilt viktiga för en anslutning (exempelvis paket med information om felkorrigering eller krypteringsförhandling) dupliceras för att öka sannolikheten att de kommer fram och samtidigt minska risken för att dessa måste efterfrågas och skickas tillbaka till klienten på nytt.
QUIC är i ett relativt tidigt stadium av sin standardiseringsprocess och har ännu inte implementerats av andra webbläsare än Google Chrome. Protokollet används dock redan av Youtube för att strömma video till användare med Chrome, vilket visas i trafiken som kan observeras i webbläsarens utvecklarverktyg.
HTML 5.1
När HTML5-standarden implementerades mellan 2008-2014 förde den med sig en rad nya funktioner för webbläsare som innan dess varierat vilt mellan olika webbläsare och i vissa fall tvingat webbutvecklare att skriva kod unik för varje webbläsarvariant. När standarden färdigställts fanns att tillgå en rad nya HTML-element som <video>, <audio>, <canvas> samt javascript-bibliotek som MathML, Geolocation, Offline storage, WebRTC, WebAudio, ClassList med flera.
I HTML 5.1, som blev en standard runt november 2016, finns ett mindre antal nya funktioner. Bland dessa finns <picture>-elementet och srcset-attributet för <img>-elementet. Dessa två funktioner tillåter webbutvecklare att specificera flera olika källor för en bildfil som kan väljas ut beroende på hur stor webbsidebesökarens fönster är. Detta gör att man lättare kan anpassa bilder efter skärmstorlek och att man enbart behöver ladda ner den bildstorlek som passar ens skärm bäst.
En annan nyhet är <details> och <summary>, två element som låter webbutvecklare skapa element vars innehåll är dolt tills användaren trycker på dem, varefter de blir synliga. Liknande funktionalitet har tidigare krävt en kombination av Javascript och CSS.
Slutligen innehåller den nya standarden även <menuitem>-elementet och type=”context” attributet, vilka ger webbutvecklare möjligheten att lägga till knappar i den meny som öppnas när användaren högerklickar på en webbsida. Tidigare har man genom Javascript kunnat ersätta hela högerklicksmenyn med en egen meny, vilket denna nya funktionalitet ämnar att göra onödigt. Denna funktion har vid skrivande stund inte vunnit gehör hos alla webbläsarutvecklare, särskilt Google, vilket gör att stödet ännu ej finns tillgängligt hos en majoritet av användarna.
Hastigheten har ökat betydligt
Efter ett drygt decennium, från mitten av 1990-talet till mitten av 2000-talet, av relativt långsam utveckling av webbens standarder har hastigheten nu ökat betydligt. W3C, organisationen med huvudansvar för att skriva och publicera webbstandarder, har ändrat sitt sätt att arbeta och är numera fokuserade på att göra små inkrementella ändringar (låter det bekant?) på sina standarder istället för stora releaser efter åratal av arbete. Dessutom har trycket från industrin blivit starkare, där yngre bolag tar mer plats i standardiseringsorganen och tekniker utvecklade av dessa bolag gör tydliga avtryck i W3C:s nya standarder.
Att HTTP/2 och QUIC dessutom fokuserar på att förbättra prestanda gör dem hett eftertraktade i en värld där vi ser webbsidor växa i datastorlek, inte minst i form av strömmande video och musik. Dessutom konsumerar vi numera i allt större utsträckning webben över trådlösa nätverk och mobilnät på surfplattor och mobiler, en miljö i vilken datahastigheterna inte ännu matchar datorer med trådbundna nätverk. Därför är de ovan nämnda teknikerna mycket väl värda att undersöka och redan nu börja planera dina investeringar i.
