8 ms·

Not usually one to get behind speculation, but if one were to provide an educated guess, what does everyone think about the timeline of switchover from 1.1 to 2

by wwarren 12y ago

Not usually one to get behind speculation, but if one were to provide an educated guess, what does everyone think about the timeline of switchover from 1.1 to 2.0? 1 year? 5 years? Personally I think we'll see a few big players jump in and then we'll see a domino effect as all the big servers complete their implementations (Apache, NGINX, Tomcat etc). Of course HTTP/1.1 systems are going to be around for a loooong time...

josteink 12y ago
> Not usually one to get behind speculation, but if one were to provide an educated guess, what does everyone think about the timeline of switchover from 1.1 to 2.0? 1 year? 5 years? Try never. Too much embedded devices out there which 1. won't get updated, 2. doesn't have enough storage for a crypto-stack and 3. doesn't have the computational power to process a crypto-stack should it even be updated to have one. Internet-standards are published, approved and then stays forever. You will realistically need to support all versions until "the end of time", or at least the end of the internet as we know it.
- mankyd 12y ago
  > Try never. Well, it depends on how you define "switchover". Enabling HTTP/2 doesn't necessarily mean turning HTTP/1.1 off.
- wwarren 12y ago
  Isn't HTTP/2 totally backwards compatible though? So those devices won't ever need to be updated ... in theory
  - vertex-four 12y ago
    No. HTTP/2 is an entirely separate protocol from HTTP/1.1. Any client, therefore, will have to have both HTTP/1.1 and HTTP/2 protocol stacks. What HTTP/2 does define is a way for the client to say "I support HTTP/2" and the server to say "Sure, talk HTTP/2 to me" in a way that allows the client to fall back to HTTP/1.1 if the server doesn't know about HTTP/2.
    - deleted 12y ago
      [deleted]
    - gsnedders 12y ago
      It's not entirely separate, as the abstract of it says: "This specification is an alternative to, but does not obsolete, the HTTP/1.1 message syntax. HTTP's existing semantics remain unchanged."
      - vertex-four 12y ago
        Indeed, the point of that message is essentially "HTTP/2 is an entirely new protocol, you can support HTTP/1.1 or HTTP/2 or both, but they have nothing to do with each other".
        gsnedders 12y ago
        Well, it means all your handling of messages is the same — once you have built your object/struct/whatever of the message (from the over-the-wire syntax), you can hand it off to pre-existing code that expects HTTP/1 messages fine. Most HTTP/2 implementations share a fair bit of code with co-existing HTTP/1 ones. You don't need to redo all your caching support and handling of HTTP caching headers, you don't need to redo any support for content negotiation you have, etc.
        dragonwriter 12y ago
        > but they have nothing to do with each other The fact that HTTP/2 retains HTTP/1.1's message semantics, as the note points out, means that they have a lot to do with each other, and that implementations will be able to share much (probably most) of their core logic. This is important -- it means that if you implement HTTP/1.1, you've done a lot of the work of implementing HTTP/2, and vice versa.
- dragonwriter 12y ago
  > You will realistically need to support all versions until "the end of time", or at least the end of the internet as we know it. Or until all the old devices have reached the end of their useful life; the internet hasn't been in general use that long, and what seems like "forever" looking back on a few decades of history may not going forward. And, anyway, even that's only true if the particular thing you are building is the kind of general purpose infrastructure that needs to support everything that might talk some form of HTTP anywhere, no matter how old or limited-purpose that device is. Plenty of things people actually build don't have that requirement.
engendered 12y ago
Months. Traditionally a change like this saw little enthusiasm or interest, and had a very slow uptake, because it didn't add value until all of the players changed. Now, however, browsers iterate so quickly that already there is HTTP/2 support on the majority of user desktops. If you run a Go or node.js or various other technology websites, even if you "self-host" HTTP, you likely (and should) have it behind nginx or Apache or HAProxy, and all of those are quickly implementing HTTP/2 (or more correctly changing the existing SPDY functionality to the final spec. And for those who wonder, a HTTP/1.1 Go app sitting behind a HTTP/2 proxy still delivers HTTP/2 benefits to the end user). Cloudflare had SPDY support over two years ago, so I expect they'll see very quick support. Of course, and you addressed this, this doesn't mean that HTTP/1.1 disappears. Heck, my web properties still see HTTP/1.0 requests, almost a decade after HTTP/1.1. But that is a very small minority.
- theallan 12y ago
  > Apache [...] are quickly implementing HTTP/2 Do you have a link to any development Apache are doing on HTTP/2? I asked about it in the previous HTTP/2 thread but there wasn't any replies and I haven't been able to find any myself. I know there is mod_spdy but that appears to be abandoned now [1]. [1] https://svn.apache.org/viewvc/httpd/mod_spdy/trunk/ https://svn.apache.org/viewvc/httpd/mod_spdy/trunk/
  - engendered 12y ago
    You know, I actually can't find anything and may have incorrectly included Apache in the "keeping up" category. The whole Apache ecosystem almost seems...defeatist now. Google donated mod_spdy to the Apache foundation and it doesn't look like it has been touched since -- given that HTTP/2 is a derivative of SPDY, the existence of that module should make it a "relatively" (relative being, well, relative) simple change, but you're right that they don't seem to be on it.
    - jimjag 12y ago
      Actually, moving from SPDY to HTTP/2 isn't any easier than going from HTTP/1.1 to HTTP/2. Google's mod_spdy was nice, but required lots of core code changes, so it was more a proof of concept. And with SPDY changing so much, wasting time on development makes little sense and, considering that SPDY (having served its purpose) is now dead, some would say that it was wise not jumping on the bandwagon quickly. But Apache is hardly alone is having a "wait and see" attitude towards HTTP/2; both HAproxy and Varnish see HTTP/2 as a solution for the wrong problem.
deleted 12y ago
[deleted]
CJefferson 12y ago
Well, in 2003 (14 years after the release of HTTP 1.1), Twitter considered it acceptable to remove HTTP 1.0 from their API access (You can still access the website itself fine over 1.0). I expect to see 1.0, 1.1 and 2.0 continue to live on basically forever. Of course, the interesting question will be how fast will the majority of users, and servers, be running 2.0?
- engendered 12y ago
  The majority of desktop browsers in use already support HTTP/2. Things are going to be slower on mobile, obviously. Thankfully it isn't all or nothing -- your server side load balancer / SSL termination supports HTTP/1, 1.1, and 2.0, and provides the client the experience they can support.
  - billyhoffman 12y ago
    Why slower on mobile? The upgrade cycle on phones is much shorter than PCs, so even if you never put new software on a phone, you'll get an HTTP/2 enabled browser quickly. On the software side, Google-derived Android comes with Chrome by default, which already support SPDY and HTTP/2 support is imminent. Safari on iOS 8 supports SPDY, ditto on HTTP/2 coming soon. Both those software updates can be done instantly (via Google Play Services) or within a year (yearly iOS updates). So I'd think mobile support is coming very quickly.
    - asadotzler 12y ago
      It's not about the upgrade cycle of the hardware, but the software. Browsers stay up to date automatically, even on 10 year old PCs. Phones are often abandoned by their providers and run old versions of the OS that are not automatically updated to the latest browser tech.
    - nly 12y ago
      > Why slower on mobile? The upgrade cycle on phones is much shorter than PCs Disagree. Phone manufacturers adopt Android versions slowly, especially at the low end, and on PC both Firefox and Chrome update themselves.
atonse 12y ago
My take is that browser support will be very fast, because of evergreen browsers. I'm also guessing a majority of the top 500 sites will support it pretty quickly (on the order of a year or two). Everything else, will be a long tail of a decade or more. Edit: Just wanted to add that, I think the better goal is "majority of traffic using HTTP/2" - that's probably 5 years because the majority of traffic probably comes down to the top 500 sites.
mrottenkolber 12y ago
I am still happily running HTTP/1.0 and didn't plan to "upgrade" ever tbh. I hope the web stays backwards compatible.
- kstrauser 12y ago
  Eww, why? HTTP/1.1 is an upgrade in every way over 1.0 with no disadvantages. If nothing else, 1.1 added the "Host:" header so that you can put two domains on the same IP.
marcosdumay 12y ago
Just to reinforce it, HTTP/2 is not a replacement for HTTP/1.1. It's an optimization for a few very important use cases, but it does not support most of the different ways HTTP is used everywhere. Even for the cases it optimizes, one's recommended to verify if there's really any performance enhancement after deploying it, because there are several variables that could make it worse.
otabdeveloper1 12y ago
> 1 year? 5 years? Never. Like IPv6, HTTP/2 is a broken standard that doesn't solve any problems. The problem with the Web isn't a lack of out-of-order requests, the problem with the Web are those horrible ever-present Javascript frameworks. (Likewise, the problem with IPv4 isn't a lack of address space, the problem with IPv4 is a lack of a standard and simple way for managing VPNs and tunnels. I don't want my lightbulbs to be connected to the global Internet. What I _do_ want is a way to tunnel remotely and securely into my home's LAN and control the lightbulbs from the inside.)
- dragonwriter 12y ago
  > The problem with the Web isn't a lack of out-of-order requests, the problem with the Web are those horrible ever-present Javascript frameworks. To the extent that's a problem with the web (its hardly as if the web can only have one problem), that's the domain that progressive HTML (and JS) standards can address (and are addressing.) The more core HTML does, the less JS you need, the more core JS does, the less framework you need when you need JS at all.
- mister_m 12y ago
  Not to be rude, but I honestly am unable to determine if you are being sarcastic.
- kingmanaz 12y ago
  >The problem with the Web isn't a lack of out-of-order requests, the problem with the Web are those horrible ever-present Javascript frameworks. Agreed. Javascript should become web assembly, evolving into an intermediate language which other languages are compiled to. Callback heavy code is a huge barrier to entry for people that want to get things done with the web. Likewise, the industry hasn't been satisfied with the framework abstractions built on such a model (hence the constant, near daily flux in framework fads). It's been said here before that the web needs to consult TCL's ~25 year old TK framework for guidence on how a simple GUI framework can be accomplished without OO. Programming TK is akin to "heaping up" a shell script from small components. Anyone can do it, and they needn't resort to the sophistry of FactoryFactories et. al. http://www.tkdocs.com/tutorial/ http://www.tkdocs.com/tutorial/
ForHackernews 12y ago
How's the IPv6 switchover going?
- kstrauser 12y ago
  5% of Google's traffic these days and growing on a hockey stick: http://www.google.com/intl/en/ipv6/statistics.html http://www.google.com/intl/en/ipv6/statistics.html . My Comcast cable Internet comes with a native IPv6 block.
  - omgitstom 12y ago
    It is amazing that the % of traffic using IPv6 is higher on the weekends... I wonder what is causing that cycle
    - tjgq 12y ago
      Possibly the same reason why the market share of old versions of Internet Explorer is higher on workdays: slower uptake on corporate environments when compared to residential customers.
  - ForHackernews 12y ago
    IPv6 was formalized in 1998, so if HTTP/2 follows the same trend, I guess we'll be at 5% adoption by 2032?
    - dragonwriter 12y ago
      Why would HTTP/2 follow the same trend? IPv6 requires not just the endpoints, but the routers in between to be on board with it. HTTP/2 only requires end-points. There's a lot less friction for HTTP/1.1 -> HTTP/2 upgrades than IPv4 -> IPv6 upgrades.

by wwarren 12y ago

josteink 12y ago

> Not usually one to get behind speculation, but if one were to provide an educated guess, what does everyone think about the timeline of switchover from 1.1 to 2.0? 1 year? 5 years? Try never. Too much embedded devices out there which 1. won't get updated, 2. doesn't have enough storage for a crypto-stack and 3. doesn't have the computational power to process a crypto-stack should it even be updated to have one. Internet-standards are published, approved and then stays forever. You will realistically need to support all versions until "the end of time", or at least the end of the internet as we know it.

mankyd 12y ago
> Try never. Well, it depends on how you define "switchover". Enabling HTTP/2 doesn't necessarily mean turning HTTP/1.1 off.
wwarren 12y ago
Isn't HTTP/2 totally backwards compatible though? So those devices won't ever need to be updated ... in theory
- vertex-four 12y ago
  No. HTTP/2 is an entirely separate protocol from HTTP/1.1. Any client, therefore, will have to have both HTTP/1.1 and HTTP/2 protocol stacks. What HTTP/2 does define is a way for the client to say "I support HTTP/2" and the server to say "Sure, talk HTTP/2 to me" in a way that allows the client to fall back to HTTP/1.1 if the server doesn't know about HTTP/2.
  - deleted 12y ago
    [deleted]
  - gsnedders 12y ago
    It's not entirely separate, as the abstract of it says: "This specification is an alternative to, but does not obsolete, the HTTP/1.1 message syntax. HTTP's existing semantics remain unchanged."
    - vertex-four 12y ago
      Indeed, the point of that message is essentially "HTTP/2 is an entirely new protocol, you can support HTTP/1.1 or HTTP/2 or both, but they have nothing to do with each other".
      - gsnedders 12y ago
        Well, it means all your handling of messages is the same — once you have built your object/struct/whatever of the message (from the over-the-wire syntax), you can hand it off to pre-existing code that expects HTTP/1 messages fine. Most HTTP/2 implementations share a fair bit of code with co-existing HTTP/1 ones. You don't need to redo all your caching support and handling of HTTP caching headers, you don't need to redo any support for content negotiation you have, etc.
      - dragonwriter 12y ago
        > but they have nothing to do with each other The fact that HTTP/2 retains HTTP/1.1's message semantics, as the note points out, means that they have a lot to do with each other, and that implementations will be able to share much (probably most) of their core logic. This is important -- it means that if you implement HTTP/1.1, you've done a lot of the work of implementing HTTP/2, and vice versa.
dragonwriter 12y ago
> You will realistically need to support all versions until "the end of time", or at least the end of the internet as we know it. Or until all the old devices have reached the end of their useful life; the internet hasn't been in general use that long, and what seems like "forever" looking back on a few decades of history may not going forward. And, anyway, even that's only true if the particular thing you are building is the kind of general purpose infrastructure that needs to support everything that might talk some form of HTTP anywhere, no matter how old or limited-purpose that device is. Plenty of things people actually build don't have that requirement.

engendered 12y ago

Months. Traditionally a change like this saw little enthusiasm or interest, and had a very slow uptake, because it didn't add value until all of the players changed. Now, however, browsers iterate so quickly that already there is HTTP/2 support on the majority of user desktops. If you run a Go or node.js or various other technology websites, even if you "self-host" HTTP, you likely (and should) have it behind nginx or Apache or HAProxy, and all of those are quickly implementing HTTP/2 (or more correctly changing the existing SPDY functionality to the final spec. And for those who wonder, a HTTP/1.1 Go app sitting behind a HTTP/2 proxy still delivers HTTP/2 benefits to the end user). Cloudflare had SPDY support over two years ago, so I expect they'll see very quick support. Of course, and you addressed this, this doesn't mean that HTTP/1.1 disappears. Heck, my web properties still see HTTP/1.0 requests, almost a decade after HTTP/1.1. But that is a very small minority.

theallan 12y ago
> Apache [...] are quickly implementing HTTP/2 Do you have a link to any development Apache are doing on HTTP/2? I asked about it in the previous HTTP/2 thread but there wasn't any replies and I haven't been able to find any myself. I know there is mod_spdy but that appears to be abandoned now [1]. [1] https://svn.apache.org/viewvc/httpd/mod_spdy/trunk/ https://svn.apache.org/viewvc/httpd/mod_spdy/trunk/
- engendered 12y ago
  You know, I actually can't find anything and may have incorrectly included Apache in the "keeping up" category. The whole Apache ecosystem almost seems...defeatist now. Google donated mod_spdy to the Apache foundation and it doesn't look like it has been touched since -- given that HTTP/2 is a derivative of SPDY, the existence of that module should make it a "relatively" (relative being, well, relative) simple change, but you're right that they don't seem to be on it.
  - jimjag 12y ago
    Actually, moving from SPDY to HTTP/2 isn't any easier than going from HTTP/1.1 to HTTP/2. Google's mod_spdy was nice, but required lots of core code changes, so it was more a proof of concept. And with SPDY changing so much, wasting time on development makes little sense and, considering that SPDY (having served its purpose) is now dead, some would say that it was wise not jumping on the bandwagon quickly. But Apache is hardly alone is having a "wait and see" attitude towards HTTP/2; both HAproxy and Varnish see HTTP/2 as a solution for the wrong problem.

deleted 12y ago

[deleted]

CJefferson 12y ago

Well, in 2003 (14 years after the release of HTTP 1.1), Twitter considered it acceptable to remove HTTP 1.0 from their API access (You can still access the website itself fine over 1.0). I expect to see 1.0, 1.1 and 2.0 continue to live on basically forever. Of course, the interesting question will be how fast will the majority of users, and servers, be running 2.0?

engendered 12y ago
The majority of desktop browsers in use already support HTTP/2. Things are going to be slower on mobile, obviously. Thankfully it isn't all or nothing -- your server side load balancer / SSL termination supports HTTP/1, 1.1, and 2.0, and provides the client the experience they can support.
- billyhoffman 12y ago
  Why slower on mobile? The upgrade cycle on phones is much shorter than PCs, so even if you never put new software on a phone, you'll get an HTTP/2 enabled browser quickly. On the software side, Google-derived Android comes with Chrome by default, which already support SPDY and HTTP/2 support is imminent. Safari on iOS 8 supports SPDY, ditto on HTTP/2 coming soon. Both those software updates can be done instantly (via Google Play Services) or within a year (yearly iOS updates). So I'd think mobile support is coming very quickly.
  - asadotzler 12y ago
    It's not about the upgrade cycle of the hardware, but the software. Browsers stay up to date automatically, even on 10 year old PCs. Phones are often abandoned by their providers and run old versions of the OS that are not automatically updated to the latest browser tech.
  - nly 12y ago
    > Why slower on mobile? The upgrade cycle on phones is much shorter than PCs Disagree. Phone manufacturers adopt Android versions slowly, especially at the low end, and on PC both Firefox and Chrome update themselves.

atonse 12y ago

My take is that browser support will be very fast, because of evergreen browsers. I'm also guessing a majority of the top 500 sites will support it pretty quickly (on the order of a year or two). Everything else, will be a long tail of a decade or more. Edit: Just wanted to add that, I think the better goal is "majority of traffic using HTTP/2" - that's probably 5 years because the majority of traffic probably comes down to the top 500 sites.

mrottenkolber 12y ago

I am still happily running HTTP/1.0 and didn't plan to "upgrade" ever tbh. I hope the web stays backwards compatible.

kstrauser 12y ago
Eww, why? HTTP/1.1 is an upgrade in every way over 1.0 with no disadvantages. If nothing else, 1.1 added the "Host:" header so that you can put two domains on the same IP.

marcosdumay 12y ago

Just to reinforce it, HTTP/2 is not a replacement for HTTP/1.1. It's an optimization for a few very important use cases, but it does not support most of the different ways HTTP is used everywhere. Even for the cases it optimizes, one's recommended to verify if there's really any performance enhancement after deploying it, because there are several variables that could make it worse.

otabdeveloper1 12y ago

> 1 year? 5 years? Never. Like IPv6, HTTP/2 is a broken standard that doesn't solve any problems. The problem with the Web isn't a lack of out-of-order requests, the problem with the Web are those horrible ever-present Javascript frameworks. (Likewise, the problem with IPv4 isn't a lack of address space, the problem with IPv4 is a lack of a standard and simple way for managing VPNs and tunnels. I don't want my lightbulbs to be connected to the global Internet. What I _do_ want is a way to tunnel remotely and securely into my home's LAN and control the lightbulbs from the inside.)

dragonwriter 12y ago
> The problem with the Web isn't a lack of out-of-order requests, the problem with the Web are those horrible ever-present Javascript frameworks. To the extent that's a problem with the web (its hardly as if the web can only have one problem), that's the domain that progressive HTML (and JS) standards can address (and are addressing.) The more core HTML does, the less JS you need, the more core JS does, the less framework you need when you need JS at all.
mister_m 12y ago
Not to be rude, but I honestly am unable to determine if you are being sarcastic.
kingmanaz 12y ago
>The problem with the Web isn't a lack of out-of-order requests, the problem with the Web are those horrible ever-present Javascript frameworks. Agreed. Javascript should become web assembly, evolving into an intermediate language which other languages are compiled to. Callback heavy code is a huge barrier to entry for people that want to get things done with the web. Likewise, the industry hasn't been satisfied with the framework abstractions built on such a model (hence the constant, near daily flux in framework fads). It's been said here before that the web needs to consult TCL's ~25 year old TK framework for guidence on how a simple GUI framework can be accomplished without OO. Programming TK is akin to "heaping up" a shell script from small components. Anyone can do it, and they needn't resort to the sophistry of FactoryFactories et. al. http://www.tkdocs.com/tutorial/ http://www.tkdocs.com/tutorial/

ForHackernews 12y ago

How's the IPv6 switchover going?

kstrauser 12y ago
5% of Google's traffic these days and growing on a hockey stick: http://www.google.com/intl/en/ipv6/statistics.html http://www.google.com/intl/en/ipv6/statistics.html . My Comcast cable Internet comes with a native IPv6 block.
- omgitstom 12y ago
  It is amazing that the % of traffic using IPv6 is higher on the weekends... I wonder what is causing that cycle
  - tjgq 12y ago
    Possibly the same reason why the market share of old versions of Internet Explorer is higher on workdays: slower uptake on corporate environments when compared to residential customers.
- ForHackernews 12y ago
  IPv6 was formalized in 1998, so if HTTP/2 follows the same trend, I guess we'll be at 5% adoption by 2032?
  - dragonwriter 12y ago
    Why would HTTP/2 follow the same trend? IPv6 requires not just the endpoints, but the routers in between to be on board with it. HTTP/2 only requires end-points. There's a lot less friction for HTTP/1.1 -> HTTP/2 upgrades than IPv4 -> IPv6 upgrades.