How's the performance? My memory is that "vanilla" SOCKS is really easy to do (just run ssh with the right option and tell your application to use it) but really slow. I suspect this is mostly for cases where you don't have a normal SOCKS/ssh server, but I'm curious if it offers a benefit there too.
By vanilla, I mean `ssh -D`, as opposed to anything else that can offer a SOCKS port without actually transporting over ssh (ex. this project). Last time I compared, that was noticeably slower than wireguard, which yeah I attributed to TCP over TCP being kinda awful.
It does multiplex multiple TCP sockets over a single underlying connection though, which can cause increased latency depending on how SSH schedules sends for each individual buffer. (Too fine-grained and you waste a lot of overhead on headers and framing; too coarse and you get head-of-line blocking.)
There are also TCP fairness concerns: In a bottleneck, like a congested home Internet connection's uplink serving n total TCP connections, traffic generally splits equally across TCP flows; if you're multiplexing m SOCKS connections over one SSH connection, all those together seize only 1/n of the bottleneck capacity, i.e. each individual one gets 1/(m*n). An (UDP-based) VPN though would get 1/n of the bandwidth per tunneled TCP flow, i.e. m/n in total.
In a way, `ssh -D` is a bit like HTTP/2 that way, while this tool is more like HTTP/3 / QUIC.
Ah, well that's quite simple: I'm dumb:) Or ignorant rather. But seriously, until reading your comment it never once occurred to me that it wasn't invented by (open)ssh; I assumed one of the "S"s stood for SSH (probably "SOCKets over Ssh"). And better yet, because that made sense, it never crossed my mind to question it. So, uh, thanks:)
It would be great to compare both. Currently I connect to WireGuard and then create a socks proxy using SSH. And it works surprisingly well. But I'm very interested in this solution.
