5 ms·

I'm glad to see they came to the sensible conclusion : "Multiplexing on top of TCP in overall fails to deliver the advantages it is assumed to provide."

joosters 10y ago
But to reach that conclusion they had to make assumptions, and yet their conclusion has washed away these assumptions so as to state a solid fact. Not very trustworthy IMO.
Aaargh20318 10y ago
It depends entirely on the use-case of course. Back in the J2ME days we multiplexed multiple connections over a single TCP stream because certain shitty phones coughnokiacough would pop up a permission dialog for every. single. connection. On startup our app would need to connect to several services and the user would be spammed with permission dialogs. Multiplexing the TCP streams solved that issue.
- eeeeeeeeeeeee 10y ago
  Do you have any other use cases? That is a pretty specific one that I don't think most people are likely to run into.
josteink 10y ago
> I'm glad to see they came to the sensible conclusion : "Multiplexing on top of TCP in overall fails to deliver the advantages it is assumed to provide." So basically the only thing the HTTP/2 crowd could come up with as a real advantage over HTTP/1.1 (discounting ofcourse that HTTP/1.1 supports pipelining), which is a massive source of complexity, which will also be a massive source of bugs, does not provide the benefits it claimed it would. Can we just call off HTTP/2 yet? It was pushed by Google to cover their needs and agenda, without any respect for the protocol's history. It had a bunch of riders introduced with misleading language with regard to privacy violating semantic changes (For instance HTTP/2 cannot do regular HTTP, only HTTPS. You can no longer deploy private apps on your LAN without registering with centralized internet registries such as DNS and CAs. Etc etc). Basically HTTP/2 was Google's attempt at making it easier for them to keep their huge amount of tracking cookies on every single HTTP(S) request across the internet, without it causing too much of an impact on users. You know what? If I have 200KBs of Google-cookies tracking me, I want those cookies to impact performance. I want to know something is up. Can't we just say "HTTP/2 considered harmful" at this point? I'll be disabling it in all my browsers which support proper user-managed configuration. Needless to say, that excludes Chrome.
- tinco 10y ago
  So.. first you jump to the conclusion that because this guy asserts TCP multiplexing is not favorable for his use case, you decide that all TCP multiplexing is useless and does not perform so HTTP/2 must be worthless. Then you complain that you can't use HTTP/2 for some potentially useful cases. Then you proceed to accuse Google of pushing HTTP/2 for improving the performance of their websites, effectively conceding that HTTP/2 does improve performance of multi-resource webpages. Then you argue that it's actually a good thing when a multi-resource webpage is slow.
- MichaelGG 10y ago
  I don't think so. On the sites I worked on, adding SPDY gave a nice double-digit& load time benefit. HTTP/2 does not require HTTPS. But all browsers decided this was a good thing, so browser require HTTP to enable HTTP/2. And you do not need to get a centralized CA to give you certs; just use your own. HTTP/2 makes parsing way faster, which can save significant resources. It'll also cut down an ambiguity which might prevent some security issues.
- roblabla 10y ago
  What on earth is this comment even about. First of all, HTTP/2 has a lot of advantage over HTTP/1.1, like server push. Saying it doesn't provide the benefits it claimed is wrong. It uses a single TCP connection, which for websites that require a lot of them (hint: lots of people nowadays do. You've got the webapp trend to thank for that) actually IMPROVES things. TCP overhead is not negligeable. And then there's the header compression algorithm that's included in HTTP2 that further helps getting size down. HTTPS-only is NOT a protocol limitation. It was pushed by BOTH Google AND Mozilla, in the name of security, like all the new features coming to the web (need webrtc ? Https. Want the camera ? https. Want https ? https). I'm not actually too sure I like that trend either, it feels like shoving candies down my throat. I like candies. But not like that. However, saying this is a Big Google Conspiracy is ridiculous. I mean what the hell does cookie have to do with anything. PS: On a separate note, could we get 10.0.0.X, 192.168.X.X, 127.0.0.1 and the file:// protocol counted as "Secure" please ? It's a pain to have to create a self-signed certs just to develop stuff.
  - 10y ago
ambrop7 10y ago
I don't disagree with the conclusion but from my understanding it was made entirely on a theoretical basis. I would be interested in seeing an implementation of multiplexing benchmarked against separate connections. There are also (low-traffic) use cases where overrun of receivers is unexpected so you don't need an application-level ACK mechanism, just notification of overrun so you can handle it, e.g. by breaking up and restarting the application associated with the overflowing stream.

joosters 10y ago

But to reach that conclusion they had to make assumptions, and yet their conclusion has washed away these assumptions so as to state a solid fact. Not very trustworthy IMO.

Aaargh20318 10y ago

It depends entirely on the use-case of course. Back in the J2ME days we multiplexed multiple connections over a single TCP stream because certain shitty phones coughnokiacough would pop up a permission dialog for every. single. connection. On startup our app would need to connect to several services and the user would be spammed with permission dialogs. Multiplexing the TCP streams solved that issue.

eeeeeeeeeeeee 10y ago
Do you have any other use cases? That is a pretty specific one that I don't think most people are likely to run into.

josteink 10y ago

> I'm glad to see they came to the sensible conclusion : "Multiplexing on top of TCP in overall fails to deliver the advantages it is assumed to provide." So basically the only thing the HTTP/2 crowd could come up with as a real advantage over HTTP/1.1 (discounting ofcourse that HTTP/1.1 supports pipelining), which is a massive source of complexity, which will also be a massive source of bugs, does not provide the benefits it claimed it would. Can we just call off HTTP/2 yet? It was pushed by Google to cover their needs and agenda, without any respect for the protocol's history. It had a bunch of riders introduced with misleading language with regard to privacy violating semantic changes (For instance HTTP/2 cannot do regular HTTP, only HTTPS. You can no longer deploy private apps on your LAN without registering with centralized internet registries such as DNS and CAs. Etc etc). Basically HTTP/2 was Google's attempt at making it easier for them to keep their huge amount of tracking cookies on every single HTTP(S) request across the internet, without it causing too much of an impact on users. You know what? If I have 200KBs of Google-cookies tracking me, I want those cookies to impact performance. I want to know something is up. Can't we just say "HTTP/2 considered harmful" at this point? I'll be disabling it in all my browsers which support proper user-managed configuration. Needless to say, that excludes Chrome.

tinco 10y ago
So.. first you jump to the conclusion that because this guy asserts TCP multiplexing is not favorable for his use case, you decide that all TCP multiplexing is useless and does not perform so HTTP/2 must be worthless. Then you complain that you can't use HTTP/2 for some potentially useful cases. Then you proceed to accuse Google of pushing HTTP/2 for improving the performance of their websites, effectively conceding that HTTP/2 does improve performance of multi-resource webpages. Then you argue that it's actually a good thing when a multi-resource webpage is slow.
MichaelGG 10y ago
I don't think so. On the sites I worked on, adding SPDY gave a nice double-digit& load time benefit. HTTP/2 does not require HTTPS. But all browsers decided this was a good thing, so browser require HTTP to enable HTTP/2. And you do not need to get a centralized CA to give you certs; just use your own. HTTP/2 makes parsing way faster, which can save significant resources. It'll also cut down an ambiguity which might prevent some security issues.
roblabla 10y ago
What on earth is this comment even about. First of all, HTTP/2 has a lot of advantage over HTTP/1.1, like server push. Saying it doesn't provide the benefits it claimed is wrong. It uses a single TCP connection, which for websites that require a lot of them (hint: lots of people nowadays do. You've got the webapp trend to thank for that) actually IMPROVES things. TCP overhead is not negligeable. And then there's the header compression algorithm that's included in HTTP2 that further helps getting size down. HTTPS-only is NOT a protocol limitation. It was pushed by BOTH Google AND Mozilla, in the name of security, like all the new features coming to the web (need webrtc ? Https. Want the camera ? https. Want https ? https). I'm not actually too sure I like that trend either, it feels like shoving candies down my throat. I like candies. But not like that. However, saying this is a Big Google Conspiracy is ridiculous. I mean what the hell does cookie have to do with anything. PS: On a separate note, could we get 10.0.0.X, 192.168.X.X, 127.0.0.1 and the file:// protocol counted as "Secure" please ? It's a pain to have to create a self-signed certs just to develop stuff.
- 10y ago

ambrop7 10y ago

I don't disagree with the conclusion but from my understanding it was made entirely on a theoretical basis. I would be interested in seeing an implementation of multiplexing benchmarked against separate connections. There are also (low-traffic) use cases where overrun of receivers is unexpected so you don't need an application-level ACK mechanism, just notification of overrun so you can handle it, e.g. by breaking up and restarting the application associated with the overflowing stream.