There are a number of work and wifi proxies which won't allow out a lot of traffic, based on port. A multiplexer like this can work around such (assumed) well-intentioned but poorly implemented protections.
Wouldn't a VPN or tunnelling solution be better? You pass all your traffic through a fixed port on one host, then unwrap it and use the web as though the restriction wasn't there.
Nothing stops you from passing a VPN through a TCP connection on port 80 and 443. There are few protocols people haven't tunnelled IP over (DNS included...)
I often have to work behind "smoothwall". AFAIK, it only allows HTTP over port 80 and HTTPS on port 443 - any other protocol on any other port gets blocked, including other protocols over port 80/443.
To bypass this, I wrote a simple ruby script to tunnel TCP connections, while adding fake HTTP headers to get through the firewall.
Generally these well-intentioned networks block the usual VPN and tunneling solutions (think kid and a school network with a firewall that only allows FTP, HTTP, and HTTPS).
At which point you simply use these ports for your VPN.
OpenVPN can use TCP, it can use UDP, it can use whatever port you like, it can even use a fixed key to turn all traffic into random noise (obfuscating protocol structures).
SSH with SOCKS5 tunnelling enabled does exactly this. The trick is that VPN's aren't allowed very often, so that's where the TLS tunnel trick steps in. You can use a VPN over TLS with serve2d if you want. I just find ssh -D5000 easier to set up quickly "in the field" than a VPN, especially seeing that it doesn't require server configuration.
It's not a bad idea, though I'm not sure why someone would want to do this on their own in a bolt-on manner. For an example of a place where demux is encouraged, see RFC 6335:
Conservation of the port number space is required because this space is a limited resource, so applications are expected to participate in the traffic demultiplexing process where feasible. The port numbers are expected to encode as little information as possible that will still enable an application to perform further demultiplexing by itself.
[...]
IANA strives to assign only one assigned port number per service or application.
Why do I know this? Consul by default uses 5-6 ports, and one of them conflicts with an IETF registered port in-use by our data center provider. Was hoping that the RFCs gave some ammo for a resolution in my favor, came out more humble and wondering if Consul really needed that many ports.
Modern apps seems to do their best to require lots of ports numbers, often with very little justification. It's incredibly annoying.
Some of it understandable, e.g. when one port is for stuff that is always meant to stay behind your firewall, and another for public access. In that case it actually makes things easier to do properly. But so often it appears to be entirely gratuitous.
> Why? The entire point of ports is so you don't have to do this.
There are use cases - many nefarious cases but some real world cases.
Let's say your university allows everything through 80 but blocks everything else. You could SSH home or stream content.
Another use case could be that you have a web site and game server on same server. An interesting implementation could be to listen on port 80 so that they could connect to yourserver.com via HTTP and view information about the game/server and connect on the same port. Interesting but not very practical.
I suppose an acceptable/respectable use case would be custom load balancers or honey pots.
Well, back in highschool I used to use a similar idea to run SSH to my home PC via port 80 -- the network restrictions meant a VPN wouldn't work, and it was the only way to get access to run compilers I wanted to play with without relying on exploits to get around the system's restrictions.