6 ms·

Check out the IETF draft[1], and this awesome book[2] for more details on HTTP/2. Some of the coolest stuff I saw was streams and server push. Streams allow mu

Check out the IETF draft[1], and this awesome book[2] for more details on HTTP/2. Some of the coolest stuff I saw was streams and server push. Streams allow multiplexing multiple logical streams of data onto one TCP connection. So unlike the graphs you typically see in chrome network inspector where one resource request ends and another begins, frames (the unit of data) from multiple streams are sent in parallel. So this means only one connection (connects are persistent by default) is needed between server and client, and there are ways to prioritize streams and control flow so it gives devs more opportunities for performance gains. Also headers are only sent in deltas now. Client/server maintain header tables with previous values of headers (which persist for the connection), so only updates need to be sent after the first request. I think this will be a consistent 40-50 byte saved per request for most connections where headers rarely change. [1] http://tools.ietf.org/html/draft-ietf-httpbis-http2-14 http://tools.ietf.org/html/draft-ietf-httpbis-http2-14 [2] http://chimera.labs.oreilly.com/books/1230000000545/ch12.html http://chimera.labs.oreilly.com/books/1230000000545/ch12.htm...

vidarh 12y ago
> So unlike the graphs you typically see in chrome network inspector where one resource request ends and another begins, frames (the unit of data) from multiple streams are sent in parallel. Connections are already processed in parallel whenever they can. That is, when the browser knows what to request, and it fits in the execution model. If there's a huge number of assets on a single hostname, this has been a limiting factor because the browsers have limited the number of requests to a single hostname to avoid overloading the server. But that will remain an issue even if the requests are multiplexed over a single connection. Most of the time when I see graphs in the network inspector that aren't massively parallel it's because nobody have spent time optimizing where/how assets are requested in ways that will make them just as bad with connection multiplexing. There certainly can be benefits to reap from it, but the worst offenders are already ignoring best practices.
- youngtaff 12y ago
  Multiple parallel connections increases the likelihood of packet loss due to network congestion, is also imposes a larger load on servers and intermediate proxies. A TCP handshake has to take place for each connection and this isn't cost free, and there's the SSL negotiations on top (though techniques like OCSP stapling help) Going massively parallel isn't free - Will Chan of Chrome did a good write up here: https://insouciant.org/tech/network-congestion-and-web-browsing/ https://insouciant.org/tech/network-congestion-and-web-brows...
  - vidarh 12y ago
    True, but my point is that unlike what zaptheimpaler seemed to imply, if you don't see massively parallel downloads in the network tab already, you are not going to see massively parallel downloads just because you get multiplexed streams, and the sites that do see parallel downloads are already for the most part going to do well. So the real world impact for users is likely to be small: Lowering the cost of multiple streams will likely give you decent percentage wise improvements on page download times that are already so good that the absolute improvements are likely to be small, and likely minimal to no improvements on the pages that are actually slow.
    - youngtaff 12y ago
      Akamai report a 5-20% increase with some sites seeing no improvement. With the advent of the browser pre-loader then as long as the resources are declared in the markup then the browser should discover them and issue the request. Currently browsers often seemed to blocked on waiting for a connection to come free
    - dcsommer 12y ago
      The real world impact is incredible, not small. Opening new connections is horribly, horribly bad for internet performance. http://www.chromium.org/spdy/spdy-whitepaper http://www.chromium.org/spdy/spdy-whitepaper
monstermonster 12y ago
I don't get this. TCP has steams. TCP has connection mux. TCP has flow and congestion control. HTTP has keepalive. Why build another stack on OSI layer 7? Also now we have to keep state to work out what the diffs are. State is evil. Whilst I'm sure this will have some minor performance advancements, I'm not sure that it justifies the new protocol stack. Not sending 2Mb of JavaScript and crappy HTML down the connection to display the front page probably has higher gains.
- megaman821 12y ago
  All true but TCP has head-of-line blocking, which means even if resources are requested in parallel then can only be returned in the order they where requested. In an ideal world we could switch to using something like the SCTP networking protocol with HTTP that would solve a lot of issues. Unfortunately we are stuck with TCP, so the application protocol (HTTP) now must implement a networking protocol so we can multiplex over a single connection. At least people won't have to inline resources, sprite images, or concatenate CSS and JavaScript anymore. And header compression is a small upgrade to the spec.
  - monstermonster 12y ago
    Couple of follow ups on this one: SCTP is message oriented rather than stream oriented so this isn't really useful. The chunk size is also two bytes meaning that all your messages have to be less than 64k or you have to implement packet reassembly and stuff. Oh look, back at TCP again. We must do nothing. I suspect this entire SPDY/HTTP/2 reengineering effort is a 1000% complexity and risk increase for a 2-5% gain in performance. That is not a trade-off as an engineer I could accept. 90% of the inefficiency of web applications is down to the application stack, not the protocols. Sending hundreds of KiB of uncompressed text down rather than compressed abstract or native virtual machine instructions for example is a bigger win.
    - megaman821 12y ago
      I am not trying to extol any virtues or negatives of SCTP, just comment that for HTTP/2 to have multiplexing over a single connect without the head-of-line block problem they have to implement messages also. Seems wasteful.

vidarh 12y ago

> So unlike the graphs you typically see in chrome network inspector where one resource request ends and another begins, frames (the unit of data) from multiple streams are sent in parallel. Connections are already processed in parallel whenever they can. That is, when the browser knows what to request, and it fits in the execution model. If there's a huge number of assets on a single hostname, this has been a limiting factor because the browsers have limited the number of requests to a single hostname to avoid overloading the server. But that will remain an issue even if the requests are multiplexed over a single connection. Most of the time when I see graphs in the network inspector that aren't massively parallel it's because nobody have spent time optimizing where/how assets are requested in ways that will make them just as bad with connection multiplexing. There certainly can be benefits to reap from it, but the worst offenders are already ignoring best practices.

youngtaff 12y ago
Multiple parallel connections increases the likelihood of packet loss due to network congestion, is also imposes a larger load on servers and intermediate proxies. A TCP handshake has to take place for each connection and this isn't cost free, and there's the SSL negotiations on top (though techniques like OCSP stapling help) Going massively parallel isn't free - Will Chan of Chrome did a good write up here: https://insouciant.org/tech/network-congestion-and-web-browsing/ https://insouciant.org/tech/network-congestion-and-web-brows...
- vidarh 12y ago
  True, but my point is that unlike what zaptheimpaler seemed to imply, if you don't see massively parallel downloads in the network tab already, you are not going to see massively parallel downloads just because you get multiplexed streams, and the sites that do see parallel downloads are already for the most part going to do well. So the real world impact for users is likely to be small: Lowering the cost of multiple streams will likely give you decent percentage wise improvements on page download times that are already so good that the absolute improvements are likely to be small, and likely minimal to no improvements on the pages that are actually slow.
  - youngtaff 12y ago
    Akamai report a 5-20% increase with some sites seeing no improvement. With the advent of the browser pre-loader then as long as the resources are declared in the markup then the browser should discover them and issue the request. Currently browsers often seemed to blocked on waiting for a connection to come free
  - dcsommer 12y ago
    The real world impact is incredible, not small. Opening new connections is horribly, horribly bad for internet performance. http://www.chromium.org/spdy/spdy-whitepaper http://www.chromium.org/spdy/spdy-whitepaper

monstermonster 12y ago

I don't get this. TCP has steams. TCP has connection mux. TCP has flow and congestion control. HTTP has keepalive. Why build another stack on OSI layer 7? Also now we have to keep state to work out what the diffs are. State is evil. Whilst I'm sure this will have some minor performance advancements, I'm not sure that it justifies the new protocol stack. Not sending 2Mb of JavaScript and crappy HTML down the connection to display the front page probably has higher gains.

megaman821 12y ago
All true but TCP has head-of-line blocking, which means even if resources are requested in parallel then can only be returned in the order they where requested. In an ideal world we could switch to using something like the SCTP networking protocol with HTTP that would solve a lot of issues. Unfortunately we are stuck with TCP, so the application protocol (HTTP) now must implement a networking protocol so we can multiplex over a single connection. At least people won't have to inline resources, sprite images, or concatenate CSS and JavaScript anymore. And header compression is a small upgrade to the spec.
- monstermonster 12y ago
  Couple of follow ups on this one: SCTP is message oriented rather than stream oriented so this isn't really useful. The chunk size is also two bytes meaning that all your messages have to be less than 64k or you have to implement packet reassembly and stuff. Oh look, back at TCP again. We must do nothing. I suspect this entire SPDY/HTTP/2 reengineering effort is a 1000% complexity and risk increase for a 2-5% gain in performance. That is not a trade-off as an engineer I could accept. 90% of the inefficiency of web applications is down to the application stack, not the protocols. Sending hundreds of KiB of uncompressed text down rather than compressed abstract or native virtual machine instructions for example is a bigger win.
  - megaman821 12y ago
    I am not trying to extol any virtues or negatives of SCTP, just comment that for HTTP/2 to have multiplexing over a single connect without the head-of-line block problem they have to implement messages also. Seems wasteful.