I 2009 introduserte Google en ny protokoll for levering av webinnhold, som et tillegg til HTTP (Hypertext Transfer Protocol), nemlig SPDY (uttales som «speedy»). Ved hjelp av blant annet multipleksing av datastrømmer i én og samme forbindelse, prioritering av spørringer og komprimering, skal websider med innhold levert ved hjelp av SPDY kunne lastes ned og vises flere titalls prosent raskere enn med http alene. SPDY avhenger av støtte fra både klient og server. Protokollen støttes i dag av Chrome, Firefox og Opera. Den helt ferske betautgaven av IE11 støtter også SPDY. Om Apple vil støtte SPDY med kommende utgaver av Safari, er foreløpig ukjent.
På serversiden støttes SPDY av blant annet Apache og Nginx. Flere store nettsteder, som Facebook og Wordpress.com – i tillegg til mange av Googles tjenester – har tatt i bruk SPDY.
Det er allerede klart at neste versjon av HTTP (2.0) vil bygge på SPDY. Dermed har Google tatt enda et skritt videre for å kunne øke farten på weben. Dette kalles for QUIC (Quick UDP Internet Connections).
HTTP og SPDY brukes vanligvis på toppen av en pålitelig transportlag-protokoll, Transmission Control Protocol (TCP), som sikrer at datapakkene blir levert ved at avsenderen sender på nytt de pakkene som mottakeren ikke bekrefter at har blitt mottatt.
Men fordi datasignalene tross alt beveger seg med en begrenset hastighet i nettverket – for eksempel tar en tur-retur Norge– Australia gjerne flere hundre millisekunder (forsøk å pinge en server i Australia) – så vil pakketap kunne føre til ganske store forsinkeser. Dette gjelder i enda større grad med SPDY enn med ren HTTP, siden et pakketap da vil føre til at alle de multipleksede datastrømmene midlertidig stoppes, mens et pakketap med ren HTTP bare vil stoppe den ene av flere parallelle datastrømmer som faktisk er berørt.
Det er her QUIC kommer inn. Dette er en eksperimentell protokoll som nå er bygget inn i testversjoner av Chrome. Protokollen støtter multipleksede forbindelser basert på UDP (User Datagram Protocol) over IP-nettverk.
I utgangspunktet er ikke UDP en pålitelig protokoll, siden avsenderen bare sender ut data og håper at mottakeren er klar, uten å vente på noen bekreftelse på dette. Det sendes heller ikke noen bekreftelser fra mottakeren om at pakker mottatt, rekkefølgen på pakkene er ikke garantert og duplikater kan oppstå.
UDP brukes derfor som oftest i forbindelse med leveranse av sanntidsinnhold, slik som IP-telefoni og videokonferanser, hvor det å unngå forsinkelser er viktigere enn at alle dataene kommer fram.
Men når man skal vise en webside, er ikke datatap akseptabelt. Dette og flere andre mangler ved UDP, må derfor håndteres av QUIC i stedet.
For å unngå «trafikkork», vil QUIC ta i bruk båndbredde-estimering i begge retninger. For å redusere pakketap, vil pakkene sendes ut med jevn takt. QUIC avhenger ikke av at pakkene mottas i riktig rekkefølge. Det benyttes feilkorreksjonskoder (ECC) for å redusere behovet for å ettersende tapte pakkedata. QUIC er dessuten designet for å tilby sikkerhet tilsvarende TLS/SSL (Transport Layer Security/Secure Socket Layer) til enhver tid. De kryptografiske blokkene er tilpasset pakkestørrelsen, noe som ytterligere skal begrense effekten av pakketap.
I tillegg til å implementere QUIC i testversjoner av Chrome, har Google kommet med en prototype som implementerer QUIC på serversiden.
QUIC skal altså kunne bidra til at det går raskere for nettleseren å opprette datastrømmer, samtidig som at dataoverføringene i mindre grad vil stoppes på grunn av datatap. Men i hvor stor grad forsinkelsene vil bli redusert ved virkelig bruk, er noe Google fortsatt studerer.
Selskapet har publisert mye dokumentasjon om QUIC. Denne FAQ-en er et greit sted å starte.
Les også:
- [10.02.2015] Google dropper egen webprotokoll
- [26.06.2013] IE11 støtter 3D-grafikk
- [19.04.2012] Raskere nettsted med ny Apache-modul
- [13.11.2009] - 2 x raskere web
