- From: J Ross Nicoll <jrn@jrn.me.uk>
- Date: Fri, 30 Mar 2012 10:46:41 +0100
- To: Peter L <bizzbyster@gmail.com>
- CC: ietf-http-wg@w3.org
- Message-ID: <4F758101.1020603@jrn.me.uk>
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 > <mailto: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 > <mailto: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 09:47:13 UTC