4 ms·

There is another interesting thread about internet of things http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/0602.html http://lists.w3.org/Archives/

There is another interesting thread about internet of things http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/0602.html http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/... "So it looks like HTTP 2 really needs (at least) two different profiles, one for web hosting/web browser users ("HTTP 2 is web scale!") and one for HTTP- as-a-substrate users. The latter should have (or more accurately should not have) multiple streams and multiplexing, flow control, priorities, reprioritisation and dependencies, mandatory payload compression, most types of header compression, and many others." http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/0604.html http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/... "First and foremost, it needs to be recognized that HTTP/2 has been designed from the start to primarily meet the needs of a very specific grouping of high volume web properties and browser implementations. There is very little evidence that ubiquitous use of the protocol is even a secondary consideration -- in fact, the "they can just keep using HTTP/1.1" mantra has been repeated quite often throughout many of the discussions here on this, usually as a way of brushing aside many of the concerns that have been raised. So be it. It's clear at this point that HTTP/2 is on a specific fixed path forward and that, for the kinds of use cases required by IoT, alternatives will need to be pursued."

youngtaff 12y ago
Pretty sure every ecommerce site will benefit from deploying HTTP/2 (although their tendency to fill sites full of third party components may reduce some of its benefits)
- justincormack 12y ago
  Well the complexity makes it hard to build a performant server. https://groups.google.com/forum/#!searchin/mechanical-sympathy/http/mechanical-sympathy/CWyAD-oF9Uw/ycO0vxGqMvsJ https://groups.google.com/forum/#!searchin/mechanical-sympat...
- fredliu 12y ago
  Not exactly sure under what specific scenarios "every e-commerce site" will be running, but if HTTP/2 == SPDY, it's not looking good on mobile: http://conferences.sigcomm.org/co-next/2013/program/p303.pdf http://conferences.sigcomm.org/co-next/2013/program/p303.pdf <== TLDR: current SPDY implementation has negative impact on Mobile performance. SPDY sucks on mobile is sort of a known fact, but this paper shows solid evidence that it's true.
  - youngtaff 12y ago
    The conclusion of "As a result, there is no clear performance improvement with SPDY in cellular networks, in contrast to existing studies on wired and WiFi networks." is rather different to "current SPDY implementation has negative impact on Mobile performance." Of cousre as SPDY is only using a single connection then it's more vulnerable to issues with that connection.
    - fredliu 12y ago
      So you agree that single connection is a problem :)? Under mobile, where high RTT is the norm rather than the exception, this has compound negative effect on performance (mistaken long response time as packet loss, reducing the congestion window that makes all flows suffer, etc, etc.). Everything else being equal, applying SPDY on mobile introduced this new mobile "vulnerability", isn't this SPDY's negative impact on Mobile? Sure, if cellular networks has the same delay/packet loss characteristics as wired/wifi, SPDY would fly, but mobile and wired/wifi are clearly not the same. Also, I used that paper just as an example showing SPDY's performance problem on mobile (with very nice detailed analysis why SPDY suffers). My conclusion of "SPDY sucks on mobile" is from my experience, not from that paper. I just use that paper to show my point. Actually, I think their paper's conclusion is a little bit too "polite" toward SPDY. [Edit: adding reference to the paper] In that paper the sentence right before the "conclusion" you quoted is "In cellular networks, there are fundamental interactions across protocol layers that limit the performance of both SPDY as well as HTTP."
      - youngtaff 12y ago
        I've tested SPDY over wired / wifi but not over mobile so my mobile experience is anecdotal. That said all my mobile browsing (minus HTTPS) is run over SPDY (via the Google proxy) and I wouldn't describe it as sucking. Even in the HTTP case it will still depend on what resource the packet loss etc., occurs for e.g. if it's something on the critical rendering path will it make that much difference?
        fredliu 12y ago

youngtaff 12y ago

Pretty sure every ecommerce site will benefit from deploying HTTP/2 (although their tendency to fill sites full of third party components may reduce some of its benefits)

justincormack 12y ago
Well the complexity makes it hard to build a performant server. https://groups.google.com/forum/#!searchin/mechanical-sympathy/http/mechanical-sympathy/CWyAD-oF9Uw/ycO0vxGqMvsJ https://groups.google.com/forum/#!searchin/mechanical-sympat...
fredliu 12y ago
Not exactly sure under what specific scenarios "every e-commerce site" will be running, but if HTTP/2 == SPDY, it's not looking good on mobile: http://conferences.sigcomm.org/co-next/2013/program/p303.pdf http://conferences.sigcomm.org/co-next/2013/program/p303.pdf <== TLDR: current SPDY implementation has negative impact on Mobile performance. SPDY sucks on mobile is sort of a known fact, but this paper shows solid evidence that it's true.
- youngtaff 12y ago
  The conclusion of "As a result, there is no clear performance improvement with SPDY in cellular networks, in contrast to existing studies on wired and WiFi networks." is rather different to "current SPDY implementation has negative impact on Mobile performance." Of cousre as SPDY is only using a single connection then it's more vulnerable to issues with that connection.
  - fredliu 12y ago
    So you agree that single connection is a problem :)? Under mobile, where high RTT is the norm rather than the exception, this has compound negative effect on performance (mistaken long response time as packet loss, reducing the congestion window that makes all flows suffer, etc, etc.). Everything else being equal, applying SPDY on mobile introduced this new mobile "vulnerability", isn't this SPDY's negative impact on Mobile? Sure, if cellular networks has the same delay/packet loss characteristics as wired/wifi, SPDY would fly, but mobile and wired/wifi are clearly not the same. Also, I used that paper just as an example showing SPDY's performance problem on mobile (with very nice detailed analysis why SPDY suffers). My conclusion of "SPDY sucks on mobile" is from my experience, not from that paper. I just use that paper to show my point. Actually, I think their paper's conclusion is a little bit too "polite" toward SPDY. [Edit: adding reference to the paper] In that paper the sentence right before the "conclusion" you quoted is "In cellular networks, there are fundamental interactions across protocol layers that limit the performance of both SPDY as well as HTTP."
    - youngtaff 12y ago
      I've tested SPDY over wired / wifi but not over mobile so my mobile experience is anecdotal. That said all my mobile browsing (minus HTTPS) is run over SPDY (via the Google proxy) and I wouldn't describe it as sucking. Even in the HTTP case it will still depend on what resource the packet loss etc., occurs for e.g. if it's something on the critical rendering path will it make that much difference?
      - fredliu 12y ago