4 ms·

Can you be more specific about the features we don't really need? Using SPDY shows huge performance improvements in production.

jacquesm 12y ago
I'm sure it does. But the overhead associated with SSL connections is something that should be solved at that level, not by shoehorning a complete multiplexing system into an otherwise relatively clean protocol. It seems to me that that violates a whole pile of good design principles.
- kjksf 12y ago
  The major speed increase is not from eliminating ssl handshake (though it helps) but by multiplexing many logical http connections on one tcp stream. It's solved exactly at the level it had to be solved. The nitty gritty of why opening a new tcp stream for each http request is slow (and why http pipelining doesn't make it faster the way spdy does) is beyond the scope of this post but https://www.youtube.com/watch?v=-yxQIRl6Qic https://www.youtube.com/watch?v=-yxQIRl6Qic explains that and other benefits of http/2.0 in great detail.
  - mateo411 12y ago
    Yes, I agree. I think the biggest win for HTTP/2 is multiplexing the requests over a single TCP connection. The average web page downloads over 1MB of data over 80 to 100 Http requests. Each request is requires its own TCP connection. Modern browsers download 6 assets per host at a time. This decision is so we don't have too many TCP connections competing for the same bandwidth. People optimize the page load times, by combining javascript, combining images with CSS sprites, or adding additional hosts so they can download more of the assets in parallel. I think that the waterfall chart is an intuitive way to understand how the assets on your website is affecting the page load time. It will be interesting to see what new ways we visualize the process of assets downloading and different browser events, when HTTP/2 starts to be more widely used.
maratd 12y ago
> Using SPDY shows huge performance improvements in production. Using SPDY only shows improvement over HTTPS. Over HTTP you get a huge performance hit! The majority of data has no need for encryption. Some of it does. Where it does, SPDY certainly makes sense.
- acdha 12y ago
  Your statement is only possibly true for a single request. In any real world application, the ability to issue many requests without having to open a new connection each time and to receive results out of order is a massive win over HTTP, even before you consider things like server push allowing resources like stylesheets or scripts to be delivered immediately rather than waiting for the client to finish parsing an HTML document.
  - threeseed 12y ago
    There are benchmarks that show that SPDY is slower than HTTP if sharding is used. The use of this common technique gets around the connection limit.
    - Dylan16807 12y ago
      And opening that many connections absolutely trashes TCP load balancing.
    - acdha 12y ago
      Sharding helps with only the connection limit at the expense of extra redundant DNS delays and poor scheduling of the total available network capacity. It cannot help with the need to request resources sequentially and has no equivalent to something like server push avoiding extra round-trips + client delays before even issuing requests for related resources.
- AlyssaRowan 12y ago
  >The majority of data has no need for encryption. Some of it does. No. Wrong. Absolutely, incontrovertibly wrong. Everything that doesn't absolutely need to be plaintext should be encrypted; everything that can be authenticated should be. Don't believe me? The IETF and IAB can't really be much stronger than this: https://tools.ietf.org/html/rfc7258 https://tools.ietf.org/html/rfc7258 https://www.iab.org/2014/11/14/iab-statement-on-internet-confidentiality/ https://www.iab.org/2014/11/14/iab-statement-on-internet-con...

jacquesm 12y ago

I'm sure it does. But the overhead associated with SSL connections is something that should be solved at that level, not by shoehorning a complete multiplexing system into an otherwise relatively clean protocol. It seems to me that that violates a whole pile of good design principles.

kjksf 12y ago
The major speed increase is not from eliminating ssl handshake (though it helps) but by multiplexing many logical http connections on one tcp stream. It's solved exactly at the level it had to be solved. The nitty gritty of why opening a new tcp stream for each http request is slow (and why http pipelining doesn't make it faster the way spdy does) is beyond the scope of this post but https://www.youtube.com/watch?v=-yxQIRl6Qic https://www.youtube.com/watch?v=-yxQIRl6Qic explains that and other benefits of http/2.0 in great detail.
- mateo411 12y ago
  Yes, I agree. I think the biggest win for HTTP/2 is multiplexing the requests over a single TCP connection. The average web page downloads over 1MB of data over 80 to 100 Http requests. Each request is requires its own TCP connection. Modern browsers download 6 assets per host at a time. This decision is so we don't have too many TCP connections competing for the same bandwidth. People optimize the page load times, by combining javascript, combining images with CSS sprites, or adding additional hosts so they can download more of the assets in parallel. I think that the waterfall chart is an intuitive way to understand how the assets on your website is affecting the page load time. It will be interesting to see what new ways we visualize the process of assets downloading and different browser events, when HTTP/2 starts to be more widely used.

maratd 12y ago

> Using SPDY shows huge performance improvements in production. Using SPDY only shows improvement over HTTPS. Over HTTP you get a huge performance hit! The majority of data has no need for encryption. Some of it does. Where it does, SPDY certainly makes sense.

acdha 12y ago
Your statement is only possibly true for a single request. In any real world application, the ability to issue many requests without having to open a new connection each time and to receive results out of order is a massive win over HTTP, even before you consider things like server push allowing resources like stylesheets or scripts to be delivered immediately rather than waiting for the client to finish parsing an HTML document.
- threeseed 12y ago
  There are benchmarks that show that SPDY is slower than HTTP if sharding is used. The use of this common technique gets around the connection limit.
  - Dylan16807 12y ago
    And opening that many connections absolutely trashes TCP load balancing.
  - acdha 12y ago
    Sharding helps with only the connection limit at the expense of extra redundant DNS delays and poor scheduling of the total available network capacity. It cannot help with the need to request resources sequentially and has no equivalent to something like server push avoiding extra round-trips + client delays before even issuing requests for related resources.
AlyssaRowan 12y ago
>The majority of data has no need for encryption. Some of it does. No. Wrong. Absolutely, incontrovertibly wrong. Everything that doesn't absolutely need to be plaintext should be encrypted; everything that can be authenticated should be. Don't believe me? The IETF and IAB can't really be much stronger than this: https://tools.ietf.org/html/rfc7258 https://tools.ietf.org/html/rfc7258 https://www.iab.org/2014/11/14/iab-statement-on-internet-confidentiality/ https://www.iab.org/2014/11/14/iab-statement-on-internet-con...