- From: Peter L <bizzbyster@gmail.com>
- Date: Fri, 30 Mar 2012 09:43:53 -0400
- To: <ietf-http-wg@w3.org>
- Message-ID: <02a401cd0e7b$26b513e0$741f3ba0$@gmail.com>
Responding to Ross and Brian's posts mainly here...
I agree that increasing concurrent connections will increase the burden on
web servers and that is a serious issue for sure but since so many sites are
already working around the 6 per domain limit via sharding, most site owners
are willing to accept higher numbers of TCP connections if it results in
faster page loads. Prevalence of domain sharding is a kind of vote in the
direction of increasing the per domain limit.
Transparency:
. SPDY compresses HTTP headers using an LZ history based algorithm,
which means that previous bytes are used to compress subsequent bytes. So
any packet capture that does not include all the traffic sent over that
connection will be completely opaque -- no mathematical way to decode the
HTTP. Even with all the traffic, a stream decoder will be a tricky thing to
build b/c packets depend on each other.
. Loss of transparency impacts intermediary devices (reverse
proxies, caches, layer 7 switches, load balancers) as much as it does packet
capture analysis. For load balancing, multiplexing requires maintaining
state from one request to the next so individual object requests from a
given user will need to be handled by the same de-multiplexing server. In
general, increasing session orientation reduces the scalability of the
overall service. Also, failover is less graceful as a load balancer will
want to be more sure that the previously used server is in fact unavailable
before routing to a new server.
. SSL kills transparency at the network level completely but also I
think that SSL should be considered as an orthogonal thing to performance.
So that site owners can make a decision based on the cost, security,
performance tradeoffs of going to all encrypted traffic. So while I agree
it's related, it seems like we have to consider these things independently.
Increased Object Processing Latency:
. Multiplexing requires that objects are encoded serially -- encode
(Object1), encode (Object2), encode (Object3) -- and then decoded in that
same order. On a multi-core server, the three objects arrive truly
concurrently, but due to multiplexing Object2 and Object3 will need to wait
while Object1 is encoded. For SPDY, that encode step involves running an
LZ-type coding function including searching the recent bytes for matches so
even on an unloaded server this can add ~milliseconds of latency.
. Multiplexing creates the need for session state. Access to this
state needs to be synchronized, thread synchronization reduces parallelism
and so impacts server scalability and per object latency.
. CPU gains are increasingly achieved by adding cores and not making
existing cores go faster. So processes that can run concurrently are
friendly to these advances (such as increasing concurrent TCP connections)
and multiplexing goes in the opposite direction -- requiring thread
synchronization and so increasing serialization, and context switching.
Thanks,
Peter
From: J Ross Nicoll [mailto:jrn@jrn.me.uk]
Sent: Friday, March 30, 2012 5:47 AM
To: Peter L
Cc: ietf-http-wg@w3.org
Subject: Re: multiplexing -- don't do it
I would consider the congestion/window benefits that Brian raised the main
benefits, personally. To address a couple of the issues you've raised:
Transparency; whatever tools you're using to monitor network traffic will
already be pulling individual connections out of a mixture of packets. It
does mean those tools will need to pull apart another layer to be able to
see the individual content being sent, but I'm not imagining this to be a
significant hurdle. I would also point out that there's discussion about
HTTP 2.0 being SSL only (and I believe "encouraged to be SSL where at all
possible" is the main alternative), and that would impact network
transparency a lot more than multiplexing!
Load balancing; do you have cases where individual user load requires
balancing? I'm not aware of any common cases where high web server load is
caused by individual users, but typically by a large number of users in
aggregate. Multiplexing would mean each user's requests would likely go to a
single server, but users should still be easily re-distributable across a
cluster of servers.
Increased object processing latency; sorry, I'm not sure why this would be
the case?
Ross
On 30/03/2012 03:07, Peter L wrote:
I'm new to this list but have been studying web performance over high
latency networks for many years and multiplexing seems to me like the wrong
way to go. The main benefit of multiplexing is to work around the 6
connections per domain limit but it reduces transparency on the network,
decreases the granularity/modularity of load balancing and increases object
processing latency in general on the back end as everything has to pass
through the same multiplexer, and introduces its own intractable
inefficiencies. In particular the handling of a low priority in flight
object ahead of a high priority object when packet loss is present is a step
backwards from what we have today for sites that get beyond the 6
connections per domain limit via domain sharding. Why not just introduce an
option in HTTP 2.0 that allows clients and servers to negotiate max
concurrent connections per domain? When web sites shard domains, aren't they
essentially telling the browser that they will happily accept lots more
connections? I'm sure this suggestion has long since been shot down but
browsing around on the web I'm not finding it.
As for header compression, again this is a trade-off between
transparency/multiple streams and bandwidth savings. But I'd think this
group could come up with ways to reduce the bytes in the protocol (including
cookies) without requiring the use of a single compression history,
resulting in an order-sensitive multiplexed stream.
Thanks,
Peter
On Thu, Mar 29, 2012 at 9:26 AM, Mike Belshe <mike@belshe.com> wrote:
I thought the goal was to figure out HTTP/2.0; I hope that the goals of SPDY
are in-line with the goals of HTTP/2.0, and that ultimately SPDY just goes
away.
Mike
On Thu, Mar 29, 2012 at 2:22 PM, Willy Tarreau <w@1wt.eu> wrote:
Hello,
after seeing all the disagreements that were expressed on the list these
days (including from me) about what feature from SPDY we'd like to have
mandatory or not in HTTP, I'm thinking that part of the issue comes from
the fact that there are a number of different usages of HTTP right now,
all of them fairly legitimate.
First I think that everyone here agrees that something needs to be done
to improve end user experience especially in the mobile networks. And
this is reflected by all proposals, including the http-ng draft from
14 years ago!
Second, the privacy issues are a mess because we try to address a social
problem by technical means. It's impossible to decide on a protocol if
we all give an example of what we'd like to protect and what we'd prefer
not to protect because it is useless and possibly counter-productive.
And precisely, some of the disagreement comes from the fact that we're
trying to see these impacts on the infrastructure we know today, which
would obviously be a total breakage. As PHK said it, a number of sites
will not want to afford crypto for privacy. I too know some sites which
would significantly increase their operating costs by doing so. But
what we're designing is not for now but for tomorrow.
What I think is that anyway we need a smooth upgrade path from current
HTTP/1.1 infrastructure and what will constitute the web tomorrow without
making any bigbang.
SPDY specifically addresses issues observed between the browser and the
server-side infrastructure. Some of its mandatory features are probably
not desirable past the server-side frontend *right now* (basically
whatever addresses latency and privacy concerns). Still, it would be
too bad not to make the server side infrastructure benefit from a good
lifting by progressively migrating from 1.1 to 2.0.
What does this mean ? Simply that we have to consider HTTP/2.0 as a
subset of SPDY or that SPDY should be an add-on to HTTP. And that
makes a lot of sense. First, SPDY already is an optimized messaging
alternative to HTTP. It carries HTTP/1.1, it can as well carry HTTP/2.0
since we're supposed to maintain compatible semantics.
We could then get to a point where :
- an http:// scheme indicates a connection to HTTP/1.x or 2.x server
- an https:// scheme indicates a connection to HTTP/1.x or 2.x server
via an SSL/TLS layer
- a spdy:// scheme indicates a connection to HTTP/1.x or 2.x server
via a SPDY layer
By having HTTP/2.0 upgradable from 1.1, this split is natural :
+----------------------------+
| Application |
+----+-----------------------+
| WS | HTTP/2.0 |
+----+--------------+ |
| HTTP/1.1 | |
| +-----+---+--------+
| | TLS | SPDY |
+---------+-----+------------+ server-side
^ ^ ^
| | |
| | |
| | |
+---------+-----+------------+ user-agent
| | TLS | SPDY |
| +-----+-------+----+
| HTTP/1.1, 2.0 | |
+-------------------+---+ |
| | WS |
| Applications +--------+
| |
+----------------------------+
The upgrade path would then be much easier :
1) have browsers, intermediaries and servers progressively
adopt HTTP/2.0 and support a seamless upgrade
2) have browsers, some intermediaries and some servers
progressively adopt SPDY for the front-line
3) have a lot of web sites offer URLs as spdy:// instead of http://,
and implement mandatory redirects from http:// to spdy:// like a
few sites are currently doing (eg: twitter)
4) have browsers at some point use the SPDY as the default scheme
for any domain name typed on the URL bar.
5) have browsers at one point disable by default transparent support
for the old http:// scheme (eg: put a warning or have to tweak
some settings for this). This will probably 10-20 years from now.
Before we get to point 5, we'd have a number of sites running on the
new protocol, with an efficient HTTP/2.0 deployed at many places
including the backoffice, and with SPDY used by web browsers for
improved performance/privacy. That will not prevent specific agents
from still only using a simpler HTTP/2.0 for some uses.
So I think that what we should do is to distinguish between what is
really desirable to have in HTTP and what is contentious. Everything
which increases costs or causes trouble for *some* use cases should
not be mandatory in HTTP but would be in the SPDY layer (as it is
today BTW).
I think that the current SPDY+HTTP mix has shown that the two protocols
are complementary and can be efficient together. Still we can significantly
improve HTTP to make both benefit from this, starting with the backoffice
infrastructure where most of the requests lie.
Willy
Received on Friday, 30 March 2012 13:44:32 UTC