Biggest problem with multiplexing over TCP is mixing latency sensitive flows (like getting HTML to render) with high throughput flows (like downloading a YouTub

Biggest problem with multiplexing over TCP is mixing latency sensitive flows (like getting HTML to render) with high throughput flows (like downloading a YouTube video). You can try and diddle with chunk size and message prioritization in your application to reduce HOL blocking of low latency messages behind chunks of high throughput data, but your OS will buffer everything in one big queue anyway (because TCP is a single stream and flow control applies to that entire stream as a whole). How do you fix that? Well you can reduce socket buffer sizes on your TCP connection, and that will fix latency... but small buffer sizes mean your total throughput is limited by round trip time (because of the way the TCP receive windows and positive acknowledgment work). If you're working over a LAN, things will be fine, but over the Internet you're hosed. Of course, the solution really is to have separate long-lived TCP connections for different kinds of flows, so you can set buffer sizes appropriately... but that's impossible for your browser (which is responsible for opening connections). It has no way to know whether a GET request triggered by an <img> tag is going to yield a 100 byte response or a 100MB response.