På tross av stor oppmerksomhet og drama rundt standardiseringen av HTTP 2.0, er den nyeste versjonen av HTTP-protokollen ikke bare et markedsføringsbegrep. Det er en reell, levende IETF-standard som går «live» i november (2014).
Og den forandrer alt.
Det finnes en rekke endringer i HTTP 2.0-spesifikasjonene som forbedrer ytelsen, blant annet multipleksing og «header»-komprimering. Dette må ikke feilaktig anses som små oppdateringer, da de gir en betydelig bedre ytelse, spesielt for klienter som kobler til via et mobilnett. «Header»-komprimering minimerer for eksempel behovet om å transportere HTTP-header sammen med hver eneste forespørsel og respons. HTTP-header kan medføre en unødvendig mengde ekstra data, spesielt for mindre spørringer som ganske enkelt består av en nettadresse eller noen få byte med data.
Multipleksing har tradisjonelt vært en teknologi på serversiden, beregnet som en avlastingsfunksjon som optimerer både serverressurser og i sin tur, ytelsen på applikasjonen. Det å benytte multipleksing på klientsiden, gir de samme fordelene i forhold til å redusere ressursforbruket. Dette forbedrer ytelsen ved å eliminere belastningen forbundet med å åpne en ny forbindelse, og ikke minst ved å slippe og vedlikeholde statusen for hver forbindelse.
Googles SPDY (som faktisk er grunnlaget for HTTP 2.0 og støttes av 65 prosent av nettleserne i dag) og MultiPath TCP-protokollene benytter multipleksing-teknikker på klientsiden.
Det er imidlertid ikke dette som forandrer alt. Selv om dette er nødvendige forbedringer, og sikkert vil være en fordel for klienter og applikasjoner som kan utnytte dem (enten innebygd eller ved å bruke en HTTP-gateway), så er det det at SSL kan bli obligatorisk som er en skikkelig potensiell «game changer» med HTTP 2.0.
Ja, det stemmer. SSL kan bli obligatorisk.
Hva betyr dette?
For alle på datasentersiden av denne ligningen – enten datasenteret er en skytjeneste eller et tradisjonelt senter – vil det å bruke SSL eller TLS for HTTP effektivt skjule det meste av applikasjonsdataene.
Dette har alltid vært slik: Å bruke ende-til-ende SSL i internett-applikasjoner (som F5s data viser, gjelder for 64 prosent av alle applikasjoner) har alltid betydd å begrense innsyn i nettrafikken. Tross alt er hensikten med transportlagsikkerhetsprotokoller, som SSL og TLS, å beskytte data mot nysgjerrige øyne. Disse øynene inkluderer velvillige tjenester som ytelsesovervåking, IDS, IPS, DLP, nettakselererasjon og andre tjenester som er basert på evnen til å inspisere data underveis.
Dette kravet for SSL eller TLS betyr at det må bli endel endringer i nettverksarkitekturen hvis du skal flytte over til HTTP 2.0 for å utnytte ytelsesfordelene. På en eller annen måte er du nødt til å finne ut hvordan man skal støtte et krav om at man MÅ bruke TLS/SSL samtidig som det skal være mulig å bruke overvåking, akselerasjon og sikkerhetstjenester – forhåpentligvis uten å kreve at alle tjenester i applikasjonsflyten skal dekryptere og rekryptere dataene.
Selv om markedsføringen gjorde mye ut av «SSL Everywhere»-bevegelsen, og mange organisasjoner faktisk begynte å etterleve forestillingen om at all internett-samhandling bør sikres med SSL eller TLS, var ikke alle så opptatt av å håndheve den overfor forbrukere og ansatte. Usikret HTTP var fortsatt ofte tillatt, til tross for risikoen forbundet med denne protokollen.
Men HTTP 2.0 vil medføre et krav om at organisasjoner som tar i bruk den nye protokollen, bruker den fullt og helt.
Delta i debatten
Informasjon om debattinnlegg og kronikker i digi.no
Alle innlegg må sendes til redaksjon@digi.no. Husk å legge ved et portrettbilde. Vi forbeholder oss retten til å redigere innsendt materiale.
