Stundum þá detta inn tæknimolar sem kalla á frekari skoðun. Nýlega kom einn starfsfélagi minn og sagði mér frá SPDY.  Eftir að hafa rætt þetta í nokkrar mínútur var mér ljóst að þetta þyrfti ég að skoða betur. SPDY (sem er jú borið fram sem Speedy á ensku) er frumkvæði sem kemur frá Google eins og svo margt annað. SPDY er leið til að gera vefinn sem við notum alla daga hraðvirkari og þá sérstaklega vefefni sem er miðlal með HTTPS. Þetta er frekar tæknilegt mál og því mun þessi pistill ganga út frá að lesandinn hafi grunnþekkingu á tölvusamskiptum og þá sérstaklega HTTP yfir TCP/IP.

Forsendur hafa breyst nokkuð frá því að upphaflegir hönnuðir HTTP, TCP og SSL samskiptastaðlanna hófu sína vinnu. Í dag eru mun fleiri tæki á netinu og svo eru gögn mun stærri og æ fleiri eru að nota SSL til að tryggja öryggi sinna gagna.  Á sama tíma hefur vefviðmót gjörbreyst og kröfur til hraða hjá notendum eru slíkar að í raun er mjög mikilvægt að upplifun sé hröð og sjónræn. Mikil vinna hefur verið lögð í að færa viðmótsvinnslu yfir á endabúnaðinn því þar er yfirlegt nægilegt tölvuafl einnig hefur mikil vinna verið lögð í að gögn sem send eru yfir netið séu eins fyriferðalítil og mögulegt er.

Lítum aðeins á hvernig hinn hefðbundnu samskipti fara fram með HTTP yfir TCP: Fyrst er hið hefðbunda 3-way-handshake sem er til að koma á tengingu á milli aðila (RTT). Síðan hefst hin eiginlega gagnasending þar sem biðlarinn sendir, yfirleitt get skipanir, á miðlarann til að fá umbeðin gögn. Þessi gögn geta verið js skrár, css skrár, myndir eða sjálft htmlið sem myndar síðuna.

Í okkar nútíma mobile umhverfi þá eru tengitímar (RTT) oftar en ekki hlutfallslega langir miðað við tölvur sem eru ekki tengdar með mobile tengingu.

Mikið hefur því verið lagt í að setja upp vefsíður þannig að efni sé sent í réttri röð, efni sé þjappað ef hægt er, myndir séu eins léttar og mögulegt er og að efni sem má vista biðlara megin (cache) sé ekki sótt nema þörf sé á.

En þetta er ekki nema hluti af ferlinu því innbyggt í TCP eru hlutir eins og Slow start sem hefur líka mikil áhrif á og CWND (Congestion Window) en TCP er þannig byggt upp að í byrjun má biðlari einungis senda takmarkað gagnamagn í hverri sendingu og síðan vex gagnamagnið veldisvexti þar til þröskuldi er náð en eftir það vex það línulega. Í hvert sinn sem tenging er gerð er alltaf byrjað á lægsta gagnamagni. Svo að lokum er öryggisþátturinn en mikil aukning er í að vilja tryggja öryggi gagna, ekki síst á mobile netum, og þá grípa menn til HTTPS, en þá bætast enn fleiri skref við tengingar og vinnslu sem eykur bara og fjölgar RTT.

Allir þessi þættir sameinast til að gera notendaupplifun, sérstaklega á mobile netum, slæma og allt virðist vera mjög hægt. Hvað er þá til ráða. Annaðhvort að auka bandvídd eða að stytta RTT. Margir hafa rannsakað þessi mál og sýna allar niðurstöður að með því að stytta RTT (eða fækka) þá næst meiri hraðaaukning heldur en með því að auka bandvídd, sjá nánar á myndinni hér fyrir neðan.

En fram til þessa hafa mestar áherslur verið á aukningu bandvíddar með betri og hraðvirkar netum og er 4G net gott dæmi um þetta. En að stytta RTT eða fækka er eitthvað sem kallar á endurskoðun á almennum samskiptastöðlum á netinu og er IETF að skoða HTTP 2.0 sem meðal annars er byggður á SPDY.
En hvað er þá SPDY og hvernig næst fram hraðaaukning á núverandi nettækni.  Markmið SPDY er að gera vefnotkun hraðvirkari, öruggari og ekki síst að draga úr áhrifum þess hvernig vefsíður eru settar upp af vefforriturum. SPDY stuðningur þarf því að vera bæði í vafranum og á vefþjóninum og sem dæmi þá eru allir Chrome vafrar með SPDY stuðning og allir vefir hjá Google styðja speedy.

SPDY kemur í stað tengingarstjórnunar í HTTP og er aðallega hugsað í notkun með SSL en er líka hægt að nota án þess. SPDY notar alltaf TLS (Transport Layer Security) þannig að gögn send með SPDY eru alltaf dulkóðuð og því öruggari en net sem nota ekki SPDY. Með notkun á TLS þá er alltaf point-to-point tenging á milli biðlara og miðlara.

SPDY kallar ekki á breytingar á þeim samskiptastöðlum sem fyrir eru og margir vefþjónar styðja SPDY en oftar en ekki þarf að leyfa SPDY stuðning á vefþjónum.

SPDY þjappar öllum headers í HTTP samskiptum, en headerar eru bara texti og í flestum tilvikum er þessi texti síendurtekinn í hverju HTTP kalli og í raun lítið notaður sem slíkur, gott dæmi er User-Agent sem segir til um hvaða vafra og stýrikerfi biðlari notar, en það er ekki að breytast mikið í hverri tengingu. Að sama skapa þjappar SPDY cookies og /r/n sem er í hverri línu og þannig mætti lengi telja. Þetta skilar um 20-40% þjöppun í fyrsta kalli en skilar 90-97%  þjöppun á síðari köllum innan sömu tengingar. Þetta er sérstaklega hentugt þar sem upload bandvídd er lítil eins og í mobile netum en einnig í almennum netum því kall frá biðlara til miðlara er að mestu bara header. Þetta er gert með g-zip.

SPDY leyfir fléttun (multiplexun), þar sem SPDY notar ekki margar TCP tengingar, bara eina þá getur SPDY leyft fléttun yfir þá tengingu og fræðilega geta verið 1.073.741.824 straumar í þeirri einu TCP tengingu. Þar sem venjulega síða í dag er með um 85 köll þá sparast mikið af tenginum (og þar með RTT) með því að flétta þessi köll yfir eina SPDY tengingu.

Ólíkt HTTP þá er SPDY full duplex og þar með geta báðir endar hvenær sem er stofnað straum yfir tenginguna.

Annað sem SPDY leyfir er forgangsröðun (priority) á einstök köll, þetta gerir það að verkum að hlutir eins og CSS, JS og annað sem þarf að koma sem fyrst til biðlara er forgangsraðað þannig að ef vefsíðan kallar ekki eftir hlutu í réttri röð þá mun serverinn forgangsraða efni sem er sent til biðlarans, og þar sem SPDY leyfir líka interleaving (setja strauma í bið án þess að slíta) þá getur vefþjónninn sett t.d sendingu á mynd í bið og notað bandvíddina til að senda CSS eða JS og svo þegar því er lokið þá fer myndin aftur af stað.  Þetta gerir forritun vefsíðna óháðari hraða þeirra.

Annað sem SPDY leyfir er að vista CWND stærðina á biðlarann, þannig að þegar næsta tenging er gerð (næst þegar þú ferð á síðuna) þá er ekki byrjað frá lægsta punkti í Slow-start heldur er byrjað á þeim punkti sem síðasta tenging leyfði. Í lang flestum tilfellum þá er þetta gildi vel innan marka og mun því ekki skapa þrenginar á netinu.    

Afleiðing af þessu er svo að SPDY notar því færri netpakka og nýting þeirra er einnig betri.
Google hefur gert mælingar á hvaða áhrif SPDY hefur á hraða vefsíðna. Með því að nota SPDY yfir HTTP þá er hraðaaukningin 27%-60% og yfir HTTPS þá er þetta 35%-55%, en hafa ber í huga að SSL síður eru mun lengur að hlaðast þannig að lægri % getur samt verið mun meiri tímasparnaður.

En SPDY er ekki töfralausnin, SPDY hentar best fyrir vefi sem eru með mikið af síendurteknum heimsóknum og nota mikið af auðlindum. SPDY hentar illa á netum sem eru með mjög háu RTT eða miklu pakka tapi því þar skilar SPDY engum ávinningi umfram að nota bara HTTP án SPDY.

Þessi mikla vinna sem fram hefur farið um að bæta notendaupplifun með betri og snjallari netsamskiptastöðlum er ekki ný af nálinni, TCP hefur verið þróað mikið í gegnum árin sem hefur skilað okkur sem nota netið miklum framförum. En nú er verið að vinna að HTTP 2.0 og ljóst er að hlutir eins og SPDY verða hluti af þeim staðli, því notkun og stærð á vefsíðum mun bara aukast, fjöldi tækja mun aukast en bandvídd getur ekki orðið meiri en hraði ljóssins, svo við vitum.

Höfundur: Ágúst Valgeirsson, Forstöðumaður rafrænna viðskipta, Advania

Helstu heimildir:
http://www.chromium.org/spdy/spdy-whitepaper
http://www.chromium.org/spdy/spdy-protocol/spdy-protocol-draft1
http://http2.github.io/http2-spec/