5 ms·

> And when the entire exchange consists of a few hundred bytes (which the server can answer with a 304 Not Modified), that seems like a substantial win. What ar

> And when the entire exchange consists of a few hundred bytes (which the server can answer with a 304 Not Modified), that seems like a substantial win. What argument do you have against doing this? Turn this around. What's the argument for doing it? "The gain using our proposed initial dictionary is seen only for the first header". This is completely counter to the goal of Spdy to keep connections open and reuse them; the longer connections are used the less the initial dictionary matters. Even just visiting one page, average say 500 KiB, it save on average 121 bytes total. That's 0.02% reduction in size. This seems like a "substantial win"? Meanwhile how many version of the dictionary are there so far? 5? 10? And they propose that it will evolve over time, so that will just keep growing with software everywhere having dozens of legacy dictionaries. > Also, HTTP pipelining requires answering requests in order, while SPDY doesn't, allowing the server to respond to requests as data becomes available. This is why metrics are important. By ignoring pipelining because of perceived problems, the authors are basing their protocol on assumptions. This assumption is that in the real world the 'head of line blocking' is a significant factor. Judging by 0.02% average gain from prefix dictionaries, I don't give them the benefit of the doubt that their assumptions are correct. But I see that Chrome 17 has some type of pipelining support, so maybe they will actually test this someday. > If I request a page generated by an expensive CGI, the server can go ahead and send me the CSS and JavaScript it knows all pages will reference ... Yes if the very first request is an expensive CGI this may be some marginal benefit. I think even the Spdy designers claimed this was less than 1% and sometimes a loss. This happens very often, that the first page requested from a site has some really slow loading CGI? I think the site is broken.

JoshTriplett 15y ago
> Turn this around. What's the argument for doing it? "The gain using our proposed initial dictionary is seen only for the first header". This is completely counter to the goal of Spdy to keep connections open and reuse them; the longer connections are used the less the initial dictionary matters. Browsers won't keep SPDY connections open forever in the hopes of someday reusing them; the "initial connection" case will happen quite frequently in a normal browsing session. > Even just visiting one page, average say 500 KiB, it save on average 121 bytes total. That's 0.02% reduction in size. This seems like a "substantial win"? When did you last visit a page with 500k of HTML? I suggested the hopefully very common case of sending a very small request and getting back a very small 304. The whole exchange consists entirely of headers; I just checked a few examples and got figures in the 300-400 byte range for request and response combined. That would make 121 bytes closer to a 30-40% savings. (Also, I'd love to see a reference for your figures on expected bytes saved through the prefix dictionary.) > Yes if the very first request is an expensive CGI this may be some marginal benefit. I think even the Spdy designers claimed this was less than 1% and sometimes a loss. This happens very often, that the first page requested from a site has some really slow loading CGI? I think the site is broken. Server push seems like a win at any point in a SPDY connection, not just for the initial connection.
- 0xABADC0DA 15y ago
  > Browsers won't keep SPDY connections open forever in the hopes of someday reusing them; the "initial connection" case will happen quite frequently in a normal browsing session. This is what boggles my mind about Spdy, the dissonance. On the one hand Spdy is great because it does a bunch of requests on the same TCP connection, but on the other hand Spdy is great because it saves 100 bytes per connection and that's a big deal because there are going to be so many connections made? It doesn't make sense. Spdy is great because it has compression, but on the other hand Spdy is great because it requires SSL which already has compression. Huh? > I suggested the hopefully very common case of sending a very small request and getting back a very small 304. ... The whole exchange consists entirely of headers ... That would make 121 bytes closer to a 30-40% savings. On a first request only. You visit some site and only check if exactly one resource? Not likely. In any case, the cost to transfer 100 bytes once is irrelevant in any grand scheme of things. > (Also, I'd love to see a reference for your figures on expected bytes saved through the prefix dictionary.) http://www.eecis.udel.edu/~amer/PEL/poc/pdf/SPDY-Fan.pdf http://www.eecis.udel.edu/~amer/PEL/poc/pdf/SPDY-Fan.pdf The dictionary construction part is suspect though... take a look at how many times the same string length count (\0\0\0\4 for example) occurs in the prefix -- this can't be optimal.
  - JoshTriplett 15y ago
    > This is what boggles my mind about Spdy, the dissonance. On the one hand Spdy is great because it does a bunch of requests on the same TCP connection, but on the other hand Spdy is great because it saves 100 bytes per connection and that's a big deal because there are going to be so many connections made? It doesn't make sense. Adaptability: SPDY works well for both cases, rather than only picking one case and optimizing for that case alone. I see quite a bit of value in optimizing SPDY for a pile of short single-request connections to sites, as well as optimizing for numerous requests to the same site. Google's own site will serve numerous examples of both; see below. > On a first request only. You visit some site and only check if exactly one resource? Not likely. In any case, the cost to transfer 100 bytes once is irrelevant in any grand scheme of things. It costs nothing to initialize the compressor state differently, and saves 100+ bytes per initial request/response. A quick search suggests that Google services several billion searches per day. Assume for the moment that a substantial fraction of those searches come from user agents that don't already have an open connection to Google. Starting the compressor out with a specific state based on a prefix dictionary costs nothing (just changing the initial state of the compressor), but saves 100+ bytes per initial request/response. So, just for Google alone that change could save on the order of 100GB of traffic per day, for something that costs browsers and servers nothing to do. Now multiply that out for every other site on the Internet. And for a different approach, consider the total number of initial connections that take place on GSM/3G networks every day. More importantly than bandwidth, saving 100 bytes provides a potentially substantial latency benefit for the initial response, making it that much more likely to fit into a single frame rather than fragmenting. If SPDY can save 100 bytes for free, why not do it? > http://www.eecis.udel.edu/~amer/PEL/poc/pdf/SPDY-Fan.pdf http://www.eecis.udel.edu/~amer/PEL/poc/pdf/SPDY-Fan.pdf Thanks for the reference! That paper seems to compare their proposed dictionary to "SPDY’s current default initial dictionary", which as far as I can tell means the prefix dictionary from some iteration of SPDY, rather than zlib's default. I don't think the paper provides statistics on how much a prefix dictionary saves over not having one at all. > The dictionary construction part is suspect though... take a look at how many times the same string length count (\0\0\0\4 for example) occurs in the prefix -- this can't be optimal. I agree that the default dictionary could probably use work. That kind of work seems like the most likely reason for the several versions of prefix dictionaries that have appeared so far, which you complained about in a previous comment. :)

JoshTriplett 15y ago

> Turn this around. What's the argument for doing it? "The gain using our proposed initial dictionary is seen only for the first header". This is completely counter to the goal of Spdy to keep connections open and reuse them; the longer connections are used the less the initial dictionary matters. Browsers won't keep SPDY connections open forever in the hopes of someday reusing them; the "initial connection" case will happen quite frequently in a normal browsing session. > Even just visiting one page, average say 500 KiB, it save on average 121 bytes total. That's 0.02% reduction in size. This seems like a "substantial win"? When did you last visit a page with 500k of HTML? I suggested the hopefully very common case of sending a very small request and getting back a very small 304. The whole exchange consists entirely of headers; I just checked a few examples and got figures in the 300-400 byte range for request and response combined. That would make 121 bytes closer to a 30-40% savings. (Also, I'd love to see a reference for your figures on expected bytes saved through the prefix dictionary.) > Yes if the very first request is an expensive CGI this may be some marginal benefit. I think even the Spdy designers claimed this was less than 1% and sometimes a loss. This happens very often, that the first page requested from a site has some really slow loading CGI? I think the site is broken. Server push seems like a win at any point in a SPDY connection, not just for the initial connection.

0xABADC0DA 15y ago
> Browsers won't keep SPDY connections open forever in the hopes of someday reusing them; the "initial connection" case will happen quite frequently in a normal browsing session. This is what boggles my mind about Spdy, the dissonance. On the one hand Spdy is great because it does a bunch of requests on the same TCP connection, but on the other hand Spdy is great because it saves 100 bytes per connection and that's a big deal because there are going to be so many connections made? It doesn't make sense. Spdy is great because it has compression, but on the other hand Spdy is great because it requires SSL which already has compression. Huh? > I suggested the hopefully very common case of sending a very small request and getting back a very small 304. ... The whole exchange consists entirely of headers ... That would make 121 bytes closer to a 30-40% savings. On a first request only. You visit some site and only check if exactly one resource? Not likely. In any case, the cost to transfer 100 bytes once is irrelevant in any grand scheme of things. > (Also, I'd love to see a reference for your figures on expected bytes saved through the prefix dictionary.) http://www.eecis.udel.edu/~amer/PEL/poc/pdf/SPDY-Fan.pdf http://www.eecis.udel.edu/~amer/PEL/poc/pdf/SPDY-Fan.pdf The dictionary construction part is suspect though... take a look at how many times the same string length count (\0\0\0\4 for example) occurs in the prefix -- this can't be optimal.
- JoshTriplett 15y ago
  > This is what boggles my mind about Spdy, the dissonance. On the one hand Spdy is great because it does a bunch of requests on the same TCP connection, but on the other hand Spdy is great because it saves 100 bytes per connection and that's a big deal because there are going to be so many connections made? It doesn't make sense. Adaptability: SPDY works well for both cases, rather than only picking one case and optimizing for that case alone. I see quite a bit of value in optimizing SPDY for a pile of short single-request connections to sites, as well as optimizing for numerous requests to the same site. Google's own site will serve numerous examples of both; see below. > On a first request only. You visit some site and only check if exactly one resource? Not likely. In any case, the cost to transfer 100 bytes once is irrelevant in any grand scheme of things. It costs nothing to initialize the compressor state differently, and saves 100+ bytes per initial request/response. A quick search suggests that Google services several billion searches per day. Assume for the moment that a substantial fraction of those searches come from user agents that don't already have an open connection to Google. Starting the compressor out with a specific state based on a prefix dictionary costs nothing (just changing the initial state of the compressor), but saves 100+ bytes per initial request/response. So, just for Google alone that change could save on the order of 100GB of traffic per day, for something that costs browsers and servers nothing to do. Now multiply that out for every other site on the Internet. And for a different approach, consider the total number of initial connections that take place on GSM/3G networks every day. More importantly than bandwidth, saving 100 bytes provides a potentially substantial latency benefit for the initial response, making it that much more likely to fit into a single frame rather than fragmenting. If SPDY can save 100 bytes for free, why not do it? > http://www.eecis.udel.edu/~amer/PEL/poc/pdf/SPDY-Fan.pdf http://www.eecis.udel.edu/~amer/PEL/poc/pdf/SPDY-Fan.pdf Thanks for the reference! That paper seems to compare their proposed dictionary to "SPDY’s current default initial dictionary", which as far as I can tell means the prefix dictionary from some iteration of SPDY, rather than zlib's default. I don't think the paper provides statistics on how much a prefix dictionary saves over not having one at all. > The dictionary construction part is suspect though... take a look at how many times the same string length count (\0\0\0\4 for example) occurs in the prefix -- this can't be optimal. I agree that the default dictionary could probably use work. That kind of work seems like the most likely reason for the several versions of prefix dictionaries that have appeared so far, which you complained about in a previous comment. :)