Bude web rychlejší s protokolem SPDY?

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?

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

Začal programovat v roce 1984 s programovatelnou kalkulačkou. Pokračoval k BASICu, assembleru Z80, Forthu, Pascalu, Céčku, dalším assemblerům, před časem v PHP a teď by rád neprogramoval a radši se věnoval starým počítačům.

Věděli jste, že nám můžete zasílat zprávičky? (Jen pro přihlášené.)

Komentáře: 28

Přehled komentářů

honzamac Re: Bude web rychlejší s protokolem SPDY?
Martin Malý Re: Bude web rychlejší s protokolem SPDY?
honzamac Re: Bude web rychlejší s protokolem SPDY?
petr, brno google map api
LS_999 Trosku OT o rychlosti - co kdyby google radsi vyvinul poradny flashblock?
Jirka Re: Trosku OT o rychlosti - co kdyby google radsi vyvinul poradny flashblock?
LS_999 Re: Trosku OT o rychlosti - co kdyby google radsi vyvinul poradny flashblock?
helb Re: Trosku OT o rychlosti - co kdyby google radsi vyvinul poradny flashblock?
volani.webnode.cz Re: Trosku OT o rychlosti - co kdyby google radsi vyvinul poradny flashblock?
LP Re: Trosku OT o rychlosti - co kdyby google radsi vyvinul poradny flashblock?
Viktor WAKA
Sten Obyčejný multiplex
dexter Data URL
Sten Re: Data URL
j Re: Data URL
Franta Re: Data URL
gilhad Re: Data URL
Jerry12 Re: Data URL
j webdeveloperi
Nox Re: webdeveloperi
ondra.novacisko.cz Zbytečně vyplácaný čas
Nox Re: Zbytečně vyplácaný čas
pi.em Analogie s protokolem SCTP
edison Re: Analogie s protokolem SCTP
František Kučera Re: Analogie s protokolem SCTP
pi.em Re: Analogie s protokolem SCTP
Opravdový odborník :-) díky
Brud SCPT
Zdroj: https://www.zdrojak.cz/?p=3484