←back to thread

SSH3: Faster and rich secure shell using HTTP/3

(github.com)
532 points tempaccount420 | 1 comments | 27 Sep 25 14:27 UTC | HN request time: 0s | source
Show context
Zambyte ◴[27 Sep 25 15:01 UTC] 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 ◴[27 Sep 25 15:35 UTC] 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 ◴[27 Sep 25 16:09 UTC] 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. lxgr ◴[28 Sep 25 07:44 UTC] No.45402500[source]▶
You're mixing application layer multiplexing and transport layer multiplexing.

If you use the former without the latter, you'll inevitably have head-of-line blocking issues if your connection is bandwidth or receiver limited.

Of course not every SSH user uses protocol multiplexing, many do, as it can avoid repeated and relatively expensive (terms of CPU, performance, and logging volume) handshakes.