←back to thread

532 points tempaccount420 | 1 comments | | HN request time: 0s | source
Show context
Zambyte ◴[] No.45396281[source]
I was skeptical of the claim that it's faster than traditional SSH, but the README specifies that it is faster at establishing a connection, and that active connections are the same speed. That makes a lot of sense and seems like a reasonable claim to make.
replies(9): >>45396495 #>>45396529 #>>45396639 #>>45396881 #>>45400344 #>>45400909 #>>45400915 #>>45403285 #>>45410927 #
notepad0x90 ◴[] No.45396639[source]
Although, dollars-to-donuts my bet is that this tool/protocol is much faster than SSH over high-latency links, simply by virtue of using UDP. Not waiting for ack's before sending more data might be a significant boost for things like scp'ing large files from part of the world to the another.
replies(6): >>45396713 #>>45396823 #>>45397014 #>>45397091 #>>45397195 #>>45402450 #
nh2 ◴[] No.45397014[source]
SSH has low throughput on high latency links, but not because it uses TCP. It is because SSH hardcodes a too-small maximum window size in its protocol, in addition to the one of TCP.

This SSH window size limit is per ssh "stream", so it could be overcome by many parallel streams, but most programs do not make use of that (scp, rsync, piping data through the ssh command), so they are much slower than plain TCP as measured eg by iperf3.

I think it's silly that this exists. They should just let TCP handle this.

replies(4): >>45397148 #>>45397220 #>>45401266 #>>45402500 #
1. fanf2 ◴[] No.45397148[source]
Yeah, the longstanding hpn-ssh fork started off by adjusting ssh’s window sizes for long fat pipes.

https://github.com/rapier1/hpn-ssh