sshuttle slower than socks?

726 views
Skip to first unread message

guyrut...@gmail.com

unread,
Oct 15, 2018, 3:44:04 AM10/15/18
to sshuttle
I benchmarked my connection speed when routing traffic through an SSH SOCKS proxy and when using sshuttle (both to the same server). Suprisingly (at least for me) sshuttle was considerably slower (about 8 times slower on the download channel, 1.5 slower on upload)

Is this normal behavior?

Speed tests were done using speedtest.net which uses tcp connections.
I've tried with and without --no-latency-control and it didn't change much.
I'm running Debian Stretch.

Brian May

unread,
Oct 16, 2018, 12:18:36 AM10/16/18
to guyrut...@gmail.com, sshuttle
There are known performance issues.

https://github.com/sshuttle/sshuttle/issues/272

We need some performance/profiling data to try to find where the worst
bottlenecks are. This way we can determine if it is feasible or not to
fix the problem areas.

It is possible that Python code just cannot keep up with the bandwidth
required. It is also possible that the code is doing something stupid
which is slowing it down. Without any evidence, it isn't possible to
tell.

Unfortunately, I don't have time to do any of this myself.
--
Brian May <br...@linuxpenguins.xyz>
https://linuxpenguins.xyz/brian/

Avery Pennarun

unread,
Oct 16, 2018, 9:40:07 PM10/16/18
to br...@linuxpenguins.xyz, guyrut...@gmail.com, sshuttle mailing list
On Tue, Oct 16, 2018 at 12:18 AM Brian May <br...@linuxpenguins.xyz> wrote:
> guyrut...@gmail.com writes:
> > I benchmarked my connection speed when routing traffic through an SSH SOCKS
> > proxy and when using sshuttle (both to the same server). Suprisingly (at
> > least for me) sshuttle was considerably slower (about 8 times slower on the
> > download channel, 1.5 slower on upload)
> >
> > Is this normal behavior?
> >
> > Speed tests were done using speedtest.net which uses tcp connections.
> > I've tried with and without --no-latency-control and it didn't change much.
> > I'm running Debian Stretch.
>
> There are known performance issues.

Likely true. sshuttle has never really been tuned for speed; most
people use it primarily as an ssh bouncer or a gateway to look at
status web pages inside their corporate network or datacenter, so
throughput has never been a high priority.

> It is possible that Python code just cannot keep up with the bandwidth
> required. It is also possible that the code is doing something stupid
> which is slowing it down. Without any evidence, it isn't possible to
> tell.

It's quite possible (in fact very likely :)) that the code itself
should be more efficient, but I have no doubt that python can keep up
with pretty high throughput given the way sshuttle is designed. If we
had to look at each packet separately (like most VPNs would do), it
might be game over at very high speed. But sshuttle lets the kernel
redirect streams at the TCP level, which means the python code can
read and write very large blocks with just a few lines of code. The
more it falls behind, the bigger the blocks will get, so it should be
self correcting.

All this relies on the code not doing blatantly inefficient things per
block, and scaling up to larger block sizes when needed. It probably
needs more tuning.

Using --no-latency-control is definitely mandatory. The
latency-control feature is rather blunt (enabled by default because as
I mentioned above, most people use sshuttle for interactive
connections rather than big transfers) and will do very bad things to
high throughput connections.

Have fun,

Avery
Reply all
Reply to author
Forward
0 new messages