Szerző: Gálffy Csaba

2013. július 1. 12:37

Új szabvánnyal gyorsítaná a webet a Google

A Google szerint a TCP protokoll megkötései komoly lassító tényezővé léptek elő a webes alkalmazások esetében, ezért a cég egy UDP-alapú adatátviteli protokollt dolgozott ki. Az új szabvány alacsonyabb késleltetést és folyamatosabb adatátvitelt ígér.

Új, kísérleti átviteli protokollt dolgozott ki az internetes adattovábbítás felgyorsítására - jelentette be a Google. A QUIC (Quick UDP Internet Connections) egyelőre kísérleti fázisban van, nagy újdonsága, hogy a TCP-alapú adatátvitel helyett UDP-t használ. A cég szerint ma már a TCP által megkövetelt oda-vissza útban látja a késleltetés (és ezzel a lassúság) legnagyobb okát, ezért érdemes az alapprotokollt is lecserélni.

A Google a HTTP leváltására tervezett SPDY protokollban már számos, az átviteli sebességet növelő technológiát bevezetett (például multiplexelés), a késleltetés lefaragásában azonban ezek nem sokat segítenek. A vállalat mérnökei szerint a hálózati késleltetés nem csökkenthető egy bizonyos ponton túl, a jel terjedésének fizikai korlátai miatt, ezért az oda-vissza utak számának minimalizálása a követendő út. A megoldást a Google az UDP protokollban látja, amely kevesebb kézfogást igényel, a hibakezelést pedig az alkalmazásokra bízza.

TCP vs. UDP

A SPDY protokoll számos ponton megújította az adatátvitelt, az egyik legnagyobb újdonság a multiplexelés volt, amely a kliens és szerver közötti kapcsolatokat egybeolvasztja: a weboldal egyetlen TCP-kapcsolaton keresztül lejön, nem kell minden objektumhoz ezt külön létrehozni. Ezzel csökken a szerver terhelése is, fontosabb azonban, hogy eltűnik a forgalomból a külön kapcsolatok létrehozása által jelentett extra terhelés.

A Google szerint azonban a TCP-alapú multiplexelés még mindig nem a legjobb megoldás. Ha a TCP-forgalom egyetlen kapcsolata valamiért megakad, akkor az a teljes letöltést leállítja. Ez párhuzamos HTTP-kapcsolatok esetén egyetlen kapcsolat kiesését, vagyis minimális fennakadást jelentene, az összeolvasztott kapcsolaton azonban a teljes adatfolyamot feltartóztatja. Ilyen fennakadást okozhat például a csomagvesztés, a TCP ilyenkor a csomag újraküldését írja elő, amíg ez le nem zajlik, a többi adatfolyam is áll. Ugyan az SPDY még ennek ellenére is gyorsabb, mint a hagyományos forgalom, a maximumot nem képes elérni.

Az UDP használatával a QUIC képes out-of-order küldeni csomagokat, vagyis egy-egy csomag elvesztése-újraküldése a multiplexelt adatfolyamok közül csak egyet érint, a többi folyamatos maradhat. Az UDP viszonylagos hátránya, hogy a kapcsolat integritását a hálózat helyett az alkalmazás szintjén kell kezelni, ez azonban része a QUIC protokollnak, a szerver és a kliens a maga oldalán intézkedik erről.

Szabvány lesz az SPDY

A Google korábbi kezdeményezése, a SPDY protokoll nagy sikernek örvend, jelen állás szerint ez lesz a következő generációs HTTP szabvány (HTTP 2.0) alapja. A 2009-ben bemutatkozott, azóta széles körű adoptációra lelt átviteli protokoll a fent említett multiplexelés mellett tömörítést, titkosítást és prioritizálást is bevet a hatékonyabb hálózati kommunikáció érdekében. A protokollt ma már a Google Chrome, a Mozilla Firefox és az Opera is támogatja, és implementálni fogja a nyár végén esedékes Internet Explorer 11 is. A SPDY szerveroldalon is terjed, a Google saját webes alkalmazásai mellett a Twitter, a Facebook és a Wordpress.com is támogatja, ahogy az NGINX és az Apache is (utóbbi külső kiterjesztés igénybevételével).

Jöhet a malware-cunami az iPhone-okra?

Nyílik az iOS, de tényleg annyira veszélyes ez? Annyira azért nem kell félni, elég sok kontroll van még az Apple-nél.

Jöhet a malware-cunami az iPhone-okra? Nyílik az iOS, de tényleg annyira veszélyes ez? Annyira azért nem kell félni, elég sok kontroll van még az Apple-nél.

Az SPDY és a QUIC teljes visszafelé kompatibilitást nyújt, vagyis az implementációhoz kizárólag a kliensnek és a szervernek kell támogatnia a protokollt, a köztes hálózat számára ez a forgalom semmilyen problémát nem okoz. Legalábbis elméletben: az SPDY kapcsán számos panaszt hallhattunk, hogy a teljesen titkosított kapcsolat az egyes hálózati és CDN-eszközök gyorsító mechanizmusát kiiktatja. Ez a Google szerint egyébként szándékos (és szükséges), az egyes hálózati eszközök ugyanis beépített "forgalomjavító" algoritmusaikkal elrontották és szétbontották az adatfolyamot.

Google: nem félünk használni a piaci fölényünket

A Google egészen egyedi helyzetben van a weben abból a szempontból, hogy mind a böngészők, mind a böngészőben futó webes alkalmazások (email, keresés, stb.) jelentős (bár nem domináns) piaci részesedéssel rendelkezik. Emiatt a vállalat saját hatáskörben, a szabványokat kidolgozó testületek megkerülésével tud bevezetni egyedi protokollokat, formátumokat. Így történt ez az SPDY és a WebP/WebM esetében is, várhatóan ugyanez játszódik le a QUIC-kel is néhány éven belül. Részben e merész lépések eredményeképp a web fejlődése újra látványosan felgyorsult - az 1999-ben elfogadott HTTP 1.1 után hamarosan elkészül a HTTP 2.0 - SPDY alapokon, Google-nyomásra.

A QUIC szükségességének részletes indoklása és a koncepció műszaki részletei a Google dokumentumában olvashatóak, a tömör kérdés-válasz formátum itt érhető el.

Nagyon széles az a skála, amin az állásinterjú visszajelzések tartalmi minősége mozog: túl rövid, túl hosszú, semmitmondó, értelmetlen vagy semmi. A friss heti kraftie hírlevélben ezt jártuk körül. Ha tetszett a cikk, iratkozz fel, és minden héten elküldjük emailben a legfrissebbet!

a címlapról