Největší zabiják připojení je ping. U šifrovaného spojení se před zahájením komunikace provádí několik výměn během ověření, a tím je dané zpomalení. Proto pro HTTPS ty asi má smysl a něco to urychlí.
U HTTP ale takové urychlení nevidím. Browser naváže N spojení (může až 10 spojení paralelně, nicméně mám někdy pocit, že jedou tak 3-4) a přenos pak probíhá s nastaveným keep-alive, takže spojení se nezavírají. Většinou jde provádět i pipelining (dokud druhá strana jede v HTTP/1.1).
A teď námět k přemýšlení. Jakou režii má SPDY na paralelní přenos? Režii, kterou má TCP spojení nelze tímto způsobem snížit a TCP spojení paralelní přenos podporuje z principu. Nebude nakonec SPDY větší zátěž na přenosovou linku, než kdyby se data posílala paralelně po více spojení?
Není náhodou zpomalení HTTP tradičním způsobem jen důsledkem toho, že prohlížeče neumí hospodařit s otevřenými linkami. Například na stahování obrázku by klidně stačily dvě spojení. Pokud má spojení delší prodlevu, mohu navázat další spojení a stáhnout něco co má vyšší prioritu. Jenže prohlížeče tohle nedělají a obávám se, že se SPDY to dělat nebudou.
Hlavní benefit vidím v tom, že SPDY šetří prostředky na serveru. Avšak, namísto vymýšlení protokolu by stačilo popřemýšlet, jak optimalizovat server pro větší množství spojení. Není možné se držet jen zaběhnutých schemat ve stylu "linux to neumí, tak to nejde".
