I come not to praise SPDY, but to bury it...
On 11/19/09 11:58 PM, Karsten Elfenbein wrote:
Hi,
I still don't seen any real advantage of spdy over http/1.1 with pipelining.
google addresses some of those objections in their docs, example:
(HTTP pipelining helps, but still enforces only a FIFO queue), a server
delay of 500 ms prevents reuse of the TCP channel for additional requests.
and later:
========
Q: Doesn't HTTP pipelining already solve the latency problem?
A: No. While pipelining does allow for multiple requests to be sent in
parallel over a single TCP stream, it is still but a single stream. Any
delays in the processing of anything in the stream (either a long request at
the head-of-line or packet loss) will delay the entire stream. Pipelining has
proven difficult to deploy, and because of this remains disabled by default in
all of the major browsers.
========
The other thing is header compression and header deduping for a connection,
could be huge savings. I notice that especially and somewhat ironically, the
requests coming from devices/wap gateways have lots of long headers, over and
over with each request. SPDY seems very interesting where there are high tcp
latencies and/or packet loss (the savings in time for SPDY over HTTP improve
with increased tcp latency) both a common situation in wap networks. If/when
google comes out with their handset with SPDY support for all their
sites/services it will have market advantage over other devices in terms of
performance unless telecoms can figure out how to throttle/choke it.
Maybe the issues with pipelining should be addressed first in the browser to
webserver chain.
I think if google implements SPDY in Chrome, there is less chance they will do
a lot of work on more pipelining code in the browser. They and others have
already decided to just open a few more simultaneous connections as the solution.
The other big issue in relation to haproxy is currently the keepalive support
as only the first header of a connection is used for L7 inspection.
Breaking that up to support keepalive and pipelining would be a big issue.
(one connection could result in different backends to deliver the content)
(SSL/TLS would be nice to have while we are talking about that :) )
I thought both of those were part of the things that would be more do-able
(and were being worked on) with the re-architecting happening in 1.4
Maybe I misunderstood.
Also while translating spdy:// to http:// you would run into issues with the
backend app needs to output spdy:// links on a http:// request.
Good point that may be an unovercome-able issue.
Am Freitag, 20. November 2009 schrieben Sie:
I am not sure if people are aware of a proposed new protocol for web from
google called SPDY.
