Přejít k navigační liště

Zdroják » Různé » Bude web rychlejší s protokolem SPDY?

Bude web rychlejší s protokolem SPDY?

Články Různé

O protokolu SPDY, vyvinutém Googlem, se příliš nemluví, nebývá ani námětem článků v médiích ani vášnivých sporů v diskusních fórech. Google samotný ho používá, ale nijak „netlačí“. O co vlastně přicházíme (a možná přijdeme)? Je SPDY opravdu technologie, která může nějak výrazněji web zrychlit?

Nálepky:

Protokol SPDY („SPeeDY“) vznikl v rámci projektu Chromium (prohlížeč Chrome) jako způsob, jak zrychlit přenos dat mezi serverem a prohlížečem. SPDY má vylepšit HTTP, resp. opravit některé jeho nešvary, především pomalost.

HTTP1.x

Naprostá většina webových prohlížečů dnes komunikuje se servery prostřednictvím protokolu HTTP, resp. HTTPS. Je bezstavový, tzn. spojení jsou nezávislá a jsou udržována jen krátkou dobu, typicky pro několik málo souborů. Uzavírání spojení po přenosu jednotlivých souborů má pozitivní efekty – umožňuje serveru šetřit prostředky, a tím zpracovat víc paralelních požadavků, a snáze se zajišťuje „atomicita spojení“. Na druhé straně jsou negativa: spojení je potřeba neustále navazovat a režie je, obzvlášť u malých souborů, značná.

Ikonky…

Dovolte zde malé odbočení: Představte si takový běžný WYSIWYG editor se sadou ikonek o rozměrech 32×32px. Představte si redakční systém s přepínáním jazyků, který obsahuje několik desítek „vlaječek“ 16×16px. A jsou další podobné příklady. Pokud je autor nešika, je schopen všechny tyhle soubory (každý s velikostí v řádu stovek bajtů) načíst při načtení stránky, hezky jeden po druhém… Však on si je prohlížeč nacachuje!

Enormní počet malých souborů představuje poměrně výrazné zpomalení při načítání (i s cache). Zkuste v takovém případě zauvažovat o alternativním způsobu – třeba o jedné „plachtě“ se všemi ikonkami, kterou napozicujete pomocí CSS, nebo o uložení obrázků jako Data URL – sice budete mít o třetinu větší objem dat, ale věřte, že jeden 30kB soubor se načte mnohem rychleji než sto 200bajtových souborů!

Ping-pong

Neustálé otvírání a zavírání spojení představuje značné režijní výdaje. Ve verzi HTTP1.1 byla proto přidána možnost využít jedno spojení pro víc požadavků po sobě (Keep-Alive), kdy prohlížeč se serverem po přenosu jednoho souboru spojení neuzavřou, ale využijí pro přenos dalšího požadavku. Tím se šetří čas, který by byl potřeba na uzavření a opětovné navázání komunikace. Zároveň přišla možnost využít „HTTP pipeline“, tedy souběžného otevření více komunikačních kanálů.

Persistentní spojení (Keep-Alive) umí prohlížeče používat, umí ho i většina serverů a v HTTP1.1 je použito právě toto spojení, „není-li uvedeno jinak“. Persistentní spojení není udržováno navěky, ale většina serverů má implementovaný timeout – tedy čas, po který naslouchá, zda přijde další požadavek. Timeout bývá v řádu jednotek sekund. Tím se zabraňuje udržování spojení ve chvílích kdy klient např. přestane odpovídat.

HTTP pipelining je rovněž implementován ve většině současných HTTP serverů (údajně s výjimkou IIS4), ovšem s podporou v prohlížečích to je horší. Některé jej neimplementují vůbec, jiné jej mají vypnutý, pouze Opera jej má zapnutý a má i mechanismus pro jeho vypnutí v případech, kdy by mohl způsobit problémy. Reálné využití HTTP pipeline tedy není nikterak slavné; vše komplikuje navíc vyžadovaný princip FIFO, tedy zpracování v tom pořadí, v jakém požadavky přišly. Pokud na začátku pošlete časově náročný požadavek, musí ostatní na stejném komunikačním kanálu čekat ve frontě.

SPDY

Pro Google, který svou vizi webu budoucnosti staví na webových aplikacích, je životně důležitý rychlý prohlížeč a rychlé připojení – bez těchto dvou věcí budou webové aplikace stále pokulhávat za nativními, resp. lokálními. HTTP2.0 se zjevně v dohledné době nechystá. Pro Chrome tedy přišel s protokolem SPDY, který – podle měření Googlu – urychlí načítání dat za příznivých okolností až o 60 %.

„Tak rychlý, že Speedy Gonzáles je proti němu jen průměrně rychlý Gonzáles…“

Jak SPDY dosahuje tohoto zrychlení? Používá několik technik:

  • Pipelining bez FIFO (víc přenosů najednou v rámci jednoho spojení)
  • Komprese dat (včetně hlavičky)
  • Prioritizace požadavků
  • Obousměrná komunikace

SPDY umožňuje v jednom TCP spojení přenášet víc paralelních toků dat, streamů. Každý stream má svoje ID a přenášená data obsahují tento identifikátor, takže obě strany komunikace dokáží poznat, ke kterému streamu přenesená data patří. Se SPDY lze tedy po jednom TCP spojení posílat libovolný počet streamů naráz. Kvůli snazší identifikaci zavádí SPDY dva druhy rámců – řídicí (Control) a datové (Data), které obsahují i identifikátor streamu.

S HTTP je možné použít datovou kompresi na samotný obsah, na přenášená data. Ve SPDY je komprese automatická a komprimována nejsou pouze přenášená data, ale i hlavičky (SPDY má předdefinovaný slovník).

V případě, že je potřeba přenést větší množství souborů a spojení není příliš dobré, může klient poslat víc požadavků naráz a určit jejich prioritu – např. může požadovat, aby byly přednostně zpracovány požadavky na HTML stránky, pak teprve CSS a nakonec JS.

Konečně může server, díky obousměrné komunikaci, poslat soubor, o němž ví, že jej klient bude požadovat, dřív než klient požadavek pošle – např. může poslat obrázky dřív, než klient zpracuje HTML a vygeneruje patřičné požadavky.

Technicky…

Pro tvůrce stránek či webového vývojáře se nic nemění – dál může používat známé HTTP metody a protokol tak, jak je zvyklý. Google tvrdí, že SPDY není náhražka HTTP, ale jeho vylepšení v určitých místech, které se týkají především přenosu dat. Jeho umístění v „HTTP stacku“ naznačí následující obrázek:


Google

http://www.chromium.org/spdy/spdy-whitepaper

SPDY v praxi

První zprávy o SPDY proběhly na českém webu v listopadu 2009 (např. CW). Zmiňovaly se o tom, že Google implementoval SPDY na svých serverech a v prohlížeči Chrome, a že podle samotného Google bude klíčová především podpora ze strany dalších tvůrců prohlížečů.

Po téměř roce a půl je situace lepší jen nepatrně. Podpora v prohlížeči Chrome zůstala, u serverů Google také – takže pokud se připojujete z Chrome na nějakou Google službu, je pravděpodobné, že používáte SPDY (někteří v této souvislosti připomínají i nedávné „odstranění“ řetězce „http://“ z adresního řádku Chrome). Ostatní prohlížeče se neangažují.

Vznikl modul pro Apache (mod_spdy), Javuimplementace v Pythonu, implementace pro Node.js nebo Ruby gem. Tedy žádné výrazné kroky. Google nabízí několik nástrojů pro práci se SPDY.

Potká SPDY osud některých dalších Google technologií, které byly technologicky převratné, ale trh je nepřijal (příklad za všechny: Google Wave)? Zatím tomu nic nenasvědčuje – ale nic nenasvědčuje ani tomu, že by o něj měl trh zájem. Nabízí se tak otázka: je o podobný protokol vůbec zájem?

Alternativy

SPDY není jediný pokus zrychlit pomalu zastarávající HTTP. Jeden z významnějších pokusů je např. HTTP over SCTP, který staví nikoli nad TCP, ale nad rychlejší alternativou SCTP.

Další možnost je např. protokol Waka, který je pokusem o „binární náhradu za HTTP, založenou na tokenech“. Waka je, slovy Marka Nottinghama z Yahoo, sice „vaporwarespec“, ale přesto přináší některé nové zajímavé myšlenky. Ovšem do doby, než budou široce podporované, si vystačíme s HTTP, protože to, co dělat má, dělá obstojně, uzavírá Nottingham.

K tématu též: Life beyond HTTP1.1 / Igvita

Komentáře

Subscribe
Upozornit na
guest
28 Komentářů
Nejstarší
Nejnovější Most Voted
Inline Feedbacks
View all comments
honzamac

Pěkné, o tom jsem nevěděl.
Máte pravdu, na servery googlu toto spojení využívá SPDY (měřeno wiresharkem).
Je na SPDY napsané RFC? Zajímalo by mě, co na to říkají ostatní odborníci nezaujatí googlem…

honzamac

Spíš jsem myslel, že by tu implementaci SPDY třeba ještě navrhli trochu jinak, lépe nebo logičtěji. Já odborník nejsem.

petr, brno

pravda, od pohledu je nase mapova aplikace s google api rychlejsi v chrome nez treba ff4. laicke zrychleni „od pohledu“ cca 50%. parada.

LS_999

O SPDY nevim nic. Ale mozna by googlu pomohlo, kdyby misto vyvijeni takovychto veci radsi konecne vyvinul poradny flashblock pro jejich hypersuper-rychly-prohlizec chrome. Protoze bez flashblocku je to porad subjektivne pomalejsi nez
moloch firefox s flashblockem. Ano, stranka se mozna nacte mega rychle, ale co z toho, kdyz pak ty flash reklamy, co casto vytezuji procesor na 50-100% brani v dalsi praci/zabave… (takze chrome ne…)
Anebo nekdo zna pro toto dobre, tj. robustni reseni? (Instalovat exeprimentalni verze se mi nechce)

Jirka

Vy asi neumíte používat vyhledávače, že:

https://chrome.google.com/extensions/search?itemlang=&hl=cs&q=flashblock

LS_999

Ok, ale komentare k tomuto rozsireni nezneji nejlepe – zpomaluje nacitani stranek, neblokuje vse, atd.

helb

Chromium (a Chrome nejspíš taky) už to umí i bez rozšíření. Na stránce about:flags stačí zapnout „Click to play“…

volani.webnode.cz

To je hezké, je i něco takového i ve firefoxu? (že bych nemusel mtí zaplý flasblocker..)

LP

Nejjednodušší a nejspolehlivější je odinstalovat Flash Player, popř. ho vypnout jako rozšíření. Já mám Flash pouze v IE a když ho někdy opravdu potřebuji (přibližně dvakrát týdně), tak si spustím IE. Počítač používám na práci.

Viktor

WAKA je predevsim pokus R.T.Fieldinga o idealni protokol vzhledem k ‚jeho‘ RESTu a sam o ni tvrdi ze ma vse pouze v hlave ale neexistuje ani prototyp;

Sten

Jestli jsem to pochopil dobře, jde o obyčejné multiplexování s podporou komprese jednotlivých streamů. Takže v podstatě malinko vylepšený <a href“http://w­ww.w3.org/Pro­tocols/MUX/WD-mux-980722.html“>draf­tový protokol WebMUX od W3.

dexter

Muzu se prosim zeptat co je to ta ‚Data URL‘ ?

Sten

Je to možnost, jak vkládat data přímo do URI: http://en.wikipedia.org/wiki/Data_URI_scheme

j

A je to samozrejme uplna pitomost, specielne v pripade obrazku, protoze externi obrazek si prohlizec stahnout muze, ale nemusi, kdezto toto si stahnouot chte nechte musi vzdy.

Franta

Což ještě neznamená, že je to blbost nebo že by takový standard neměl existovat — někdy se to může hodit.
https://frantovo.cz/blog/?q=vlozeni-obrazku-primo-do-xhtml

gilhad

Kdyz mam vypnute stahovani obrazku, tak ocenim, ze se zadne obrazky nestahujou. Web je potom mnohem rychlejsi a pohodlnejsi. Takze nestojim o to, aby me nekdo zdrzoval tim, ze mi bude cpat kraviny, ktere nechci.

Jerry12

Z pohledu koncepce je to trochu prasarna, ale vazne to zrychluje nacitani. Nevim jak ted, ale google tohle „svinstvo“ pouzival vsude kde moh. Cely google images na tom stojej.

j

Casto staci, pokud vyvojar webu neni idiot a rychlost se muze zvednout nekolikanasobne, tomu ovsem zadny protokol nepomuze. Uz jen takova prkotina jako desitky kB CSS primo v html => stahuje se to pri kazdym reloadu stranky znovu a znovu. Vetsina webu neumi prohlizeci ric ze se cosi zmenilo a tak radsi vsichni nastavuji nocache …

Nox

Lepší jak drátem do voka a těm normálním webdeveloperům to pomůže, tak proč ne…

ondra.novacisko.cz

Je to zbytečně vyplácaný čas. Né že by mě to už nenapadlo, ale to už někdy v roce 2003 při jiné příležitosti (přenášení nějakých dat ve více streamech). Ta vyplácaná energie nepřinesla o moc větší výkon než prostě jen otevřít víc konekcí současně. Jediným efektem tak může být jen virtuálně snížený počet potřebných systémových prostředků na straně serveru. A to bych viděl jako hlavní motivaci Google.

Nox

A co je na tom špatného? Navíc je to Googlův čas, můžou s ním naložit jak chtějí

Samoúčelné brblání okořeněné trochou sebechvály…

pi.em

Nechápu proč google zahazuje čas nad vymýšlením již vymyšleného. Již několik let je standardizován transportní protokol SCTP, který byl vyvinut právě za účelem přenášení více streamů v rámci jednoho spojení.
SCTP umí i jiné vychytávky (multihoming ap.) včetně případného šifrování. Kdyby se Google místo vymýšlení nových protokolů věnoval prosazení již existujících, udělal by lépe.

edison

bohuzel soucasne implementace SCTP je skoro nepouzitelna, tolik zabugovanej protokol sem jeste nevidel.

František Kučera

Co konkrétně a která implementace? (nerýpu, upřímně mě to zajímá :-)

pi.em

Testoval jsem 3 implementace (pro Linux, Windows a FreeBSD), „základní“ funkce jely. Zabugované to dost možná je, jelikož to není ve středu zájmu (nikdo to nepoužívá, neladí).
SCTP byl primárně vyvinut pro účely signalizace mezi tel. ústřednami, později byly implementovány stacky pro používané OS.
V rozumných síťových zařízení jsem již SCTP podporu viděl (konkrétně Fortigate protokol SCTP zná).
Kvůli diplomové práci jsem si pročítal RFC k SCTP a dle mého názoru je to papírově vyzrálejší protokol než TCP či UDP. Bohužel nejsou důvody k rozšíření tohoto protokolu (TCP nebo UDP stále dostačuje).

Opravdový odborník :-)

a pak že to nejde :-) díky za pěkný článek o zajímavých technologiích

Brud

Uz ste tohle nekdo aspon videl z vlaku prinasazovani ve velkem prostredi ?

Enum a statická analýza kódu

Mám jednu univerzální radu pro začínající programátorty. V učení sice neexistují rychlé zkratky, ovšem tuhle radu můžete snadno začít používat a zrychlit tak tempo učení. Tou tajemnou ingrediencí je statická analýza kódu. Ukážeme si to na příkladu enum.

Pocta C64

Za prvopočátek své programátorské kariéry vděčím počítači Commodore 64. Tehdy jsem genialitu návrhu nemohl docenit. Dnes dokážu lehce nahlédnout pod pokličku. Chtěl bych se o to s vámi podělit a vzdát mu hold.