On Thu, 2012-05-24 at 08:54 -0700, [email protected] wrote: > issue. I'm not sure what that number is in Firefox right now, but at > least traditionally it's been lower than we've been comfortable with.
it's 6 - same as chrome and ie. > To get around the limit, we open each hanging GET to a different > numbered subdomain of docs.google.com. "sharding" we call it. one of the goals for spdy is to allow enough parallelism that you don't need to do that - cause it really sucks in many ways :) > When we first tried this technique in Chrome, it disagreed with their > SPDY implementation. When SPDY in Chrome is active, the per-origin > connection limit is lifted to a much higher number, the maximum stream > count on the SPDY connection. In firefox we look at it like this: you still have the limit of 6 connections its just that you can do parallel work on a single connection so we are incented to not use them all. and if everything is well established its true you will only be using one of them but there are times you will have more than 1 connection open and active to the same host. (but probably only 1 of them is starting new work). There is also an ip pooling concept that is used to automatically de-shard. (like I said, sharding sucks - and once you have spdy's parallelism you don't need it anymore). For two hosts to be de-sharded into one they must share the same IP address and have SSL certs that cover the "redirected" host (e.g. *.google.com). You should be able to continue to use the sharded names without a problem in a spdy context - spdy will basically undo that for you in firefox. (there are some race conditions here, because 1] we can't unshard in a non-spdy context and, 2] we don't serialize all connections, and 3] we can't know if the host is spdy or not without a connection. So sometimes sharding still happens in a spdy context, but we try and shut down those connections and move new transactions to the preferred host as quickly as we can.) > may have completely different characteristics. I haven't actually > tested our solution on Firefox/SPDY yet, so I'm not sure. I'm not sure either, because to be honest I can't quite follow your story of where the failure happened on chrome. I have the gist of it - but not all the specifics. If its important please try again in step by step detail. I'm interested. > to work out whether I've conducted a valid test - hopefully the use > of SPDY at least shows up in firebug or some other debugging tool? > I'd hate to be getting out my packet sniffer :-) on FF, there is a fake response header injected into each transaction that was done over spdy: X-Firefox-Spdy.. you can't get to it with normal priv JS, but you can see it in the developer tools (ctrl-shift-k), with the live http headers add-on, or with firebug. > The use of random subdomains to circumvent connection limits has > costs. DNS lookups are needed, and it defeats SPDY's ability to > establish multiple http connections over one TCP connection. like I said, firefox and chrome (iirc) try and undo the sharding automatically. The costs are worse than you state - its bad for congestion control, bufferbloat, resource prioritization, and fast tcp loss recovery too. The DNS aspect is one place where this auto-unsharding doesn't help. if we were going to put transport information (protocol, version level, etc.. ) into the dom I'd want to take a cue from boris or jonas on where and how. _______________________________________________ dev-tech-network mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-network
