HTTP/2

Hvert millisekund tæller når brugere (u)tålmodigt besøger ens website. De store spillere ved det, og bruger omfattende ressourcer på at optimere i marginalerne. Kampene er typisk en kombination af at maksimere ydelse inden for de etablerede standarder og et arbejde på forbedringer af standarderne selv.

Jeg havde på GOTO København fornøjelsen af at lytte til Daniel Stenberg der til dagligt arbejder for Mozilla og er en af hovedmændene bag det populære web-tool curl og hans foredrag om HTTP/2.

De fleste web-udviklere har sikkert stødt på det. Websider skal optimeres, Javascript minimeres, CSS minimeres, og bruger man mange billeder skal de sættes sammen til ét stort og beskæres vha. CSS til enkeltelementer eller in-lines så de bliver en del af CSS’en osv. Formålet er at minimere antallet af http-forespørgsler – de tager nemlig lang tid at etablere. Ud over dette begrænser browseren antallet af forbindelser til et enkelt domain – noget der har ført til en workaround kaldet server-sharding, hvor man opretter www1.site.dk, www2.site.dk osv. der alle peger på samme server.

Ovenstående skærmbillede fra Firefox viser hvor grænseværdierne ligger den dag i dag – op til seks samtidige forbindelser til hvert domæne.

HTTP/2 Scope

For ikke at skulle genopfinde hele internettet var arbejdsgruppen omkring HTTP/2 pålagt visse begrænsninger. Eksisterende paradigmer omkring HTTP skulle bevares – HTTP/2 ændrer kun på den protokol vi kører hen over TCP. Http:// og https:// bevares. HTTP/1 vil tage mange år om at forsvinde, så infrastrukturen skal stadig understøtte denne. Og så var der et generelt behov for forsimpling. Da HTTP/1 blev etableret var det lidt et kludetæppe af best practices fra branchen – med HTTP/2 havde man chancen for at få fjernet mange optionelle dele.

Features

• Binær protokol
  HTTP/1 har altid været meget nem at fejlsøge på da alt i protokollen er bygget op omkring tekst – i princippet kan man blot telnette til port 80 på en webserver og begynde at agere browser. Med HTTP/2 er dette slut – af flere årsager. For det første fordi det skulle være nemmere at implementere – med tekst er der meget tvetydighed omkring linjeskift m.v. som man helt slipper for. Desuden er argumentet at ændringen ikke er så stor – hvis en browser i dag kører på https eller benytter sig af transportkompression er formatet alligevel binært. Så resultatet af dette er at værktøjerne skal være istand til at omsætte den binære protokol til noget læsbart.

• Bedre udnyttelse af forbindelsen
  Det binær format giver dog også andre fordele. I stedet for at sende hver ressource (billede, html, css el lign.) over hver sin separate forbindelse sender HTTP/2 binære rammer over forbindelsen der hver især indeholder fragmenter af den fulde ressource. HTTP/2 kan så udnytte en enkelt forbindelse ved at multiplexe flere af disse binære streams.

• Komprimering af headers
  HTTP er som udgangspunkt stateless – så alt den information som en server har brug for at vide om klienten skal sendes med i hver eneste forespørgsel. Typisk er der tale om teknisk information om hvilke formater browseren forstår, fortrukne sprog, caching information og cookies. Til tider fylder denne metainformation mere end selve indholdet af forespørgslen.
  

  En stor portion metainformation blot for at hente html-delen af forsiden af QED.dk.

  HTTP/2 introducerer to teknikker for at nedbringe datamængden af headers. For det første tilføjes der en lille smule state så klienten efter at have sendt en header én gang blot kan referere til denne. Og for det andet bruges der simpel komprimering i form af huffman-encoding.

• Push
  HTTP/2 åbner ligeledes op for en lidt sjov optimering. Serveren kan vælge at sende data til klienten som denne ikke har bedt om. Eksempelvis kan serveren vælge at sende linkede billeder med når en webside bliver forespurgt. Det åbner op for en bred vifte af optimeringer som serveren kan lave baseret enten på heuristikker eller kendskab til de applikationer der skal serveres og det er helt sikkert et sted hvor der kan bruges noget fremtig forskning og udvikling.

• Kryptering af al trafik
  Mange har advokeret for at vi bør sende alt web-trafik hen over https-forbindelser og med denne iteration af HTTP blev der også skubbet på for at gøre dette til et krav. Det var ikke kun for at gøre trafikken sikker, men også fordi at visse dele af vores infrastruktur i dag udfører inspektion af de http-pakker der bliver overført. Det kunne fx. være et stykke antivirus-software der pludselig reagerer på at trafikken er skiftet fra tekst til binær form.

  Dog er der steder hvor kryptering ikke giver mening, eksempelvis intern trafik mellem to microservices og derfor er krypteringen også i sidste ende endt med at være optionel. Men på grund af de førnævnte problemer har alle de store browserproducenter meldt ud at de kun vil understøtte HTTP/2 over https-forbindelser.

HTTP/2 er i høj grad en teknologi hvor vi alle kan være med. Når vi udvikler applikationer er denne ændring i http-protokollen som udgangspunkt transparent og den infrastruktur vi allerede har etableret bør fint kunne håndtere at vi skifter transportformatet ud. Der er få undtagelser til dette – fx. bør vi med tiden stoppe med de førstnævnte optimeringer med at samle ressourcer i store klumper så vi kan høste nogle af de fordele HTTP/2 bringer.

Det er svært at forudse hvor store fordele HTTP/2 egentligt giver den enkelte browsingoplevelse med de store variationer der er på både hastighed og latency på internetforbindelserne men udviklingen stopper heller ikke her. Google er allerede i gang med næste iteration kaldet QUIC der eksperimenterer med at køre HTTP/2 over den langt hurtigere og mere usikre forbindelse UDP.