2 ms·
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 comp
by yjftsjthsd-h 3y ago
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.
- lxgr 3y ago`ssh -D` isn't TCP over TCP, though! 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.
- rahimnathwani 3y agoI'm curious why you refer to 'ssh -D' as 'vanilla SOCKS'? SOCKS existed before SSH did, and there are SOCKS server implementations that don't rely on SSH.
- yjftsjthsd-h 3y agoAh, 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:)