5 ms·

https://www.youtube.com/watch?v=-yxQIRl6Qic https://www.youtube.com/watch?v=-yxQIRl6Qic talks in great detail about why http2 exists and why it does things the

by kjksf 12y ago

https://www.youtube.com/watch?v=-yxQIRl6Qic https://www.youtube.com/watch?v=-yxQIRl6Qic talks in great detail about why http2 exists and why it does things the way it does. It also addresses the usual complaints, including the "binary" part. The short version is that is all about speed and security (by encrypting everything). As to the issue of binary vs. text. Implementing binary protocols (including tools used for debugging them) is much simpler than implementing text protocol. HTTP1 might look simple to human eyes but it's not an easy protocol to implement (fully and correctly). I know, I tried. Furthermore, engineering is about tradeoffs. HTTP2 is not simple but the complexity exists to address real problems in failure modes of tcp stack and to maximize speed by both sending as little as possible (compression) and ensuring that one request doesn't block the other, as long as there is bandwidth to send both. Maybe the purity and simplicity of the protocol is more important to you than improving the speed by few %, but to make it makes perfect sense to trade simplicity for even modest gains in performance in the context of http. You only write the code once but it'll speed up every http connection until end of time. That's a lot of http connections which adds up to a lot of bandwidth and time savings.

jacquesm 12y ago
Bandwidth is cheap. I don't buy that argument, but I do see that there are problems with HTTP and the way it is implemented. I think that if you are going to implement something that will replace HTTP that it had better be something that is huge step up from what we have today and in that respect HTTP2 fails to convince me that it is that step. Keep in mind that we're talking about the protocol that currently powers much of the developed world as we know it and that mistakes will be extremely costly to correct. HTTP has its warts and quirks but for the most part we have worked our way around those. Minor efficiency gains do not add up for me to a complete overhaul of the web and everything attached to it. So what we'll get instead is this: a percentage of the web will transition (mostly the bigger players where that few % adds up to a higher bottom line), the rest will not care and wait for HTTP3 or whatever will come after HTTP2 to really address what's wrong with HTTP (and that's not that it isn't fast enough, that's mostly a problem with the underlying transports, HTTP is plenty fast).
- fpgeek 12y ago
  > Bandwidth is cheap. Says someone who I'm certain doesn't rely on a prepaid SIM for their primary Internet connection. Not that I do either, but I'm far more aware that tens (if not hundreds) of millions of these people exist today. In fact, it's likely that such people will be a clear majority of Internet users early in the life of HTTP2. Leaving them out of the conversation, as you implicitly do here, would be a colossal mistake for a protocol that intended to stand the test of time.
  - jacquesm 12y ago
    The difference between HTTP and HTTP2 is not noticeable cost-wise on the consumer side, it is only noticeable in the aggregate when serving millions of requests. Let's not try to pretend that HTTP2 is about bandwidth savings in the third world, that didn't even enter the consideration at any level. If you want to save bandwidth at that level then you're better off reducing eye candy and using apps rather than websites and not shipping bloated pages with 100's of requests and 1/2 MB of javascript frameworks across to mobile devices. Shaving a couple of bytes off a header is not going to move the needle there. For the record, I ran my internet connection of one of those pre-paid SIM cards for a month and the big killers were websites that keep refreshing their pages, javascript frameworks and advertising.
    - fpgeek 12y ago
      I agree the developing world wasn't an explicit consideration, but mobile most certainly was. And since better mobile performance and behavior is what developing world Internet clients most need from a new protocol, many of their concerns are being explicitly addressed. As for whether "shaving a couple of bytes off of a header" makes a practical difference, you should consider the "Why do we need header compression?" answer here: http://http2.github.io/faq/ http://http2.github.io/faq/ which references concrete evidence provided by an HTTP2 advocate. Personally, I find that more convincing than your apparently unsupported assertion. Separately, it's nice to say websites should drop the eye candy and the Javascript frameworks (the hundreds of requests is addressed by HTTP2 multiplexing, I believe), but that's missing the point. As has been repeatedly demonstrated since the earliest days of WAP, mobile users don't want a stripped-down subset of the Internet, they want as much as they can get. From that perspective, raising the bar on what's possible (as HTTP2 tries to do) moves the ball far more than trying to convince websites to fit themselves into today's constraints (especially since the mobile user in the developing world has one of the strictest versions of those constraints).
dingaling 12y ago
> The short version is that is all about speed and security (by encrypting everything). I'm not up to speed on certificate verification for HTTP2. Have the IETF suggested a mechanism? If so t must be outside the draft-ietf-httpbis-http2-16.

by kjksf 12y ago

jacquesm 12y ago

Bandwidth is cheap. I don't buy that argument, but I do see that there are problems with HTTP and the way it is implemented. I think that if you are going to implement something that will replace HTTP that it had better be something that is huge step up from what we have today and in that respect HTTP2 fails to convince me that it is that step. Keep in mind that we're talking about the protocol that currently powers much of the developed world as we know it and that mistakes will be extremely costly to correct. HTTP has its warts and quirks but for the most part we have worked our way around those. Minor efficiency gains do not add up for me to a complete overhaul of the web and everything attached to it. So what we'll get instead is this: a percentage of the web will transition (mostly the bigger players where that few % adds up to a higher bottom line), the rest will not care and wait for HTTP3 or whatever will come after HTTP2 to really address what's wrong with HTTP (and that's not that it isn't fast enough, that's mostly a problem with the underlying transports, HTTP is plenty fast).

fpgeek 12y ago
> Bandwidth is cheap. Says someone who I'm certain doesn't rely on a prepaid SIM for their primary Internet connection. Not that I do either, but I'm far more aware that tens (if not hundreds) of millions of these people exist today. In fact, it's likely that such people will be a clear majority of Internet users early in the life of HTTP2. Leaving them out of the conversation, as you implicitly do here, would be a colossal mistake for a protocol that intended to stand the test of time.
- jacquesm 12y ago
  The difference between HTTP and HTTP2 is not noticeable cost-wise on the consumer side, it is only noticeable in the aggregate when serving millions of requests. Let's not try to pretend that HTTP2 is about bandwidth savings in the third world, that didn't even enter the consideration at any level. If you want to save bandwidth at that level then you're better off reducing eye candy and using apps rather than websites and not shipping bloated pages with 100's of requests and 1/2 MB of javascript frameworks across to mobile devices. Shaving a couple of bytes off a header is not going to move the needle there. For the record, I ran my internet connection of one of those pre-paid SIM cards for a month and the big killers were websites that keep refreshing their pages, javascript frameworks and advertising.
  - fpgeek 12y ago
    I agree the developing world wasn't an explicit consideration, but mobile most certainly was. And since better mobile performance and behavior is what developing world Internet clients most need from a new protocol, many of their concerns are being explicitly addressed. As for whether "shaving a couple of bytes off of a header" makes a practical difference, you should consider the "Why do we need header compression?" answer here: http://http2.github.io/faq/ http://http2.github.io/faq/ which references concrete evidence provided by an HTTP2 advocate. Personally, I find that more convincing than your apparently unsupported assertion. Separately, it's nice to say websites should drop the eye candy and the Javascript frameworks (the hundreds of requests is addressed by HTTP2 multiplexing, I believe), but that's missing the point. As has been repeatedly demonstrated since the earliest days of WAP, mobile users don't want a stripped-down subset of the Internet, they want as much as they can get. From that perspective, raising the bar on what's possible (as HTTP2 tries to do) moves the ball far more than trying to convince websites to fit themselves into today's constraints (especially since the mobile user in the developing world has one of the strictest versions of those constraints).

dingaling 12y ago

> The short version is that is all about speed and security (by encrypting everything). I'm not up to speed on certificate verification for HTTP2. Have the IETF suggested a mechanism? If so t must be outside the draft-ietf-httpbis-http2-16.