Roberto Peon wrote: > Much of the improvement comes from the multiplexing+prioritization-- > since the browser can trust the server to fill the pipe with the > things the browser wants the most, it is free to issue requests as > soon as it knows that it needs them. Today, browsers will artificially > induce a delay in requests because it is vastly important that the > HTML and CSS arrive unimpeded. > > Also a factor is how quickly we open up the cwnd. Since the protocol > is multiplexing, it has more bytes to stuff down the pipe (and sooner > that it would with HTTP thanks to prioritization+multiplexing), and so > it opens cwnd more quickly. This is simplifying a bit.. but you get > the picture :) It's nice to see this confirmed. This is a major reason why I've been advocating multiplexing on the hybi list - it's HTTP pipelining done properly, as it should have been in the first place, so that it's (a) usable and (b) performs well for browser applications. (The other major reason for multiplexing is to give the browser (especially) and proxies/servers freedom to combine or separate connections - for exactly the kind of efficiencies you've described, when multiple pages and multiple separately-authored things per page are involved. It's very interesting that you found it's important for the server to prioritise response order, and that not doing so risks being slower than some browser heuristics with HTTP. -- Jamie
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.