7 ms·

I'm not ever supporting HTTP/2. For something "monumental" enough to be called the whole second revision of HTTP, what have we really gained? A Google-backed "s

I'm not ever supporting HTTP/2. For something "monumental" enough to be called the whole second revision of HTTP, what have we really gained? A Google-backed "server push" mechanism and some minor efficiency additions? Add to that the fact that SPDY was pushed through as HTTP/2 because nothing else was ready. Please. Downvoters: although I don't usually do this, I'd ask you to enter into a discussion with me instead of just hitting the down arrow. Do you honestly think my discussion is worth being silenced?

mrb 12y ago
If that doesn't convince you to support HTTP/2, then nothing will: https://www.httpvshttps.com/ https://www.httpvshttps.com/ HTTP/1.1 is 5x-15x slower in this benchmark! These insane perf gains are possible only thanks to HTTP/2, specifically thanks to its support for multiplexing. Please read the spec and understand the technical implications before criticizing. On some unrelated note: I found this tidbit of humor in the RFC draft (https://tools.ietf.org/html/draft-ietf-httpbis-http2-16 https://tools.ietf.org/html/draft-ietf-httpbis-http2-16): ENHANCE_YOUR_CALM (0xb): The endpoint detected that its peer is exhibiting a behavior that might be generating excessive load.
- fiatjaf 12y ago
  The only explanation for this nonsense phaenomenon seems to be that HTTPS ports are less used generally, which isn't an argument in favor of HTTPS.
  - sarciszewski 12y ago
    That has nothing to do with anything. SPDY and HTTP/2 reduce the number of TCP round trips needed to transmit information. "Nonsense phaenomenon?" Not to anyone who actually looks at how the protocols are implemented!
- striking 12y ago
  I can point you to a benchmark that disagrees. http://www.guypo.com/not-as-spdy-as-you-thought/ http://www.guypo.com/not-as-spdy-as-you-thought/ . I promise you that I've considered the spec and its implications. Where are we now?
  - venaoy 12y ago
    First comment: "This study is very flawed. Talking to a proxy by SPDY doesn't magically make the connection between that proxy and the original site use the SPDY protocol, everything was still going through HTTP at some point for the majority of these sites. Further, the exclusion of 3rd party content fails to consider how much of this would be 1st party in a think-SPDY-first architecture, where you know you'll reduce round trips, so putting this content on your own domain all together would be better, anyway." In other words the guy benchmarked SPDY _slowed down by HTTP connections behind it_!!
    - striking 12y ago
      Sure. It illustrates how any benchmark can be flawed because it's tailored to the point it's trying to make. The author of that article thought this scenario was "more realistic." What is more realistic to him is not to other people. And thus, benchmarks are unhelpful. I care about feature sets and major improvements, not minor down-to-the-wire fixes. If this were called HTTP/1.2 or something I'd be less critical, but there are so many issues and flaws left unfixed, with unhelpful bikeshedding occurring over perceived "performance".
      - taf2 12y ago
        so your only real issue is with the version number.
      - venaoy 12y ago
        > And thus, benchmarks are unhelpful. No, they are helpful! Especially real-world benchmarks. Sure you can cook up utterly flawed benchmarks (like the one you pointed to), but that doesn't mean all benchmarks are unhelpful. A good engineer knows which benchmarks matter, which don't. You don't seem to be able to do that. > If this were called HTTP/1.2 ... The mere fact you brought this up (no amount of backpedalling you may do after my comment on this) makes your criticism look even stupider. You should judge the spec based on its technical content, not based on whatever arbitrary version number was assigned to it. Talk about a bike-shed argument (http://en.wikipedia.org/wiki/Parkinson's_law_of_triviality http://en.wikipedia.org/wiki/Parkinson's_law_of_triviality)
- dlubarov 12y ago
  Not really a fair benchmark. It's making tons of requests with tiny payloads, so that most browsers will hit a connection limit and requests will be queued up. Heavily optimized pages like google.com use data urls or spritesheets for small images, and inline small css/javascript. On the bright side, reducing the need to minimize request count will make our lives as developers a bit easier :-)
  - nl 12y ago
    That's an extremely fair comparison because it shows how it is possible to avoid odd optimisations like the one you mentioned.
  - venaoy 12y ago
    Many of the sites I visit frequently are exactly like that: tons of requests with tiny payloads. The nytimes.com homepage makes 100+ requests to tiny images. Same thing for the yahoo.com homepage. An ebay.com listing page makes many requests to small thumbnails of items on sale. And so on... This makes it a perfectly fair benchmark IMHO.
    - dlubarov 12y ago
      I don't know how you're assessing those pages, but bear in mind that - Counting images can be misleading, since well-optimized sites use spritesheets or data URIs. - If you're using something like Chrome's dev console to view requests, a lot of them are non-essential requests which are intentionally made after the page is functional. - HTTP connection caps are per host. The benchmark is making hundreds of requests to one host, whereas a real page might make a dozen requests to the main server, a dozen to some CDN for static files, and a dozen to miscellaneous third parties. - The benchmark is simulating an uncached experience; with a realistic blend of cached/uncached, HTTP 1 vs 2 performance would be much more comparable. HTTP/2 is an improvement but if people expect a "5-15X" difference, they're in for a big disappointment.
- bsdetector 12y ago
  > These insane perf gains are possible only thanks to HTTP/2, specifically thanks to its support for multiplexing. What's sad about this is that if you load this site with pipelining enabled you get the same speed benefits as with HTTP/2 or SPDY, but Google would never know this, since they never tested SPDY against pipelining. > ENHANCE_YOUR_CALM (0xb): > Please read the spec and understand the technical implications before criticizing. Please understand that -- technically -- this protocol is an embarrassment to the profession and to those involved in designing it.
  - enneff 12y ago
    HTTP pipelining is busted for a variety of reasons. Support exists in most browsers but it's disabled by default because it makes things worse, on balance.
    - bsdetector 12y ago
      At the time SPDY came out, Opera and Android Browser had pipelining on by default and Firefox was about to also default it on. They didn't only because of the promise of SPDY, not because pipelining "is busted". Pipelining works fine in almost all cases. And if you only enable pipelining to known-good servers over a non-MITM SSL connection -- exactly like SPDY does -- then there is absolutely no problem with it and it performs similarly to SPDY. But I have no doubt you will continue spreading the party line from your employer, who couldn't be bothered to even test this.
      - gsnedders 12y ago
        Firefox wasn't about to default it to being on (yes, there was work being done on it to see how workable it was, but there was no decision to ship it) — it's well-known that pipelining causes all kinds of bizarre breakage with badly behaved servers and proxies (and the latter are where the implementations are especially bad). Opera had enough problems with pretty crazy-complex heuristics as to when to enable pipelining; it would've been nice for them to have been published, but that has never happened. Determining what a known-good server is over SSL isn't that easy.
kllrnohj 12y ago
> I'm not ever supporting HTTP/2. Congrats? Want a cookie or something? Do you have an actual complaint with the spec or do you just want to be an old man yelling at a cloud?
- striking 12y ago
  My "actual" complaint is that it's not enough to be a major version and that it's a system that only benefits large corporations with data to pre-push, with no other benefits. You can think differently, of course, but after looking at this (https://news.ycombinator.com/item?id=8824789 https://news.ycombinator.com/item?id=8824789) I reconsidered my previously positive view on it. (Also, I'd love a cookie)
  - exelius 12y ago
    So you'd be ok if they called it HTTP/1.2? Snark aside, it's a standardized way of allowing different architectural patterns that can benefit use cases we haven't even seen yet. Yes, those architecture patterns currently benefit large corporations, but they're not being implemented at the expense of anything else. HTTP is a remarkably complete and flexible protocol. What other benefits were you expecting to see that aren't already part of HTTP/1.1?
    - striking 12y ago
      From https://news.ycombinator.com/item?id=8825001 https://news.ycombinator.com/item?id=8825001: * no more easy debugging on the wire * another TCP like implementation inside the HTTP protocol * tons of binary data rather than text * a whole slew of features that we don't really need but that please some corporate sponsor because their feature made it in * continuing, damaging and absurd lack of DNS and IPv6 considerations * most notably the omission of any discussion of endpoint resolution Fixing anything related to DNS, DNSSEC, IPv6, or anything else would have made this closer to "HTTP/2." And as I said in another thread: yes. Calling it HTTP/1.2 would actually have made me a little happier. This isn't the next new, big thing. This is a minor improvement, if not a minor regression.
StefanKarpinski 12y ago
This attitude is exactly how you make sure that nothing ever changes or improves. It is "the perfect is the enemy of the good" exemplified. HTTP/2 is a huge improvement over HTTP in many very important ways. True, it's not perfect, but guess what? 2 is not the last version number out there. We can switch to HTTP/2 now and fix the rest of the problems with HTTP/3. Moreover, it seems like we are collectively getting better at upgrading technologies: IPv6 adoption has finally got some momentum; HTTP/2 is actually happening. With lessons learned from the HTTP => HTTP/2 transition, HTTP/3 could happen in five years instead of in another fifteen.
- striking 12y ago
  I appreciate your optimism, but do realize that there isn't really a massive improvement unless you're Google. I don't see this as worthy of the "/2" suffix; Google might like it because it allows them to make their tech standard, but other than that it's unnecessary marketing. HTTP has never been the bottleneck. I think IPv6 is excellent and a needed, massive improvement especially since IPv4 is no longer tenable. HTTP/1.1, however, still works quite well and keeps a larger feature set in some circumstances. It's less insane because it's not made by W3C or IETF or any other hugely bureaucratic group; however, that doesn't mean it's better either. I can't wait for HTTP/3! Hopefully this time they won't rush it.
  - enneff 12y ago
    Check this out https://http2.golang.org/gophertiles https://http2.golang.org/gophertiles and tell me that HTTP isn't the bottleneck, especially for high-latency connections. This is going to make the web so much faster.
  - MichaelGG 12y ago
    On some small sites I've worked on, switching to SPDY shaved about 20-30% off our load times. And all we had to do was type " SPDY" into our nginx.conf. That's like the definition of a win.
- zzzcpan 12y ago
  > This attitude is exactly how you make sure that nothing ever changes or improves. On the contrary, we are in a desperate need of such attitudes in software. We need for everyone to stop jumping to every new thing with silly promises. We need to start choosing quality over quantity. We need substantial well researched improvements.

mrb 12y ago

If that doesn't convince you to support HTTP/2, then nothing will: https://www.httpvshttps.com/ https://www.httpvshttps.com/ HTTP/1.1 is 5x-15x slower in this benchmark! These insane perf gains are possible only thanks to HTTP/2, specifically thanks to its support for multiplexing. Please read the spec and understand the technical implications before criticizing. On some unrelated note: I found this tidbit of humor in the RFC draft (https://tools.ietf.org/html/draft-ietf-httpbis-http2-16 https://tools.ietf.org/html/draft-ietf-httpbis-http2-16): ENHANCE_YOUR_CALM (0xb): The endpoint detected that its peer is exhibiting a behavior that might be generating excessive load.

fiatjaf 12y ago
The only explanation for this nonsense phaenomenon seems to be that HTTPS ports are less used generally, which isn't an argument in favor of HTTPS.
- sarciszewski 12y ago
  That has nothing to do with anything. SPDY and HTTP/2 reduce the number of TCP round trips needed to transmit information. "Nonsense phaenomenon?" Not to anyone who actually looks at how the protocols are implemented!
striking 12y ago
I can point you to a benchmark that disagrees. http://www.guypo.com/not-as-spdy-as-you-thought/ http://www.guypo.com/not-as-spdy-as-you-thought/ . I promise you that I've considered the spec and its implications. Where are we now?
- venaoy 12y ago
  First comment: "This study is very flawed. Talking to a proxy by SPDY doesn't magically make the connection between that proxy and the original site use the SPDY protocol, everything was still going through HTTP at some point for the majority of these sites. Further, the exclusion of 3rd party content fails to consider how much of this would be 1st party in a think-SPDY-first architecture, where you know you'll reduce round trips, so putting this content on your own domain all together would be better, anyway." In other words the guy benchmarked SPDY _slowed down by HTTP connections behind it_!!
  - striking 12y ago
    Sure. It illustrates how any benchmark can be flawed because it's tailored to the point it's trying to make. The author of that article thought this scenario was "more realistic." What is more realistic to him is not to other people. And thus, benchmarks are unhelpful. I care about feature sets and major improvements, not minor down-to-the-wire fixes. If this were called HTTP/1.2 or something I'd be less critical, but there are so many issues and flaws left unfixed, with unhelpful bikeshedding occurring over perceived "performance".
    - taf2 12y ago
      so your only real issue is with the version number.
    - venaoy 12y ago
      > And thus, benchmarks are unhelpful. No, they are helpful! Especially real-world benchmarks. Sure you can cook up utterly flawed benchmarks (like the one you pointed to), but that doesn't mean all benchmarks are unhelpful. A good engineer knows which benchmarks matter, which don't. You don't seem to be able to do that. > If this were called HTTP/1.2 ... The mere fact you brought this up (no amount of backpedalling you may do after my comment on this) makes your criticism look even stupider. You should judge the spec based on its technical content, not based on whatever arbitrary version number was assigned to it. Talk about a bike-shed argument (http://en.wikipedia.org/wiki/Parkinson's_law_of_triviality http://en.wikipedia.org/wiki/Parkinson's_law_of_triviality)
dlubarov 12y ago
Not really a fair benchmark. It's making tons of requests with tiny payloads, so that most browsers will hit a connection limit and requests will be queued up. Heavily optimized pages like google.com use data urls or spritesheets for small images, and inline small css/javascript. On the bright side, reducing the need to minimize request count will make our lives as developers a bit easier :-)
- nl 12y ago
  That's an extremely fair comparison because it shows how it is possible to avoid odd optimisations like the one you mentioned.
- venaoy 12y ago
  Many of the sites I visit frequently are exactly like that: tons of requests with tiny payloads. The nytimes.com homepage makes 100+ requests to tiny images. Same thing for the yahoo.com homepage. An ebay.com listing page makes many requests to small thumbnails of items on sale. And so on... This makes it a perfectly fair benchmark IMHO.
  - dlubarov 12y ago
    I don't know how you're assessing those pages, but bear in mind that - Counting images can be misleading, since well-optimized sites use spritesheets or data URIs. - If you're using something like Chrome's dev console to view requests, a lot of them are non-essential requests which are intentionally made after the page is functional. - HTTP connection caps are per host. The benchmark is making hundreds of requests to one host, whereas a real page might make a dozen requests to the main server, a dozen to some CDN for static files, and a dozen to miscellaneous third parties. - The benchmark is simulating an uncached experience; with a realistic blend of cached/uncached, HTTP 1 vs 2 performance would be much more comparable. HTTP/2 is an improvement but if people expect a "5-15X" difference, they're in for a big disappointment.
bsdetector 12y ago
> These insane perf gains are possible only thanks to HTTP/2, specifically thanks to its support for multiplexing. What's sad about this is that if you load this site with pipelining enabled you get the same speed benefits as with HTTP/2 or SPDY, but Google would never know this, since they never tested SPDY against pipelining. > ENHANCE_YOUR_CALM (0xb): > Please read the spec and understand the technical implications before criticizing. Please understand that -- technically -- this protocol is an embarrassment to the profession and to those involved in designing it.
- enneff 12y ago
  HTTP pipelining is busted for a variety of reasons. Support exists in most browsers but it's disabled by default because it makes things worse, on balance.
  - bsdetector 12y ago
    At the time SPDY came out, Opera and Android Browser had pipelining on by default and Firefox was about to also default it on. They didn't only because of the promise of SPDY, not because pipelining "is busted". Pipelining works fine in almost all cases. And if you only enable pipelining to known-good servers over a non-MITM SSL connection -- exactly like SPDY does -- then there is absolutely no problem with it and it performs similarly to SPDY. But I have no doubt you will continue spreading the party line from your employer, who couldn't be bothered to even test this.
    - gsnedders 12y ago
      Firefox wasn't about to default it to being on (yes, there was work being done on it to see how workable it was, but there was no decision to ship it) — it's well-known that pipelining causes all kinds of bizarre breakage with badly behaved servers and proxies (and the latter are where the implementations are especially bad). Opera had enough problems with pretty crazy-complex heuristics as to when to enable pipelining; it would've been nice for them to have been published, but that has never happened. Determining what a known-good server is over SSL isn't that easy.

kllrnohj 12y ago

> I'm not ever supporting HTTP/2. Congrats? Want a cookie or something? Do you have an actual complaint with the spec or do you just want to be an old man yelling at a cloud?

striking 12y ago
My "actual" complaint is that it's not enough to be a major version and that it's a system that only benefits large corporations with data to pre-push, with no other benefits. You can think differently, of course, but after looking at this (https://news.ycombinator.com/item?id=8824789 https://news.ycombinator.com/item?id=8824789) I reconsidered my previously positive view on it. (Also, I'd love a cookie)
- exelius 12y ago
  So you'd be ok if they called it HTTP/1.2? Snark aside, it's a standardized way of allowing different architectural patterns that can benefit use cases we haven't even seen yet. Yes, those architecture patterns currently benefit large corporations, but they're not being implemented at the expense of anything else. HTTP is a remarkably complete and flexible protocol. What other benefits were you expecting to see that aren't already part of HTTP/1.1?
  - striking 12y ago
    From https://news.ycombinator.com/item?id=8825001 https://news.ycombinator.com/item?id=8825001: * no more easy debugging on the wire * another TCP like implementation inside the HTTP protocol * tons of binary data rather than text * a whole slew of features that we don't really need but that please some corporate sponsor because their feature made it in * continuing, damaging and absurd lack of DNS and IPv6 considerations * most notably the omission of any discussion of endpoint resolution Fixing anything related to DNS, DNSSEC, IPv6, or anything else would have made this closer to "HTTP/2." And as I said in another thread: yes. Calling it HTTP/1.2 would actually have made me a little happier. This isn't the next new, big thing. This is a minor improvement, if not a minor regression.

StefanKarpinski 12y ago

This attitude is exactly how you make sure that nothing ever changes or improves. It is "the perfect is the enemy of the good" exemplified. HTTP/2 is a huge improvement over HTTP in many very important ways. True, it's not perfect, but guess what? 2 is not the last version number out there. We can switch to HTTP/2 now and fix the rest of the problems with HTTP/3. Moreover, it seems like we are collectively getting better at upgrading technologies: IPv6 adoption has finally got some momentum; HTTP/2 is actually happening. With lessons learned from the HTTP => HTTP/2 transition, HTTP/3 could happen in five years instead of in another fifteen.

striking 12y ago
I appreciate your optimism, but do realize that there isn't really a massive improvement unless you're Google. I don't see this as worthy of the "/2" suffix; Google might like it because it allows them to make their tech standard, but other than that it's unnecessary marketing. HTTP has never been the bottleneck. I think IPv6 is excellent and a needed, massive improvement especially since IPv4 is no longer tenable. HTTP/1.1, however, still works quite well and keeps a larger feature set in some circumstances. It's less insane because it's not made by W3C or IETF or any other hugely bureaucratic group; however, that doesn't mean it's better either. I can't wait for HTTP/3! Hopefully this time they won't rush it.
- enneff 12y ago
  Check this out https://http2.golang.org/gophertiles https://http2.golang.org/gophertiles and tell me that HTTP isn't the bottleneck, especially for high-latency connections. This is going to make the web so much faster.
- MichaelGG 12y ago
  On some small sites I've worked on, switching to SPDY shaved about 20-30% off our load times. And all we had to do was type " SPDY" into our nginx.conf. That's like the definition of a win.
zzzcpan 12y ago
> This attitude is exactly how you make sure that nothing ever changes or improves. On the contrary, we are in a desperate need of such attitudes in software. We need for everyone to stop jumping to every new thing with silly promises. We need to start choosing quality over quantity. We need substantial well researched improvements.