Question Qu'est-ce qui est plus efficace / plus rapide, la compression rsync ou la compression ssh?


Je actuellement rsync fichiers: (i) localement et (ii) à distance via WAN (connexion vers 8 Mbps vers le bas / 1,5 Mbps vers le haut).

J'envisage d'ajouter à rsync:

-z

pour compresser des fichiers.

Ou alternativement en ajoutant à ssh:

-C

Lequel est le meilleur et en fait, y a-t-il de gros avantages?


3
2017-09-30 19:23


origine




Réponses:


Basé sur la Manuel rsync, il est préférable de compresser avec rsync -z

Notez que cette option réalise généralement meilleurs taux de compression que ceux pouvant être obtenus en utilisant un shell distant de compression ou un transport de compression car il tire parti des informations implicites contenues dans les blocs de données correspondants qui ne sont pas explicitement envoyés via la connexion.


9
2017-09-30 19:43



Je vous remercie. Si je compresse dans rsync, dois-je désactiver la compression ssh, alors "-o Compression = no"? Ou puis-je laisser ssh tel quel? - Guest
Oui, désactivez la compression ssh. Les données sont déjà compressées, pas besoin d'essayer de les compresser à nouveau. - Darren


Dans la plupart des cas, rsync -z la compression conviendra à vos besoins. Cependant, le rsync -z la compression ne compresse pas les métadonnées échangées avant la copie du fichier (notamment la liste des fichiers). Afin de compresser également la liste des fichiers, je recommanderais également d'utiliser le ssh -C option. Surtout quand vous avez les deux:

  • un grand nombre de fichiers à transférer
  • peu de changements entre vos fichiers source et destination

2
2018-06-21 09:32





Vous semblez confondre la compression avec le cryptage. SSH ne compresse pas par défaut. Pas besoin de l'éteindre car il n'est pas utilisé par défaut. Vous pouvez utiliser la compression de rsync pour réduire la quantité de données envoyées via SSH, mais la vitesse de SSH est beaucoup plus impactée par le cryptage de tout ce qui la traverse que par la sauvegarde de l'application. 15% en compressant les données source. Si vous modifiez ce que SSH utilise pour le chiffrement, utilisez un chiffrement plus faible (par exemple, arcfour), ou si vous le patchez pour désactiver complètement le chiffrement (shell INsecure), SSH terminera le transfert beaucoup plus rapidement.


-2
2018-04-02 17:12



- En ce qui concerne Compression SSH : Beaucoup de gens (et je veux dire beaucoup) ont tendance à mettre Comprssion yes dans leurs .ssh / config des fichiers pour améliorer le débit de données sur des liaisons plus lentes (lors de la redirection via DSL ou 3 / 4G, etc.) -oCompression=no est nécessaire dans ces configurations. - En ce qui concerne cryptage : Blowfish est un autre possible (utiliser: -c blowfish-cbc). C'est théoriquement plus faible que AES256. Mais contrairement à RC4, il n’a toujours pas connu de faiblesse cryptanalytique (bien qu’aujourd’hui, personne ne le regarde activement) et il est beaucoup plus rapide sur les architectures ne disposant pas d’une accélération matérielle AES256. - DrYak