3 ms·

So basically HTTP/2.0 performs on par with HTTP/1.1 with pipelining, but has a complexity which is a million times higher, and everyone working on it experience

So basically HTTP/2.0 performs on par with HTTP/1.1 with pipelining, but has a complexity which is a million times higher, and everyone working on it experiences bugs and incompatibilities. How about we just ditch HTTP/2.0 (aka the Google forced it upon us protocol) and get back to something which is proven, IETF/W3C-based, is not binary, is simple and most importantly: actually works? That'd be real nice. Also let's not let Google create more internet protocols please. That'd also be nice.

pfg 11y ago
> So basically HTTP/2.0 performs on par with HTTP/1.1 with pipelining, but has a complexity which is a million times higher, and everyone working on it experiences bugs and incompatibilities. Can you quote the section of the article where it says that? Because the only reference to HTTP/1.1 I found says: > HTTP/2 [...] provides several performance optimizations compared to HTTP/1.1. These optimizations include more efficient header compression, server push, stream multiplexing over the same connection, etc.
madeofpalk 11y ago
> is not binary Why is this a downside (apart from 'I can't telnet now')?
- josteink 11y ago
  All major internet protocols to date has been plain text, which for almost anyone has been easy to learn, easy to inspect and diagnose without specialised tools and easy to extend without creating compatibility concerns because of it. We've already seen SPDY be incompatible between its few versions. Binary ruins that fine tradition for the promise of 0.1% better performance. And I think that's a terrible trade.
  - X-Cubed 11y ago
    TLS is binary
    - zimpenfish 11y ago
      But you can access the inner protocol by using `openssl s_client -connect host:port` as a TLS/SSL wrapper, can't you? (Edit: I realise you can likely also access/debug HTTP/2.0 streams with a CLI tool - I am currently ambivalent about text vs binary streams.)
      - Matthias247 11y ago
        Yes, you can also access/debug HTTP/2 content with curl or nghttp2. And the content of the request/response body streams is binary (in the sense that there is no predefined encoding) - just like in HTTP/1.1. That there is also a binary framing layer underneath should not care you from CLI user or application builders perspective. Just like you don't care in what number of IP frames your request was transmitted.
    - Matthias247 11y ago
      as are Ethernet, IP, TCP, and everything else on the lower layers. I would say even say most networking protocols are binary. Some very high level protocols are not, but in my opinion working with binary ones in applications and libraries is much easier (no need to read an arbitrary amount of bytes and loop through all of them just to find a termination sequence, etc.)
    - profmonocle 11y ago
      As are DNS, NTP, SSH, and DHCP. That's just off the top of my head.
secure 11y ago
Any new technology is bound to have such teething problems. I’m curious how HTTP/2.0 and HTTP/1.1 compare in a few years from now.
manigandham 11y ago
HTTP/2 outperforms HTTP/1 at everything. If pipelining was so easy then it would've actually taken off (which it never did) and it doesn't come close to all the features of HTTP/2 that make it far better for the different types of content, networks and devices used today. It's even the backbone for the new Google RPC framework: gRPC allowing for microsecond latencies. It's time to move on to better tech. Reading your other comments, it seems you have some anti-Google political stance rather than a technical basis for this.

pfg 11y ago

> So basically HTTP/2.0 performs on par with HTTP/1.1 with pipelining, but has a complexity which is a million times higher, and everyone working on it experiences bugs and incompatibilities. Can you quote the section of the article where it says that? Because the only reference to HTTP/1.1 I found says: > HTTP/2 [...] provides several performance optimizations compared to HTTP/1.1. These optimizations include more efficient header compression, server push, stream multiplexing over the same connection, etc.

madeofpalk 11y ago

> is not binary Why is this a downside (apart from 'I can't telnet now')?

josteink 11y ago
All major internet protocols to date has been plain text, which for almost anyone has been easy to learn, easy to inspect and diagnose without specialised tools and easy to extend without creating compatibility concerns because of it. We've already seen SPDY be incompatible between its few versions. Binary ruins that fine tradition for the promise of 0.1% better performance. And I think that's a terrible trade.
- X-Cubed 11y ago
  TLS is binary
  - zimpenfish 11y ago
    But you can access the inner protocol by using `openssl s_client -connect host:port` as a TLS/SSL wrapper, can't you? (Edit: I realise you can likely also access/debug HTTP/2.0 streams with a CLI tool - I am currently ambivalent about text vs binary streams.)
    - Matthias247 11y ago
      Yes, you can also access/debug HTTP/2 content with curl or nghttp2. And the content of the request/response body streams is binary (in the sense that there is no predefined encoding) - just like in HTTP/1.1. That there is also a binary framing layer underneath should not care you from CLI user or application builders perspective. Just like you don't care in what number of IP frames your request was transmitted.
  - Matthias247 11y ago
    as are Ethernet, IP, TCP, and everything else on the lower layers. I would say even say most networking protocols are binary. Some very high level protocols are not, but in my opinion working with binary ones in applications and libraries is much easier (no need to read an arbitrary amount of bytes and loop through all of them just to find a termination sequence, etc.)
  - profmonocle 11y ago
    As are DNS, NTP, SSH, and DHCP. That's just off the top of my head.

secure 11y ago

Any new technology is bound to have such teething problems. I’m curious how HTTP/2.0 and HTTP/1.1 compare in a few years from now.

manigandham 11y ago

HTTP/2 outperforms HTTP/1 at everything. If pipelining was so easy then it would've actually taken off (which it never did) and it doesn't come close to all the features of HTTP/2 that make it far better for the different types of content, networks and devices used today. It's even the backbone for the new Google RPC framework: gRPC allowing for microsecond latencies. It's time to move on to better tech. Reading your other comments, it seems you have some anti-Google political stance rather than a technical basis for this.