RE: HTTP 2.0 and a Faster, more Mobile-friendly web

On Aug 1, 2012 6:47 AM, "Jitu Padhye" <padhye@microsoft.com> wrote:
> We have done a bit of work on looking at how SPDY works for apps (mostly
simple trace analysis), but we don’t have anything significant to report
yet. But this is indeed something that needs looking into.

The use case where SPDY should offer an advantage is when many requests are
in transit concurrently and there is significant variability in response
times.
Responsiveness of both http and SPDY will depend on the protocol stack's
ability to keep the TCP buffer full of messages, and the real test cases
might be between proxies at the edges of data centres or on other high
volume links.

I have had success with pipelined http as part of SCADA user interfaces. In
this use case we want to bring up a display containing ten thousand
individual data points that each have individual urls. With ordinary
pipelined http/1.1 and a good http implementation I can complete the
initial GET requests plus establish subscriptions and perform all rendering
within a couple of seconds on commodity hardware. In this case response
times are very consistent so server push aside SPDY should not offer
significant raw performance improvement. For workloads with variable
response times I use draft- mogul- http- ooo- 00, which works very well
when supported consistently across the architecture.

I wonder a little as to whether browser protocol stacks will be
appropriately tuned for high message loads to provide good baseline http
figures. A fairer comparison might be obtained by essentially dumping bytes
across the network and comparing on that basis. Alternatively SPDY should
be compared not to http but instead to existing enterprise message queuing
protocols.

In fact when it comes down to it if we're defining a new http primarily for
the purposes of improving performance then existing http isn't really a
good baseline. Instead we should probably be looking at the best performing
available protocols and comparing against those as baselines. It's
potentially very easy to be faster. The question is have we achieved "fast"
such that it would be pointless for anyone to build and use custom
protocols in place of http for transporting http message content except in
extreme cases? I think enterprise experience as to what constitutes "fast"
or "fast enough" and what constitutes an ordinary workload should be
considered.

Benjamin