Sounds great. I really like this pragmatic approach of doing things to improve user's experience that have a good chance of wide deployment. I'm also very interested in the goal to allow the server to initiate communication with the client. Would this be accomplished via bi-directional streams within the TCP connection - but the connection itself would still need to be initiated by the client? Meaning you haven't figured out a magical way to put an httpd on the client? Mike On Mon, Nov 16, 2009 at 7:54 PM, Roberto Peon <fenix at google.com> wrote: > That was only part of the savings, though it was certainly the most > significant savings for users with thin pipes. > 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 :) > -=R > > On Mon, Nov 16, 2009 at 7:40 PM, Mike Dierken <mike at dierken.com> wrote: >> >> Was the reduced page load time due to fewer TCP packets needing to be >> exchanged (due to smaller HTTP request and response headers)? >> >> Mike >> >> On Thu, Nov 12, 2009 at 7:00 PM, Roberto Peon <fenix at google.com> wrote: >> > http://sites.google.com/a/chromium.org/dev/spdy/spdy-whitepaper >> > Header compression resulted in an ~88% reduction in the size of request >> > headers and an ~85% reduction in the size of response headers. On the >> > lower-bandwidth DSL link, in which the upload link is only 375 Kbps, >> > request >> > header compression in particular, led to significant page load time >> > improvements for certain sites (i.e. those that issued large number of >> > resource requests). We found a reduction of 45 - 1142 ms in page load >> > time >> > simply due to header compression. >> > In other words, HTTP headers are so verbose that we get a large latency >> > reduction simply by gzipping them. If we did a delimiter-based framing, >> > we'd >> > have to ensure that the compressed data was not including >> > that delimiter, or >> > we'd have to give up on header compression entirely. Neither of these >> > options is particularly interesting. >> > Hopefully, we can publish some more data about this later-- We've done a >> > lot >> > of experimentation with dummynet+chrome+SPDY server on a lot of sites. >> > The >> > server assumed that every resource came back in 30ms, which is on the >> > fast >> > side, but that should have biased in favor of HTTP... We're trying to be >> > as >> > data driven as possible about this. >> > -=R >> > >> > On Thu, Nov 12, 2009 at 6:45 PM, Thomson, Martin >> > <Martin.Thomson at andrew.com> >> > wrote: >> >> >> >> It was interesting to hear the IAB opinions on this in relation to >> >> internationalization. The thesis was that the bulk of the web is video >> >> or >> >> some other efficiently encoded binary data and that text makes up a >> >> very >> >> small proportion of the data that is moved around. The purported costs >> >> of >> >> more verbose encodings (in this case of Unicode) were actually >> >> considered >> >> negligible when compared to the other benefits. >> >> >> >> >> >> >> >> Thus, I’d question whether these speed benefits are of any tangible >> >> benefit. Sure, we minify javascript and there are still >> >> bandwidth-limited >> >> devices that would benefit from some speed improvement, but I don’t see >> >> a >> >> binary protocol improving this situation significantly. And when I >> >> consider >> >> that some folks are getting better bandwidth on their mobiles than I >> >> get >> >> over my ADSL2+ connection at home, I wonder why we waste so much time >> >> on >> >> saving bits. >> >> >> >> >> >> >> >> Can anyone point to the studies on impact of HTTP header sizes on >> >> throughput, latency and overall bandwidth use? >> >> >> >> >> >> >> >> I’m also increasingly of the view that channels-based protocols aren’t >> >> necessarily the right way to solve head-of-line blocking problems. >> >> There >> >> are other methods that do not demand the same overheads. For instance, >> >> a >> >> simple request identifier can be used for request-response correlation. >> >> >> >> >> >> >> >> I’m actually more excited about the prospect of getting HTTP over SCTP. >> >> >> >> >> >> >> >> --Martin >> >> >> >> >> >> >> >> From: hybi-bounces at ietf.org [mailto:hybi-bounces at ietf.org] On Behalf Of >> >> Ian Fette (????????) >> >> Sent: Friday, 13 November 2009 11:00 AM >> >> To: Infinity Linden (Meadhbh Hamrick) >> >> Cc: hybi at ietf.org >> >> >> >> Subject: Re: [hybi] SPDY protocol from google frame >> >> >> >> >> >> >> >> The point of SPDY was to make the web faster. Billions of users >> >> requesting >> >> pages, want to speed it up. Of those billions of users, perhaps 100 >> >> care >> >> whether it's binary or ASCII. Using ASCII just so that it's easier for >> >> 100 >> >> people to look at the traffic on the wire without any "specialized >> >> tools" >> >> while slowing it down for billions of users seems like a strange >> >> tradeoff. >> >> >> >> 2009/11/12 Infinity Linden (Meadhbh Hamrick) <infinity at lindenlab.com> >> >> >> >> +1 ted >> >> >> >> >> >> >> >> i have to admit i'm a fan of text based protocols that use ASCII for >> >> headers, allow arbitrary length fields, and whose elements are >> >> delimited by >> >> ASCII characters. in the early days of my career, i was a fan of fixed >> >> length fields with binary elements. to be sure, there are definitely >> >> places >> >> where they are useful. but in my experience, when you're building >> >> something >> >> new, the benefits of extensibility and debuggability outweigh the >> >> drawbacks >> >> of dealing with larger, variable length messages that may require a >> >> little >> >> bit more coding to parse. >> >> >> >> >> >> >> >> <soapbox> >> >> >> >> >> >> >> >> but i am kind of curious.. if there are people on this list that prefer >> >> binary formats, i wonder, what are the characteristics you're trying to >> >> preserve? >> >> >> >> >> >> >> >> a. messages should be easy to parse? >> >> >> >> b. messages and message elements should be as small as possible? >> >> >> >> c. something else? >> >> >> >> >> >> >> >> the reason i ask it that i've had experience with building IIOP and SS7 >> >> implementations and debugging HTTP is waay more fun than IIOP. and by >> >> "fun" >> >> i mean that i'm less likely to drink heavily after a 24 hour debugging >> >> session. >> >> >> >> >> >> >> >> that being said... if i was building something for the telco ecosystem, >> >> and i needed to respond to messages in a small, deterministic amount of >> >> time, i would be interested in investigating where i would need to use >> >> fixed >> >> length fields in a binary message. (but i wouldn't like it.) >> >> >> >> >> >> >> >> it just seems to me that we're talking about bidirectional HTTP here; >> >> not >> >> BEEP or IIOP or SS7. HTTP is generally NOT a binary protocol. doesn't >> >> it >> >> make sense that a bidirectional version of it should also be ASCII/text >> >> based? you're going to have developers and tool chains that are >> >> probably >> >> going to assume that headers flowing across port 80 will be human >> >> comprehensible. and while i have no problem using binary encoding when >> >> it's >> >> needed... but... is it really needed here? >> >> >> >> >> >> >> >> do we really have use cases where the < 1% savings you get on message >> >> size >> >> by adding binary headers and protocol flow markers makes or breaks a >> >> service? >> >> >> >> >> >> >> >> </soapbox> >> >> >> >> >> >> >> >> -cheers >> >> >> >> -meadhbh >> >> >> >> >> >> >> >> -- >> >> infinity linden (aka meadhbh hamrick) * it's pronounced "maeve" >> >> http://wiki.secondlife.com/wiki/User:Infinity_Linden >> >> >> >> On Thu, Nov 12, 2009 at 16:25, Ted Goddard <ted.goddard at icesoft.com> >> >> wrote: >> >> >> >> It appears to be a binary framing protocol carrying >> >> an HTTP subset. The goals of the protocol match the >> >> BWTP "manifesto", so hopefully the SPDY authors will >> >> join this BOF. >> >> >> >> I still like the idea of text-based framing and metadata >> >> because it's easy to debug with telnet and tcpdump. >> >> For instance, BWTP header persistence is still human >> >> readable, would be very effective in terms of >> >> compression, and could be retrofitted for httpbis; >> >> whereas SPDY headers are compressed with gzip, resulting >> >> in effective compression but no savings in header >> >> encoding and decoding, and a random looking byte stream >> >> unless you have a specialized debug tool. >> >> >> >> It would be interesting to take a poll to see if people >> >> have a binary or a text-based protocol in mind. >> >> >> >> Ted. >> >> >> >> >> >> On 2009-11-12, at 4:24 PM, Greg Wilkins wrote: >> >> >> >> Lloyd Wood wrote: >> >> >> >> How does this compare to BEEP? >> >> >> >> From my quick look: >> >> >> >> + It's simpler than beep in channel management >> >> + It's addresses the header compactness issues >> >> + It is definitely bound to uber-http semantics, while beep is more >> >> general >> >> purpose (but could have a http binding defined). >> >> >> >> But in concept, it is not too far apart. It's using the same grab >> >> bag of techniques (multiplexed channels with fragmentation and orderly >> >> channel management) that Beep uses (and BWTP is advocating). >> >> >> >> cheers >> >> >> >> >> >> On 12 Nov 2009, at 22:05, Greg Wilkins wrote: >> >> >> >> FYI Google have announced some work they are doing on a HTTP >> >> improvement >> >> >> >> http://dev.chromium.org/spdy/spdy-whitepaper >> >> >> >> >> >> It appears to capture many of the same ideas I was attempting to with >> >> BWTP >> >> - but >> >> they are binary encoded and have working code :) >> >> >> >> cheers >> >> _______________________________________________ >> >> hybi mailing list >> >> hybi at ietf.org >> >> https://www.ietf.org/mailman/listinfo/hybi >> >> >> >> DTN work: http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/ >> >> >> >> <http://info.ee.surrey.ac.uk/Personal/L.Wood/><L.Wood at surrey.ac.uk> >> >> >> >> >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> >> hybi mailing list >> >> hybi at ietf.org >> >> https://www.ietf.org/mailman/listinfo/hybi >> >> >> >> _______________________________________________ >> >> hybi mailing list >> >> hybi at ietf.org >> >> https://www.ietf.org/mailman/listinfo/hybi >> >> >> >> >> >> >> >> _______________________________________________ >> >> hybi mailing list >> >> hybi at ietf.org >> >> https://www.ietf.org/mailman/listinfo/hybi >> >> >> >> >> >> >> >> _______________________________________________ >> >> hybi mailing list >> >> hybi at ietf.org >> >> https://www.ietf.org/mailman/listinfo/hybi >> >> >> > >> > >> > _______________________________________________ >> > hybi mailing list >> > hybi at ietf.org >> > https://www.ietf.org/mailman/listinfo/hybi >> > >> > > >
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.