Sådan fungerer HTTP/2

Forstå grundlæggende netværkskommunikation

Begrænsninger i HTTP/1.1

HTTP/1.1 protokollen anvender sekventiel kommunikation, hvor hver ressource kræver sin egen forbindelse til serveren. Når en browser anmoder om flere ressourcer samtidig, oprettes separate TCP-forbindelser for hver enkelt forespørgsel. Denne tilgang skaber en kø af ventende forespørgsler, også kendt som køblokering (head-of-line blocking), hvor ressourcer må vente på, at tidligere forespørgsler behandles færdigt.

En moderne webside består typisk af HTML-dokumenter, stilark, scripts og billeder. Med HTTP/1.1 skal disse ressourcer hentes én efter én, hvilket resulterer i lange indlæsningstider. Browsere forsøger at omgå denne begrænsning ved at åbne flere parallelle forbindelser, men denne løsning belaster både server og klient unødigt.

HTTP/1.1 skaber flaskehalse i moderne webapplikationer

Komplekse webapplikationer illustrerer tydeligt HTTP/1.1’s begrænsninger. Når en bruger tilgår en moderne webapplikation, starter browseren med at hente hovedsiden. Dette HTML-dokument indeholder referencer til adskillige andre ressourcer såsom JavaScript-filer, CSS-stilark og billeder. Under HTTP/1.1 må disse ressourcer vente i kø, hvilket skaber en dominoeffekt af forsinkelser.

Særligt JavaScript-filer påvirker indlæsningstiden markant, da de ofte blokerer for videre indlæsning indtil de er færdigbehandlet. Dette problem forstærkes yderligere af ressourceafhængigheder, hvor én fil skal indlæses og udføres før andre kan begynde deres indlæsning. I praksis betyder det, at selv mindre forsinkelser i starten af indlæsningen kan resultere i betydelige forsinkelser for den samlede sidevisning.

HTTP/2 introducerer multiplexing

Sådan fungerer multiplexing

HTTP/2 introducerer multiplexing som en grundlæggende ændring i måden, hvorpå data overføres mellem klient og server. Hvor HTTP/1.1 behandler hver forespørgsel sekventielt, tillader multiplexing samtidig overførsel af flere datastrømme gennem samme TCP-forbindelse. Dette svarer til at opgradere en ensporet vej til en flersporet motorvej, hvor flere biler kan køre samtidigt.

Teknologien bygger på datastrømme (streams), der fungerer som uafhængige kommunikationskanaler inden for den samme forbindelse. Hver datastrøm transporterer sit eget sæt af forespørgsler og svar, identificeret med unikke numre. Denne struktur gør det muligt at prioritere vigtige ressourcer, mens mindre kritiske elementer indlæses sideløbende.

Datastrømme i praksis

I HTTP/2 nedbrydes al kommunikation i mindre enheder kaldet frames. Hver frame tilhører en specifik datastrøm og indeholder information om både sin destination og oprindelse. Dette svarer til et postsystem, hvor hvert brev bærer både en afsender- og modtageradresse, så flere breve kan sorteres og leveres effektivt gennem samme distributionsnetværk.

Frames kan sendes i vilkårlig rækkefølge og samles korrekt hos modtageren baseret på deres stream-identifikation. Denne fleksibilitet betyder, at en stor fil ikke længere blokerer for mindre, vigtige ressourcer. For eksempel kan et vigtigt JavaScript-bibliotek modtages samtidig med, at store baggrundsbilleder downloades, hvilket markant reducerer tiden før websiden bliver interaktiv.

Den tekniske implementering af multiplexing i HTTP/2 understøtter også tovejs-kommunikation. Serveren kan sende flere svar samtidig, mens den modtager nye forespørgsler fra klienten. Dette minder om en telefonsamtale, hvor begge parter kan tale og lytte på samme tid, i modsætning til en walkie-talkie, hvor kun én kan sende ad gangen.

For at sikre effektiv udnyttelse af netværksforbindelsen implementerer HTTP/2 et system til flow control. Dette system regulerer hastigheden af dataoverførsel mellem klient og server, så ingen af parterne overbelastes. Flow control fungerer på både stream- og forbindelsesniveau, hvilket giver fin kontrol over ressourceforbruget.

Multiplexing optimerer ressourceudnyttelse

Med multiplexing kan webudviklere nu optimere deres applikationer på nye måder. Ved at udnytte den samtidige dataoverførsel kan kritiske ressourcer prioriteres højere end mindre vigtige elementer. For eksempel kan hovedindholdet og layoutet indlæses først, mens billeder og andre medier hentes sideløbende.

Denne fleksibilitet i ressourcehåndteringen åbner også for mere avancerede indlæsningsstrategier. Udviklere kan nu gruppere relaterede ressourcer og sende dem sammen, hvilket reducerer den samlede indlæsningstid. Et praktisk eksempel er en nyhedsside, hvor artiklens tekst og tilhørende billeder kan indlæses samtidig, mens kommentarer og relaterede artikler hentes med lavere prioritet.

Multiplexing eliminerer også behovet for forskellige workarounds, der blev brugt i HTTP/1.1, såsom domain sharding og ressourcesammenlægning. Dette forenkler både udvikling og vedligeholdelse af webapplikationer, da ressourcer nu kan organiseres efter logisk sammenhæng frem for tekniske begrænsninger.

Komprimerer headers effektivt

HPACK-komprimering i praksis

HTTP/2 introducerer en specialiseret komprimeringsalgoritme kaldet HPACK, der reducerer størrelsen af HTTP-hoveder (headers) markant. Hvor HTTP/1.1 sender hovederne som almindelig tekst i hver forespørgsel, bruger HPACK en mere effektiv tilgang baseret på dynamiske ordbøger. Dette svarer til at oprette en fælles ordliste mellem afsender og modtager, hvor ofte brugte udtryk erstattes med korte koder.

HPACK vedligeholder to separate ordbøger: en statisk og en dynamisk. Den statiske ordbog indeholder almindelige HTTP-hovedfelter som “method”, “path” og “status”, mens den dynamiske ordbog opbygges løbende med de specifikke hovedfelter, som klient og server udveksler. Når en header sendes gentagne gange, kan den efterfølgende refereres med et simpelt indeks i stedet for at sende hele teksten igen.

Reducerer netværkstrafik

Header-komprimering har særlig betydning for moderne webapplikationer, der ofte sender hundredvis af forespørgsler til serveren. Traditionelle HTTP/1.1 hovedere udgør typisk 500-800 bytes per forespørgsel, mens HPACK kan reducere dette til 20-50 bytes for gentagne forespørgsler. For mobilbrugere og andre med begrænset båndbredde betyder denne reduktion hurtigere sideindlæsning og mindre dataforbrug.

HPACK anvender også Huffman-kodning til at komprimere tekstværdier i hovederne. Denne teknik tildeler kortere koder til hyppigt forekommende tegn, hvilket yderligere reducerer datamængden. Den kombinerede effekt af ordbøger og Huffman-kodning resulterer i en væsentlig reduktion af netværkstrafikken, særligt for websider med mange små ressourcer eller hyppige AJAX-kald.

Komprimeringsmekanismen er designet med sikkerhed for øje og undgår bevidst de sårbarheder, der tidligere blev fundet i protokoller som SPDY. Ved at holde separate komprimeringskonktekster for hver forbindelse forhindrer HPACK potentielle angreb baseret på header-manipulation.

Server push

Proaktiv ressourcehåndtering

HTTP/2 introducerer server push som en mekanisme, hvor serveren kan sende ressourcer til klienten før de bliver efterspurgt. Dette svarer til en tjener, der ikke blot serverer den bestilte hovedret, men også automatisk medbringer passende tilbehør. Serveren kan analysere HTML-dokumentet og identificere ressourcer som scripts, stilark og billeder, som browseren med sikkerhed vil få brug for.

For at igangsætte server push sender serveren først et push promise, der informerer klienten om den kommende ressource. Dette push promise indeholder samme headerinformation som en normal forespørgsel, hvilket giver klienten mulighed for at afvise ressourcen, hvis den allerede findes i browserens cache. Denne mekanisme forhindrer unødig dataoverførsel og sikrer effektiv ressourceudnyttelse.

Cache-strategier

Server push kræver omhyggelig cache-håndtering for at fungere optimalt. Når serveren overvejer at pushe en ressource, må den tage højde for forskellige cache-scenarier. En effektiv implementering analyserer klientens cache-tilstand gennem cookies eller andre mekanismer, før den beslutter hvilke ressourcer der skal pushes.

Cache-validering spiller en central rolle i server push-arkitekturen. Browseren kan sammenligne modtagne push promises med sin lokale cache og afvise ressourcer, der allerede er cached. Dette system fungerer gennem RST_STREAM frames, hvor browseren kan afbryde overførslen af pushede ressourcer, den ikke har brug for. Dermed undgås dobbelt download af ressourcer, samtidig med at fordelene ved proaktiv levering bevares for nye eller opdaterede filer.

Ved at integrere server push med eksisterende cache-mekanismer opnås en balance mellem hurtig levering og effektiv ressourceudnyttelse. Serveren kan eksempelvis push nye versioner af statiske ressourcer sammen med HTML-dokumentet, men undlade at pushe ressourcer der sjældent ændres.

Den binære protokol

Forstå protokollens opbygning

HTTP/2 erstatter den tekstbaserede protokol fra HTTP/1.1 med et binært format. I modsætning til den læsbare tekstform i HTTP/1.1, hvor beskeder sendes som almindelig tekst, transporterer HTTP/2 data i præcist definerede binære frames. Dette svarer til forskellen mellem at sende et håndskrevet brev og at sende en stregkode – mens brevet er let at læse for mennesker, er stregkoden optimeret til maskinel behandling.

Hver binær frame består af en fast header efterfulgt af variabel længde payload data. Frame-headeren indeholder vigtig metadata som længde, type, flag og stream-identifikation. Dette standardiserede format muliggør hurtig og pålidelig parsing, da computerens processor kan læse og fortolke data direkte uden først at skulle konvertere tekst til computerens interne format.

Effektiv parsing

Den binære protokol reducerer markant den tid, computeren bruger på at fortolke netværkskommunikation. Hvor HTTP/1.1 kræver kompleks tekstanalyse for at identificere start og slutning af beskeder, kan HTTP/2’s binære frames behandles med simple bitoperationer. Dette giver ikke kun hurtigere processing, men eliminerer også mange af de fejlkilder, der findes i tekstbaserede protokoller.

Den strukturerede opbygning af frames letter også fejlhåndtering. Hvis der opstår problemer under overførslen, kan modtageren præcist identificere hvor fejlen opstod og hvilken type frame der blev påvirket. I HTTP/1.1 kunne en enkelt fejl i tekstfortolkningen potentielt ødelægge hele kommunikationen, mens HTTP/2’s binære format gør det muligt at isolere og håndtere problemer på frame-niveau.

Konkrete forbedringer ved HTTP/2

Hastighedsgevinster

Overgangen til HTTP/2 viser betydelige forbedringer i indlæsningstider på tværs af forskellige typer webapplikationer. Hvor komplekse sider under HTTP/1.1 ofte bruger 2-3 sekunder på den første indlæsning, reducerer HTTP/2 dette til under ét sekund. Denne forbedring skyldes primært multiplexing og header-komprimering, der sammen eliminerer meget af den ventetid, der tidligere var uundgåelig.

På mobilnetværk, hvor latenstid ofte er en udfordring, demonstrerer HTTP/2 særligt markante forbedringer. En typisk e-handelsside med mange produktbilleder og dynamisk indhold indlæses op til 60% hurtigere sammenlignet med HTTP/1.1. Server push bidrager yderligere til denne forbedring ved at reducere antallet af nødvendige netværksforespørgsler.

Mindsker ressourceforbrug

Den binære protokol og effektive frame-håndtering i HTTP/2 reducerer også den processorkraft, der kræves til netværkskommunikation. Målinger viser, at servere kan håndtere op til 50% flere samtidige forbindelser med HTTP/2 sammenlignet med HTTP/1.1, uden at øge hardwareressourcerne. Dette skyldes både den simplere parsing af binære frames og elimineringen af behovet for multiple TCP-forbindelser.

Netværkstrafikken reduceres markant gennem header-komprimering. På en travl webserver, der håndterer millioner af daglige forespørgsler, kan dette resultere i flere hundrede gigabyte sparet båndbredde per dag. Den reducerede datamængde gavner særligt mobile brugere, hvor hver sparet kilobyte bidrager til hurtigere sidevisning og reduceret dataforbrug.