5 ms·

Still has a prefix dictionary. The benefit of the prefix dictionary over starting from scratch is extremely marginal (about a hundred bytes on the first reques

Still has a prefix dictionary. The benefit of the prefix dictionary over starting from scratch is extremely marginal (about a hundred bytes on the first request). Still making claims comparing to HTTP without pipelining. After how long they still haven't even compared to pipelining (because Chrome doesn't do pipelining, is Firefox is banned at Google or something?) Still has server push. Read the spec at how complicated this is, all to save one one-way trip. Still hardcodes parts of HTTP into the protocol. ...gross.

wmf 15y ago
My understanding is that HTTP/1.1 pipelining can break in a messy way where the client isn't sure whether some requests in flight will be serviced or not. Thus it tends to be disabled. In contrast, SPDY either works correctly or it falls back to regular HTTP.
- 0xABADC0DA 15y ago
  There are some problems in HTTP pipelining. Nevertheless Firefox and Opera have pipelining implementations that work and are significantly faster than HTTP with keepalive. It's enabled by default in Opera. The point being that they've designed this new protocol based on their assumptions and hunches. Same lack of rigor is present throughout the whole spec -- take a look at how much redundancy is in the prefix dictionary for instance.
  - igrigorik 15y ago
    http://www.chromium.org/spdy http://www.chromium.org/spdy - contains some great and in-depth research motivating SPDY. Original whitepaper: http://www.chromium.org/spdy/spdy-whitepaper http://www.chromium.org/spdy/spdy-whitepaper Here's a good tech talk to checkout as well: http://www.youtube.com/watch?v=TNBkxA313kk http://www.youtube.com/watch?v=TNBkxA313kk Draft 3 has also updated the dictionary, here's the research paper motivating the change: http://www.eecis.udel.edu/~amer/PEL/poc/pdf/SPDY-Fan.pdf http://www.eecis.udel.edu/~amer/PEL/poc/pdf/SPDY-Fan.pdf
  - agentS 15y ago
    Chromium and Chrome Dev Channel has (off by default) pipelining. Pipelining can only be done for idempotent requests, (ie GET only), has head of line blocking problems, and can break proxies. Also, its very difficult to handle errors in a pipelined situation. For example, if the 2nd request in a pipeline fails, but the server has been processing 3rd and 4th concurrently, what response does it give? I think most engineers would agree that multiplexing over a single connection is better and less error-prone than pipelining.
JoshTriplett 15y ago
> Still has a prefix dictionary. The benefit of the prefix dictionary over starting from scratch is extremely marginal (about a hundred bytes on the first request). 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? > Still making claims comparing to HTTP without pipelining. After how long they still haven't even compared to pipelining (because Chrome doesn't do pipelining, is Firefox is banned at Google or something?) Firefox still doesn't do pipelining by default either, with the stated reason that some web servers will break with it enabled. Using HTTP pipelining at this point would require some kind of positive indication from the server that it will work, or some kind of autodetection by the browser (which will take multiple requests to do). Also, HTTP pipelining requires answering requests in order, while SPDY doesn't, allowing the server to respond to requests as data becomes available. > Still has server push. Read the spec at how complicated this is, all to save one one-way trip. Server push potentially eliminates several full round trips. 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, and the pile of images referenced from that CSS or JavaScript, all while the CGI runs. That eliminates at least two round-trips, or even more if more images exist than the maximum number of concurrent requests browsers will hit a server with. > Still hardcodes parts of HTTP into the protocol. SPDY specifically exists to replace HTTP, not anything else.
- caf 15y ago
  FWIW, I've been browsing with pipelining enabled for years now and not noticed any problems (in Firefox, search for "pipelining" in about:config).
- 0xABADC0DA 15y ago
  > 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.
pronoiac 15y ago
Isn't security one of their major concerns? Before you encrypt something as compressible as headers, it's a good idea to compress it first. At the least, when brute forcing decryption keys, it makes it more complex to check the output.
- gcp 15y ago
  Brute forcing a key shouldn't be a concern, nor should a known-plaintext attack be. If it is, your crypto is broken. That said, compression before encryption means there's less data to encrypt, so you win back some performance lost by the compression. Nevertheless, I'm sure the considerations were something else entirely (such as compression seldom being done by TLS).

wmf 15y ago

My understanding is that HTTP/1.1 pipelining can break in a messy way where the client isn't sure whether some requests in flight will be serviced or not. Thus it tends to be disabled. In contrast, SPDY either works correctly or it falls back to regular HTTP.

0xABADC0DA 15y ago
There are some problems in HTTP pipelining. Nevertheless Firefox and Opera have pipelining implementations that work and are significantly faster than HTTP with keepalive. It's enabled by default in Opera. The point being that they've designed this new protocol based on their assumptions and hunches. Same lack of rigor is present throughout the whole spec -- take a look at how much redundancy is in the prefix dictionary for instance.
- igrigorik 15y ago
  http://www.chromium.org/spdy http://www.chromium.org/spdy - contains some great and in-depth research motivating SPDY. Original whitepaper: http://www.chromium.org/spdy/spdy-whitepaper http://www.chromium.org/spdy/spdy-whitepaper Here's a good tech talk to checkout as well: http://www.youtube.com/watch?v=TNBkxA313kk http://www.youtube.com/watch?v=TNBkxA313kk Draft 3 has also updated the dictionary, here's the research paper motivating the change: http://www.eecis.udel.edu/~amer/PEL/poc/pdf/SPDY-Fan.pdf http://www.eecis.udel.edu/~amer/PEL/poc/pdf/SPDY-Fan.pdf
- agentS 15y ago
  Chromium and Chrome Dev Channel has (off by default) pipelining. Pipelining can only be done for idempotent requests, (ie GET only), has head of line blocking problems, and can break proxies. Also, its very difficult to handle errors in a pipelined situation. For example, if the 2nd request in a pipeline fails, but the server has been processing 3rd and 4th concurrently, what response does it give? I think most engineers would agree that multiplexing over a single connection is better and less error-prone than pipelining.

JoshTriplett 15y ago

> Still has a prefix dictionary. The benefit of the prefix dictionary over starting from scratch is extremely marginal (about a hundred bytes on the first request). 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? > Still making claims comparing to HTTP without pipelining. After how long they still haven't even compared to pipelining (because Chrome doesn't do pipelining, is Firefox is banned at Google or something?) Firefox still doesn't do pipelining by default either, with the stated reason that some web servers will break with it enabled. Using HTTP pipelining at this point would require some kind of positive indication from the server that it will work, or some kind of autodetection by the browser (which will take multiple requests to do). Also, HTTP pipelining requires answering requests in order, while SPDY doesn't, allowing the server to respond to requests as data becomes available. > Still has server push. Read the spec at how complicated this is, all to save one one-way trip. Server push potentially eliminates several full round trips. 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, and the pile of images referenced from that CSS or JavaScript, all while the CGI runs. That eliminates at least two round-trips, or even more if more images exist than the maximum number of concurrent requests browsers will hit a server with. > Still hardcodes parts of HTTP into the protocol. SPDY specifically exists to replace HTTP, not anything else.

caf 15y ago
FWIW, I've been browsing with pipelining enabled for years now and not noticed any problems (in Firefox, search for "pipelining" in about:config).
0xABADC0DA 15y ago
> 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.

pronoiac 15y ago

Isn't security one of their major concerns? Before you encrypt something as compressible as headers, it's a good idea to compress it first. At the least, when brute forcing decryption keys, it makes it more complex to check the output.

gcp 15y ago
Brute forcing a key shouldn't be a concern, nor should a known-plaintext attack be. If it is, your crypto is broken. That said, compression before encryption means there's less data to encrypt, so you win back some performance lost by the compression. Nevertheless, I'm sure the considerations were something else entirely (such as compression seldom being done by TLS).