11 ms·

HTTP/2 all the things

335 points by matsuu 12y ago

BorisMelnik 12y ago
Wow what a great history lesson. I had no idea HTTP 1 (or .9) was basically an "idea framework" for the www. Sounds like this will help solve some major issues and organize the interwebs a bit better.
hnmcs 12y ago
Hell yeah, Ilya Grigorik. https://www.igvita.com/archives https://www.igvita.com/archives "A word to the wise is sufficient." When he speaks, it's quite often relevant at a quantum level beyond your average tech post or presentation.
devanti 12y ago
i'm assuming clients and web servers that start to support http2 will also be backwards compatible with http1.1 which seems necessary
mjevans 12y ago
"push 'tombstone' record to invalidate cache" For that /alone/ this is technically superior and that's frosting on the cake. Now if only we could also get DNS servers to reply with similar packages of useful data.
- Arnt 12y ago
  They do, it's called "additional data". There are issues about cache poisoning and a bit more, but the concept exists and is used.
est 12y ago
I wonder what's QUIC's role in this? An UDP based multi-home roaming protocol looks so much better for today's mobile internet world.
- Lukasa 12y ago
  HTTP/2 is redesigning the application layer protocol for the modern internet. QUIC is an attempt to redesign the transport layer. The two should work hand-in-hand. It'll be interesting to see how it works out!
angersock 12y ago
People do realize that this is going to mainly benefit large companies, right? Anybody who still scatters their resources across many CDNs and whatnot is probably not going to see a tremendous benefit. I'm not convinced that the 30-40% improvement in performance (in some cases) is worth the additional complexity. There are some nice features, but I can't help but think that this is something being pushed mainly by Google et al. because it benefits their server farms as opposed to being an objectively good idea. At least it should be relatively easy to setup on a server.
- enneff 12y ago
  You don't think the web being almost twice as fast is worth it? Really?
  - angersock 12y ago
    Twice as fast, in some cases. I don't think--and again, this is just my opinion--that giving up the simplicity of the protocol that has somehow brought us in the last twenty years from barely functioning text to the modern web is a good idea. I believe that especially given that the big benefits seem predicated on very centralized authorities and large-scale companies. If you're Google or Facebook or Twitter, this is great. If you're anyone else, it's not really a huge win.
    - afro88 12y ago
      We're not giving up anything (1.1 support will be around for quite some time). The benefits won't be for small site owners, but for end users. At a guess, I'd say at least 60% of my daily web use is to big company sites (facebook, google, twitter, news organisations etc). This will result in a huge speed increase for most end users.
  - m_eiman 12y ago
    30% faster... IF you've got your page split up into 78 requests on 12 different hosts using 1.2 MB. Btw, do they still have the special case handling of headers and whatnot that hardcodes today's implementation details and "best practies" into the protocol we're supposed to use for decades ahead?
higherpurpose 12y ago
It's a shame they dropped mandatory encryption. Now "HTTP2 all the things" doesn't mean "encrypt all the things" anymore.
- Lukasa 12y ago
  In practice it very nearly does. Only IE plan to support plaintext HTTP/2, all other browsers will only support it over TLS. Opportunistic Encryption is still on the table as well.
  - byuu 12y ago
    The one major advantage to TLS everywhere will definitely be avoiding mixed-content issues when eg you have a web forum and someone tries to embed an image on a non-TLS server into their post. Hopefully IE's choice to be the one non-TLS HTTP/2 supporter doesn't undermine this. Since this is just going to be how it is, I just hope we can do more to make setting up TLS easier for everyone.
  - higherpurpose 12y ago
    Ah, once again Microsoft is the one that supports less security than the other major companies. Microsoft needs to distance itself a bit more from law enforcement agencies.
    - Lukasa 12y ago
      I got the impression that Microsoft is backing this because of pressure from large enterprises, which do not want to deploy TLS in their intranets. I don't believe IE will prefer plaintext HTTP/2 to TLS HTTP/2, and it will certainly deploy both. Put another way: I don't believe Microsoft is worse than Google in this regard.
- Nullabillity 12y ago
  On the other hand, while "encrypt all the things" is a noble goal, the CA problem has to be sorted out first.
- 12y ago
byuu 12y ago
Having written an HTTP server+proxy recently, I haven't been super impressed with HTTP/2 so far. There is some good in it (basically everything I'm not mentioning), but also a lot of bad. First, Firefox (and some others) are forcing TLS to use HTTP/2 : https://wiki.mozilla.org/Networking/http2 https://wiki.mozilla.org/Networking/http2 ; that's a big deal breaker for a lot of people. Yes, encryption is all well and good. I'll all for it! But SSL certs either cost money, or you get them from companies that will want cash to revoke them for you if compromised. SSL/TLS errors are still a royal bitch (and pop up with less popular authorities), with browsers warning you of your impending undoing if you choose to continue (sometimes damn near requiring a blood contract to override.) They also require extra CPU resources. This can be a problem for a site that is only hosting kitten pictures or video game news. It's also a barrier toward people like me experimenting with it, since I now also have to learn how to use TLS if I just want to toy around with the protocol. Second, I don't really agree that using a new, custom-made compression algorithm is a smart way to do headers. We are talking about ~300 bytes of data per header ... are the bandwidth gains really so superior to outweigh the CPU costs in having to compress the data, and to overcome the added programming complexity in working with these headers? Third, it's really a fundamentally different way to do things. Like the slides said, you're going to have to really redesign how servers and website packages serve up content to be optimized for this new model, or else performance may even be worse than HTTP/1.1 ... having seen the way the real world works, I'm not very confident that web developers are going to take this seriously enough, and we'll likely see a lot of "HTTP/1 over HTTP/2" behavior anyway (eg not taking advantage of server push.) The servers like Apache and nginx can only go so far toward doing this for you. Fourth, since it's not backward-compatible, we're pretty much not going to be able to use HTTP/2 exclusively for another 5 - 10 years. Which, of course, doesn't mean we shouldn't ever upgrade HTTP/1. It's just kind of crappy that we have to basically run two very different HTTP engines that serve content very differently for the next decade, waiting for people to upgrade their browsers. I would have liked to have seen an HTTP/1.2 intermediary step that added a few extra headers, like 'Server-Push: "filename", ETag'; and perhaps a specification rule that no HTTP/1.2 request could ever ask for /favicon.ico or /apple-touch-icon.png. Just that would have reduced countless extra wasteful connection requests -> 304 Not Modified responses that we have today on HTTP/1.1, without having to resort to max-age and not being able to instantly update your site anymore. And it would just silently keep working for HTTP/1.1 users (obviously without the 1.2 benefits.) ... Also, all of these slides are always pretty sparse. Given that the new header format is binary, does anyone know how clients are going to go about requesting HTTP/2 capabilities? Is there a special HTTP/1.1 header? Because Apache will respond to "GET / HTTP/2" with an HTTP/1.1 OK response at present. (In fact, it responds with 200 OK even to "GET / ITS_JUST_A_HARMLESS_LITTLE_BUNNY/3.141592" ...)
insertnickname 12y ago
It's interesting that modern web developers don't consider that maybe websites are slow because they keep stuffing them to the brim with every conceivable script and other resources from 30 different domains. No, of course that's not why the web is slow. The web is obviously slow because HTTP is too slow.
- Animats 12y ago
  Right. Multiplexing over one pipe won't help when content is being pulled in from four ad networks, five trackers, three social networks, a site that hosts Jquery, and another site that hosts fonts. This works for Google because their sites load almost entirely from Googleworld.
  - icebraining 12y ago
    So HTTP/2 provides an incentive to put the analytics, jQuery, etc on the main server, reducing third-party spying? Sounds like a win-win to me.
    - ddalex 12y ago
      Sounds like the worst idea ever to me. It will stiffle inovation and adoption of technologies developed by those with not-the-biggest-site-in-the-world. Functioning again as a barier against net neutrality, it goes against everything that made the Internet open and great.
      - icebraining 12y ago
        How will it stifle innovation or function as a barrier against net neutrality?
        TheLoneWolfling 12y ago
        > function as a barrier against net neutrality? Much easier to throttle traffic from a website when it's actually from a website. If many websites reference the same external resources, it's harder to throttle websites individually.
_stephan 12y ago
The current specification of priorities in HTTP/2 seems problematic (and apparently was agreed upon by coin toss): http://lists.w3.org/Archives/Public/ietf-http-wg/2014OctDec/0450.html http://lists.w3.org/Archives/Public/ietf-http-wg/2014OctDec/...
adam-a 12y ago
I'm curious about how the Header tables are supposed to work. How does the client reliably know which request was last received by the server? In the example > method: GET > path: /resource > ... can be followed by just > path: /other_resource but how do I know a badly behaving router didn't delay a DELETE request from earlier? Do I have to manually table all my responses to make sure there are no potentially dangerous requests on the wire?
- Lukasa 12y ago
  There are a few key points here. First, Ilya's slides are out of date. The reference set got removed (it was a complexity nightmare), so there's a bit less efficiency in deltas but a substantially simpler algorithm for header sets. As for your badly behaved router, there are two options. The first is that it's a router, not a proxy. In that case, the strict ordering of TCP ensures that there's no problem here. A router cannot cause the server to miss a request without knowing about it. Assuming by 'router' you meant 'proxy', the key here is that HPACK compression state is hop-by-hop, not end-to-end. That is, HPACK compression state is only synchronised at each end of a TCP connection. The strict ordering of TCP ensures that those two ends cannot be confused about the order of requests. Across TCP connections, there's new HPACK state.
  - adam-a 12y ago
    Ah thanks for explaining it. I'm so used to thinking of http as a set of concurrent requests, but as a single stream optimisations like this make sense.
teddyh 12y ago
No mention of SRV records. Of course. https://news.ycombinator.com/item?id=8404788 https://news.ycombinator.com/item?id=8404788 It really is no surprise that Google is not interested in this, since Google does not suffer from any of those problems which using SRV records for HTTP would solve. It’s only users which could more easily run their own web servers closer to the edges of the network which would benefit, not the large companies which has CDNs and BGP AS numbers to fix any shortcomings the hard way. Google has already done the hard work of solving this problem for themselves – of course they want to keep the problem for everybody else. This is going to bite them big time in the end, because Google got large by indexing the Geocities-style web, where everybody did have their own web page on a very distributed set of web hosts. What Google is doing is only contributing to the centralization of the Web, the conversion of the Web into Facebook, which will, in turn, kill Google, since they then will have nothing to index. They sort of saw this coming, but their idea of a fix was Google+ – trying to make sure that they were the ones on top. I think they are still hoping for this, which is why they won’t allow a decentralized web by using SRV records in HTTP/2.
- personZ 12y ago
  Of the varied bizarrely negative posts this submission has earned, yours is the one that perplexes me most. How is HTTP/2 going to "bite" Google (even if we assume that Google is the only initiator of the HTTP/2 spec, while they're far from it)? Is the web, right now, failing? Are those little sites somehow not existing? You seem to be positing that a new standard not supporting your pet feature is suddenly going to destroy the web, which seems a little hysterical. Interesting to note that as a relatively small shop we've already seen huge benefits from SPDY (the precursor) because it allows us to serve from a single site in the US, offering a much, much better experience for our users in Singapore (the benefits to high latency connections are significantly higher than the results commonly reported).
  - teddyh 12y ago
    I thought I expressed myself reasonably clearly. The web is currently slowly centralizing and turning into Facebook. Google could fight this trend by using SRV records for HTTP/2. If, otherwise, this trend continues, Google will eventually have nothing in the open web to index, and will therefore get no value from selling ads in their search service. Therefore, Google is doing itself a disservice by not using SRV records in HTTP/2. I further speculated about the reasons Google might have for acting the way the do – i.e. not supporting SRV records. I proposed two reasons: First, SRV records do not solve any problem which Google has not already solved for themselves, and they do not want anybody else to simply get the solution for free, since that would devalue their previous investment. Second, Google assumed that they would be the ones that the Web would centralize into, and even since Facebook has appeared, Google created Google+ and tried to push it as a centralization point, using every pressure point they could muster (YouTube, etc.) to make this happen. If they could make this happen, they also would not benefit from a more decentralized web as would be enabled by SRV records in HTTP/2.
kator 12y ago
The first 100ms to 160ms of the Yahoo call is RTB[1] delay. I don't see how HTTP/2 will fix that. Also notice all the various analytics beacons that will still be third party in the future. I know many people hate this stuff but when you're Yahoo! and most of your income is from advertisements on your web site you will still have to sell that inventory and prove to third parties they got what they paid for via various "pixels". I don't doubt there is a lot of room to improve, clearly a lot was learned from SPDY and other projects. But I do worry that what we're actually doing is rewarding large companies who can bring all the stuff into one stream and the small sites will be yet more disadvantaged. I could see a world where this is used as a way for PHB's[2] to justify "just move our stuff to Google/Amazon/Apple". These sort of initiatives may incentivize more centralization and IMHO that is not a good thing. Also being an old guy(tm) I worry about loosing the ability for humans to talk to these services or see the conversation in a textual way. Before you explode on that comment think about the balance of JSON -vs- various binary serialization solutions. How many of us have chosen a serialization protocol because "we can read it". I'm not arguing that as a perfect argument, but if you're already pushing TLS and HPACK then why not at least leave the textual data in there? I guess I worry that now we head down the RFC hell where only large bodies can get extensions in the protocol because we only have 256 options on this header and each bit counts. To be fair I've not deep dove the protocol yet, I suppose theses are just rantings of a guy who read a slide show.. :) [1] http://en.wikipedia.org/wiki/Real-time_bidding http://en.wikipedia.org/wiki/Real-time_bidding [2] http://en.wikipedia.org/wiki/Pointy-haired_Boss http://en.wikipedia.org/wiki/Pointy-haired_Boss
- Lukasa 12y ago
  > Also being an old guy(tm) I worry about loosing the ability for humans to talk to these services or see the conversation in a textual way. This is definitely a loss. It's real, it's unfortunate. But the binary-vs-text change is actually pretty minor: a well-crafted binary protocol permits simple tools that can be used to debug it. The actual problem here is that HTTP/2 is highly stateful. Connection state, stream state, and header compression state are all required to actually reliably debug a HTTP/2 flow. In practice, that means either your HTTP/2 implementation needs to be able to dump its state, or you need to capture the entire session to understand it. For my part, I will not mourn the ability to telnet to a port and type HTTP. In practice, that approach lacks value in most modern cases. However, I will mourn the loss of tcpdump as a single HTTP debugging tool. Your implementations now need to make debugging possible in their own right.
dsr_ 12y ago
What's the number one thing people who run web servers are concerned about? It's not performance. It's not customer experience. It's reachability. When a person with a browser clicks, they have to receive the page they clicked on before anything else can happen. Seems obvious, right? In order to do that, they need a web server that they trust. Most people opt for Apache, nginx or IIS. Which of those has well-tested and trustworthy HTTP/2 implementations?
- wmf 12y ago
  All of them will.

335 points by matsuu 12y ago

Wow what a great history lesson. I had no idea HTTP 1 (or .9) was basically an "idea framework" for the www. Sounds like this will help solve some major issues and organize the interwebs a bit better.

hnmcs 12y ago

Hell yeah, Ilya Grigorik. https://www.igvita.com/archives https://www.igvita.com/archives "A word to the wise is sufficient." When he speaks, it's quite often relevant at a quantum level beyond your average tech post or presentation.

devanti 12y ago

i'm assuming clients and web servers that start to support http2 will also be backwards compatible with http1.1 which seems necessary

mjevans 12y ago

"push 'tombstone' record to invalidate cache" For that /alone/ this is technically superior and that's frosting on the cake. Now if only we could also get DNS servers to reply with similar packages of useful data.

Arnt 12y ago
They do, it's called "additional data". There are issues about cache poisoning and a bit more, but the concept exists and is used.

est 12y ago

I wonder what's QUIC's role in this? An UDP based multi-home roaming protocol looks so much better for today's mobile internet world.

Lukasa 12y ago
HTTP/2 is redesigning the application layer protocol for the modern internet. QUIC is an attempt to redesign the transport layer. The two should work hand-in-hand. It'll be interesting to see how it works out!

angersock 12y ago

People do realize that this is going to mainly benefit large companies, right? Anybody who still scatters their resources across many CDNs and whatnot is probably not going to see a tremendous benefit. I'm not convinced that the 30-40% improvement in performance (in some cases) is worth the additional complexity. There are some nice features, but I can't help but think that this is something being pushed mainly by Google et al. because it benefits their server farms as opposed to being an objectively good idea. At least it should be relatively easy to setup on a server.

enneff 12y ago
You don't think the web being almost twice as fast is worth it? Really?
- angersock 12y ago
  Twice as fast, in some cases. I don't think--and again, this is just my opinion--that giving up the simplicity of the protocol that has somehow brought us in the last twenty years from barely functioning text to the modern web is a good idea. I believe that especially given that the big benefits seem predicated on very centralized authorities and large-scale companies. If you're Google or Facebook or Twitter, this is great. If you're anyone else, it's not really a huge win.
  - afro88 12y ago
    We're not giving up anything (1.1 support will be around for quite some time). The benefits won't be for small site owners, but for end users. At a guess, I'd say at least 60% of my daily web use is to big company sites (facebook, google, twitter, news organisations etc). This will result in a huge speed increase for most end users.
- m_eiman 12y ago
  30% faster... IF you've got your page split up into 78 requests on 12 different hosts using 1.2 MB. Btw, do they still have the special case handling of headers and whatnot that hardcodes today's implementation details and "best practies" into the protocol we're supposed to use for decades ahead?

higherpurpose 12y ago

It's a shame they dropped mandatory encryption. Now "HTTP2 all the things" doesn't mean "encrypt all the things" anymore.

Lukasa 12y ago
In practice it very nearly does. Only IE plan to support plaintext HTTP/2, all other browsers will only support it over TLS. Opportunistic Encryption is still on the table as well.
- byuu 12y ago
  The one major advantage to TLS everywhere will definitely be avoiding mixed-content issues when eg you have a web forum and someone tries to embed an image on a non-TLS server into their post. Hopefully IE's choice to be the one non-TLS HTTP/2 supporter doesn't undermine this. Since this is just going to be how it is, I just hope we can do more to make setting up TLS easier for everyone.
- higherpurpose 12y ago
  Ah, once again Microsoft is the one that supports less security than the other major companies. Microsoft needs to distance itself a bit more from law enforcement agencies.
  - Lukasa 12y ago
    I got the impression that Microsoft is backing this because of pressure from large enterprises, which do not want to deploy TLS in their intranets. I don't believe IE will prefer plaintext HTTP/2 to TLS HTTP/2, and it will certainly deploy both. Put another way: I don't believe Microsoft is worse than Google in this regard.
Nullabillity 12y ago
On the other hand, while "encrypt all the things" is a noble goal, the CA problem has to be sorted out first.
12y ago

byuu 12y ago

Having written an HTTP server+proxy recently, I haven't been super impressed with HTTP/2 so far. There is some good in it (basically everything I'm not mentioning), but also a lot of bad. First, Firefox (and some others) are forcing TLS to use HTTP/2 : https://wiki.mozilla.org/Networking/http2 https://wiki.mozilla.org/Networking/http2 ; that's a big deal breaker for a lot of people. Yes, encryption is all well and good. I'll all for it! But SSL certs either cost money, or you get them from companies that will want cash to revoke them for you if compromised. SSL/TLS errors are still a royal bitch (and pop up with less popular authorities), with browsers warning you of your impending undoing if you choose to continue (sometimes damn near requiring a blood contract to override.) They also require extra CPU resources. This can be a problem for a site that is only hosting kitten pictures or video game news. It's also a barrier toward people like me experimenting with it, since I now also have to learn how to use TLS if I just want to toy around with the protocol. Second, I don't really agree that using a new, custom-made compression algorithm is a smart way to do headers. We are talking about ~300 bytes of data per header ... are the bandwidth gains really so superior to outweigh the CPU costs in having to compress the data, and to overcome the added programming complexity in working with these headers? Third, it's really a fundamentally different way to do things. Like the slides said, you're going to have to really redesign how servers and website packages serve up content to be optimized for this new model, or else performance may even be worse than HTTP/1.1 ... having seen the way the real world works, I'm not very confident that web developers are going to take this seriously enough, and we'll likely see a lot of "HTTP/1 over HTTP/2" behavior anyway (eg not taking advantage of server push.) The servers like Apache and nginx can only go so far toward doing this for you. Fourth, since it's not backward-compatible, we're pretty much not going to be able to use HTTP/2 exclusively for another 5 - 10 years. Which, of course, doesn't mean we shouldn't ever upgrade HTTP/1. It's just kind of crappy that we have to basically run two very different HTTP engines that serve content very differently for the next decade, waiting for people to upgrade their browsers. I would have liked to have seen an HTTP/1.2 intermediary step that added a few extra headers, like 'Server-Push: "filename", ETag'; and perhaps a specification rule that no HTTP/1.2 request could ever ask for /favicon.ico or /apple-touch-icon.png. Just that would have reduced countless extra wasteful connection requests -> 304 Not Modified responses that we have today on HTTP/1.1, without having to resort to max-age and not being able to instantly update your site anymore. And it would just silently keep working for HTTP/1.1 users (obviously without the 1.2 benefits.) ... Also, all of these slides are always pretty sparse. Given that the new header format is binary, does anyone know how clients are going to go about requesting HTTP/2 capabilities? Is there a special HTTP/1.1 header? Because Apache will respond to "GET / HTTP/2" with an HTTP/1.1 OK response at present. (In fact, it responds with 200 OK even to "GET / ITS_JUST_A_HARMLESS_LITTLE_BUNNY/3.141592" ...)

insertnickname 12y ago

It's interesting that modern web developers don't consider that maybe websites are slow because they keep stuffing them to the brim with every conceivable script and other resources from 30 different domains. No, of course that's not why the web is slow. The web is obviously slow because HTTP is too slow.

Animats 12y ago
Right. Multiplexing over one pipe won't help when content is being pulled in from four ad networks, five trackers, three social networks, a site that hosts Jquery, and another site that hosts fonts. This works for Google because their sites load almost entirely from Googleworld.
- icebraining 12y ago
  So HTTP/2 provides an incentive to put the analytics, jQuery, etc on the main server, reducing third-party spying? Sounds like a win-win to me.
  - ddalex 12y ago
    Sounds like the worst idea ever to me. It will stiffle inovation and adoption of technologies developed by those with not-the-biggest-site-in-the-world. Functioning again as a barier against net neutrality, it goes against everything that made the Internet open and great.
    - icebraining 12y ago
      How will it stifle innovation or function as a barrier against net neutrality?
      - TheLoneWolfling 12y ago
        > function as a barrier against net neutrality? Much easier to throttle traffic from a website when it's actually from a website. If many websites reference the same external resources, it's harder to throttle websites individually.

_stephan 12y ago

The current specification of priorities in HTTP/2 seems problematic (and apparently was agreed upon by coin toss): http://lists.w3.org/Archives/Public/ietf-http-wg/2014OctDec/0450.html http://lists.w3.org/Archives/Public/ietf-http-wg/2014OctDec/...

adam-a 12y ago

I'm curious about how the Header tables are supposed to work. How does the client reliably know which request was last received by the server? In the example > method: GET > path: /resource > ... can be followed by just > path: /other_resource but how do I know a badly behaving router didn't delay a DELETE request from earlier? Do I have to manually table all my responses to make sure there are no potentially dangerous requests on the wire?

Lukasa 12y ago
There are a few key points here. First, Ilya's slides are out of date. The reference set got removed (it was a complexity nightmare), so there's a bit less efficiency in deltas but a substantially simpler algorithm for header sets. As for your badly behaved router, there are two options. The first is that it's a router, not a proxy. In that case, the strict ordering of TCP ensures that there's no problem here. A router cannot cause the server to miss a request without knowing about it. Assuming by 'router' you meant 'proxy', the key here is that HPACK compression state is hop-by-hop, not end-to-end. That is, HPACK compression state is only synchronised at each end of a TCP connection. The strict ordering of TCP ensures that those two ends cannot be confused about the order of requests. Across TCP connections, there's new HPACK state.
- adam-a 12y ago
  Ah thanks for explaining it. I'm so used to thinking of http as a set of concurrent requests, but as a single stream optimisations like this make sense.

teddyh 12y ago

No mention of SRV records. Of course. https://news.ycombinator.com/item?id=8404788 https://news.ycombinator.com/item?id=8404788 It really is no surprise that Google is not interested in this, since Google does not suffer from any of those problems which using SRV records for HTTP would solve. It’s only users which could more easily run their own web servers closer to the edges of the network which would benefit, not the large companies which has CDNs and BGP AS numbers to fix any shortcomings the hard way. Google has already done the hard work of solving this problem for themselves – of course they want to keep the problem for everybody else. This is going to bite them big time in the end, because Google got large by indexing the Geocities-style web, where everybody did have their own web page on a very distributed set of web hosts. What Google is doing is only contributing to the centralization of the Web, the conversion of the Web into Facebook, which will, in turn, kill Google, since they then will have nothing to index. They sort of saw this coming, but their idea of a fix was Google+ – trying to make sure that they were the ones on top. I think they are still hoping for this, which is why they won’t allow a decentralized web by using SRV records in HTTP/2.

personZ 12y ago
Of the varied bizarrely negative posts this submission has earned, yours is the one that perplexes me most. How is HTTP/2 going to "bite" Google (even if we assume that Google is the only initiator of the HTTP/2 spec, while they're far from it)? Is the web, right now, failing? Are those little sites somehow not existing? You seem to be positing that a new standard not supporting your pet feature is suddenly going to destroy the web, which seems a little hysterical. Interesting to note that as a relatively small shop we've already seen huge benefits from SPDY (the precursor) because it allows us to serve from a single site in the US, offering a much, much better experience for our users in Singapore (the benefits to high latency connections are significantly higher than the results commonly reported).
- teddyh 12y ago
  I thought I expressed myself reasonably clearly. The web is currently slowly centralizing and turning into Facebook. Google could fight this trend by using SRV records for HTTP/2. If, otherwise, this trend continues, Google will eventually have nothing in the open web to index, and will therefore get no value from selling ads in their search service. Therefore, Google is doing itself a disservice by not using SRV records in HTTP/2. I further speculated about the reasons Google might have for acting the way the do – i.e. not supporting SRV records. I proposed two reasons: First, SRV records do not solve any problem which Google has not already solved for themselves, and they do not want anybody else to simply get the solution for free, since that would devalue their previous investment. Second, Google assumed that they would be the ones that the Web would centralize into, and even since Facebook has appeared, Google created Google+ and tried to push it as a centralization point, using every pressure point they could muster (YouTube, etc.) to make this happen. If they could make this happen, they also would not benefit from a more decentralized web as would be enabled by SRV records in HTTP/2.

kator 12y ago

The first 100ms to 160ms of the Yahoo call is RTB[1] delay. I don't see how HTTP/2 will fix that. Also notice all the various analytics beacons that will still be third party in the future. I know many people hate this stuff but when you're Yahoo! and most of your income is from advertisements on your web site you will still have to sell that inventory and prove to third parties they got what they paid for via various "pixels". I don't doubt there is a lot of room to improve, clearly a lot was learned from SPDY and other projects. But I do worry that what we're actually doing is rewarding large companies who can bring all the stuff into one stream and the small sites will be yet more disadvantaged. I could see a world where this is used as a way for PHB's[2] to justify "just move our stuff to Google/Amazon/Apple". These sort of initiatives may incentivize more centralization and IMHO that is not a good thing. Also being an old guy(tm) I worry about loosing the ability for humans to talk to these services or see the conversation in a textual way. Before you explode on that comment think about the balance of JSON -vs- various binary serialization solutions. How many of us have chosen a serialization protocol because "we can read it". I'm not arguing that as a perfect argument, but if you're already pushing TLS and HPACK then why not at least leave the textual data in there? I guess I worry that now we head down the RFC hell where only large bodies can get extensions in the protocol because we only have 256 options on this header and each bit counts. To be fair I've not deep dove the protocol yet, I suppose theses are just rantings of a guy who read a slide show.. :) [1] http://en.wikipedia.org/wiki/Real-time_bidding http://en.wikipedia.org/wiki/Real-time_bidding [2] http://en.wikipedia.org/wiki/Pointy-haired_Boss http://en.wikipedia.org/wiki/Pointy-haired_Boss

Lukasa 12y ago
> Also being an old guy(tm) I worry about loosing the ability for humans to talk to these services or see the conversation in a textual way. This is definitely a loss. It's real, it's unfortunate. But the binary-vs-text change is actually pretty minor: a well-crafted binary protocol permits simple tools that can be used to debug it. The actual problem here is that HTTP/2 is highly stateful. Connection state, stream state, and header compression state are all required to actually reliably debug a HTTP/2 flow. In practice, that means either your HTTP/2 implementation needs to be able to dump its state, or you need to capture the entire session to understand it. For my part, I will not mourn the ability to telnet to a port and type HTTP. In practice, that approach lacks value in most modern cases. However, I will mourn the loss of tcpdump as a single HTTP debugging tool. Your implementations now need to make debugging possible in their own right.

dsr_ 12y ago

What's the number one thing people who run web servers are concerned about? It's not performance. It's not customer experience. It's reachability. When a person with a browser clicks, they have to receive the page they clicked on before anything else can happen. Seems obvious, right? In order to do that, they need a web server that they trust. Most people opt for Apache, nginx or IIS. Which of those has well-tested and trustworthy HTTP/2 implementations?

wmf 12y ago
All of them will.