Sådan fungerer HTTP: fra HTTP/1.1 til HTTP/3

Grundprincippet: forespørgsel og svar

Al HTTP-kommunikation består af en forespørgsel (request) fra klienten og et svar (response) fra serveren. HTTP er tilstandsløst: hver forespørgsel står for sig selv, og serveren husker ikke af sig selv, hvem du er fra den ene forespørgsel til den næste. Det er derfor, cookies findes: de lader browseren sende et id med hver forespørgsel, så serveren kan genkende et login eller en kurv.

En simpel forespørgsel ser sådan ud:

GET /produkter/kaffe HTTP/1.1
Host: minwebshop.dk
Accept: text/html
Accept-Language: da-DK

Og serverens svar:

HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Cache-Control: max-age=300

(selve HTML-siden)

Metoder

Metoden fortæller, hvad klienten vil:

• GET henter en ressource, fx en side eller et billede. Den ændrer ikke noget på serveren.
• POST sender data, fx en formular eller en ordre.
• PUT og PATCH erstatter eller opdaterer en ressource, typisk i API’er.
• DELETE sletter en ressource.
• HEAD henter kun headers, ikke indholdet, og OPTIONS spørger, hvad serveren tillader.

To egenskaber ved metoderne har praktisk betydning. GET, HEAD og OPTIONS er sikre: de må ikke ændre noget, og derfor kan browsere, caches og søgemaskiner kalde dem uden at spørge. PUT og DELETE er idempotente: sendes den samme forespørgsel to gange, er resultatet det samme som efter én. Det er POST ikke, og det er grunden til, at browseren advarer, før den sender en formular igen, og at en integration skal passe på, så en ordre ikke oprettes to gange, når et kald gentages efter en timeout.

Statuskoder

For SEO er forskellen på 301 og 302 vigtig: en 301 fortæller søgemaskinerne, at siden er flyttet permanent, så den nye adresse overtager placeringen.

Headers og caching

Headers bærer alt det, der ikke er selve indholdet: indholdstype, sprog, cookies, komprimering og caching. De vigtigste for hastigheden er caching-headerne. Cache-Control fortæller browsere og CDN’er, hvor længe et svar må genbruges, og med ETag eller Last-Modified kan browseren spørge, om dens kopi stadig er gyldig. Er den det, svarer serveren blot 304 Not Modified uden at sende indholdet igen.

De svar-headers, du oftest støder på som ejer af en hjemmeside:

Se det selv

Du kan se det hele på din egen side. I browserens udviklerværktøjer viser fanen Network hver forespørgsel med metode, statuskode, headers og protokolversion. Fra en terminal henter curl -I kun headers:

$ curl -I https://minwebshop.dk/
HTTP/2 200
content-type: text/html; charset=UTF-8
cache-control: max-age=300
content-encoding: br

Får du en 301 eller 302, står den nye adresse i location, og med curl -IL følger du hele kæden, hvilket er den hurtigste måde at finde omdirigeringer, der går i ring eller tager en omvej.

HTTP’s historie

HTTP blev udviklet af Tim Berners-Lee på CERN omkring 1990 sammen med HTML og den første browser. Den første version, senere kaldet HTTP/0.9, kunne kun én ting: hente et HTML-dokument. Siden er protokollen udvidet i faste trin:

Hver ny version har bevaret den samme grundmodel med metoder, statuskoder og headers. Det, der har ændret sig, er, hvordan beskederne pakkes og transporteres. Protokollerne udvikles i IETF og beskrives i RFC’er, og i 2022 blev hele HTTP-familien samlet og opdateret i en ny række specifikationer. Vil du vide mere om, hvordan internettets protokoller er opstået, så læs om netværksprotokollernes historie.

HTTP/1.1

HTTP/1.1 var standarden i næsten 20 år og bruges stadig. Beskederne er ren tekst, som i eksemplerne ovenfor, og de sendes over en TCP/IP-forbindelse. I forhold til HTTP/1.0 kunne samme forbindelse nu genbruges til flere forespørgsler i stedet for at åbne en ny hver gang, og den nye Host-header gjorde det muligt at have mange hjemmesider på samme IP-adresse, hvilket er grundlaget for næsten al moderne hosting. Serveren kunne også begynde at sende et svar, før den kendte den samlede størrelse, og caching blev langt bedre med Cache-Control og betingede forespørgsler.

Den store begrænsning er, at hver forbindelse kun kan håndtere én forespørgsel ad gangen, og et langsomt svar blokerer alle efterfølgende (head-of-line blocking). Browsere åbner derfor flere forbindelser parallelt til hver server, og udviklere lærte at samle filer, lave sprites og fordele filer på flere domæner for at komme uden om det. Meget af det er unødvendigt eller ligefrem skadeligt med HTTP/2.

HTTP/2

HTTP/2 byggede på Googles eksperimentelle SPDY-protokol og ændrede, hvordan data sendes, uden at ændre betydningen af metoder, headers og statuskoder. Beskederne deles op i små binære frames, og mange forespørgsler og svar kan sendes samtidig over én forbindelse som separate strømme. Det kaldes multiplexing, og det fjerner behovet for flere parallelle forbindelser. Samtidig komprimeres headers med HPACK, så de oplysninger, der gentages på hver forespørgsel, som cookies, kun sendes én gang.

Ikke alle nyheder holdt. Server push, hvor serveren kunne sende filer, før browseren bad om dem, hjalp sjældent og er fjernet fra Chrome og de andre Chromium-baserede browsere (på engelsk). Og HTTP/2 løste kun køproblemet i HTTP, ikke i TCP: alle strømme deler én TCP-forbindelse, så mistes én pakke, venter de alle. På dårlige forbindelser kan HTTP/2 derfor være lige så langsom som HTTP/1.1. I praksis bruges HTTP/2 kun over HTTPS, fordi browserne kræver det.

HTTP/3 og QUIC

HTTP/3 løser det sidste køproblem ved at udskifte TCP med QUIC, en transportprotokol oven på UDP, der blev udviklet hos Google og standardiseret i IETF i 2021 (på engelsk). QUIC kender selv til strømmene, så en tabt pakke kun forsinker den strøm, den tilhører. TLS 1.3 er bygget ind, så forbindelse og kryptering etableres i én rundtur i stedet for to eller tre, og ved gentagne besøg kan data sendes med det samme.

En QUIC-forbindelse identificeres heller ikke af IP-adresse og port, men af et id, så den kan overleve, at en telefon skifter fra wifi til mobilnet. Headerkomprimeringen er tilpasset som QPACK, fordi pakker kan ankomme i vilkårlig rækkefølge. Browseren opdager, at en server understøtter HTTP/3, via en Alt-Svc-header eller en HTTPS-post i DNS og falder tilbage til HTTP/2, hvis UDP ikke kan komme igennem. Hvad det betyder i praksis, kan du læse i hvad HTTP/3 betyder for din webshops hastighed.

Sammenligning af versionerne

HTTP og HTTPS

HTTPS er ikke en separat protokol, men HTTP sendt gennem en krypteret TLS-forbindelse. Alt, der står i denne guide, gælder også for HTTPS. I dag bør al trafik være krypteret, og HTTP/2 og HTTP/3 kræver det i praksis. Læs mere i vores guide til HTTPS og TLS.

Ofte stillede spørgsmål

Hvilken HTTP-version bruger min side?

Åbn udviklerværktøjerne i browseren, gå til fanen Network, og slå kolonnen Protocol til. Den viser http/1.1, h2 eller h3 for hver fil.

Skal jeg stadig samle mine CSS- og JavaScript-filer?

Ikke i samme grad som med HTTP/1.1. Med HTTP/2 og HTTP/3 kan mange små filer hentes parallelt, og mindre filer kan caches hver for sig. Minificering og at undgå unødvendige filer giver stadig mening.

Er HTTP/1.1 forældet?

Nej, det bruges stadig mange steder, blandt andet mellem servere og i mange API’er. Men over for browsere bør en moderne hjemmeside tilbyde HTTP/2 og gerne HTTP/3.