About rsync over SSH and compression

Stuart Henderson stu at spacehopper.org
Wed Jun 26 02:47:22 AEST 2019

On 2019/06/25 10:03, JCA wrote:
> Rsync supports the capability of compressing data before sending. So does
> OpenSSH. It would be probably be a waste of resources and time to enable
> both compression capabilities at the same time, but it is not clear to me
> whether, in general, it makes better sense to enable rsync compression or
> SSH compression.
> My first thought would be that SSH compression might yield better results,
> on the ground that SSH will try to cram as much data as possible in a
> channel data message, within the limitations imposed by the maximum SSH
> message size and the current window size. On the other hand, rsync might
> (and 'might' is the keyword here) resort to individual
> SSH2_MSG_CHANNEL_DATA messages for particular deltas, thus giving the
> compression code smaller amounts of data to play with every time.
> Additionally, SSH compression will be able to compress the rsync protocol
> control data, which rsync will not be able to compress (right?)
> Feedback on the issues above will be much appreciated.

If you're updating changed files, then rsync has more information
available about them available than ssh possibly can (see the rsync
manual about --compress).

If you want to save bandwidth over all else then you probably want to
test for yourself with your usual set of files and typical changes, but
in that case it might be worth using both to get control data as well
(especially if you have large numbers of files).

More information about the openssh-unix-dev mailing list