14 ms·

Multiplexing on top of TCP (2011)

88 points by riobard 10y ago

frederikvs 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."
- 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.
zimbatm 10y ago
That's one of the issues HTTP/2 has. Because all the requests and responses are now multiplexed over a single TCP connection, losing a single packet is going to block everything. This makes HTTP/2 actually work on unreliable networks. This problem is also known as Head-Of-Line (HOL) blocking. Google is aware of that issue, that's why they explored SCTP first and now QUIC as alternate layer 3 protocols to replace TCP in the future.
- riobard 10y ago
  SCTP is problematic because middle boxes need to be made aware of it since it uses a different IP protocol. This is gonna require massive infrastructure changes and probably won't fly (like IPv6). QUIC, which runs over UDP, is easier to adopt. However, in reality many ISPs and company networks de-prioritize UDP traffic so the quality of connection is unpredictable. TCP is still the safest bet. We need to figure out a better (and magical!) way somehow...
  - AndrewDucker 10y ago
    IPv6 is over 10% of Google's traffic, and is doubling year-on-year. If SCTP was failing to fly that badly it would make me very happy!
    - daenney 10y ago
      But its taken us 20 years to get to this point and even with the IPv4 exhaustion it's still relatively slow to be picked up on by providers in Europe or North America (except for mobile, now). Not to say I wouldn't want SCTP to succeed but IPv6 doesn't exactly spring to mind as a model for the successful adoption of a new internet protocol.
  - panic 10y ago
    SCTP is problematic because middle boxes need to be made aware of it since it uses a different IP protocol. Is this true? As far as I can tell SCTP works over plain IP, just like UDP and TCP do.
zaxomi 10y ago
Does this solve something that ssh-tunneling can't do? By the way, maybe it should say in the title that the post is from 2011?
caseymarquis 10y ago
I think it really depends on the use case. My current work project is multiplexing on one port with a separate port for critical control commands. It seems like a good design, but maybe I'll make another writeup like this in a year when I realize it was a terrible decision.
known 10y ago
TCPTuner: congestion control utility https://tuxdiary.com/2016/05/14/tcptuner/ https://tuxdiary.com/2016/05/14/tcptuner/

88 points by riobard 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."

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.

zimbatm 10y ago

That's one of the issues HTTP/2 has. Because all the requests and responses are now multiplexed over a single TCP connection, losing a single packet is going to block everything. This makes HTTP/2 actually work on unreliable networks. This problem is also known as Head-Of-Line (HOL) blocking. Google is aware of that issue, that's why they explored SCTP first and now QUIC as alternate layer 3 protocols to replace TCP in the future.

riobard 10y ago
SCTP is problematic because middle boxes need to be made aware of it since it uses a different IP protocol. This is gonna require massive infrastructure changes and probably won't fly (like IPv6). QUIC, which runs over UDP, is easier to adopt. However, in reality many ISPs and company networks de-prioritize UDP traffic so the quality of connection is unpredictable. TCP is still the safest bet. We need to figure out a better (and magical!) way somehow...
- AndrewDucker 10y ago
  IPv6 is over 10% of Google's traffic, and is doubling year-on-year. If SCTP was failing to fly that badly it would make me very happy!
  - daenney 10y ago
    But its taken us 20 years to get to this point and even with the IPv4 exhaustion it's still relatively slow to be picked up on by providers in Europe or North America (except for mobile, now). Not to say I wouldn't want SCTP to succeed but IPv6 doesn't exactly spring to mind as a model for the successful adoption of a new internet protocol.
- panic 10y ago
  SCTP is problematic because middle boxes need to be made aware of it since it uses a different IP protocol. Is this true? As far as I can tell SCTP works over plain IP, just like UDP and TCP do.

zaxomi 10y ago

Does this solve something that ssh-tunneling can't do? By the way, maybe it should say in the title that the post is from 2011?

caseymarquis 10y ago

I think it really depends on the use case. My current work project is multiplexing on one port with a separate port for critical control commands. It seems like a good design, but maybe I'll make another writeup like this in a year when I realize it was a terrible decision.

known 10y ago

TCPTuner: congestion control utility https://tuxdiary.com/2016/05/14/tcptuner/ https://tuxdiary.com/2016/05/14/tcptuner/