![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
I'm pleased to announce the first release of qcp.
The QUIC Copier (qcp) is an experimental high-performance remote file copy utility for long-distance internet connections with the following features:
- 🔧 Drop-in replacement for
scp - 🛡️ Similar security to
scp, using existing, well-known mechanisms - 🚀 Better throughput on congested networks
qcp exists because I needed to copy multiple large (3+ GB) files from a server in Europe to my home in New Zealand.
I’ve got nothing against ssh or scp. They’re brilliant. I’ve been using them since the 1990s. However they run on top of TCP, which does not perform very well when the network is congested. With a fast fibre internet connection, a long round-trip time and noticeable packet loss, I was right in the sour spot. TCP did its thing and slowed down, but when the congestion cleared it was very slow to get back up to speed.
If you're interested you can find qcp here:
(no subject)
Very cool! Do you mind if I share links? This announcement isn’t a public post so I thought I should ask.
I was recently reminded of the very old hpn-ssh patches which increased the ssh buffer sizes to cope with long fat pipes (i.e. gigabit across north america, iirc) but they didn’t do anything to mitigate congestion or packet loss.
(no subject)
(no subject)
Thanks! It looks very polished, I must say :-)
(no subject)
(no subject)
> Both sides generate a TLS key and exchange self-signed certs over the ssh pipe between them
> We use those certs to set up a QUIC session between the two
Is there a reason for the heavyweight handoff to QUIC? (i.e. as opposed to using the SSH session to provide shared keying material directly to both endpoints.)
(no subject)
Seriously, I was cobbling stuff together to improve my life. I've already had a useful couple of suggestions from randoms I don't know; I am half expecting to overhaul things pretty thoroughly in time.
QUIC implies TLS (unless I've missed something). Do you mean TLS-PSK or something else? Unfortunately, it seems that rustls doesn't support TLS-PSK at present. I'm not readily sure how quinn (the Rust QUIC implementation) would deal with it either.
(no subject)