Que fait exactement le drapeau `-C` dans` scp`?

J'utilise toujours soit rsyncou scppour copier le fichier de / vers une machine distante. Récemment, j'ai découvert dans le manuel de scp( man scp) le drapeau-C

 -C      Compression enable.  Passes the -C flag to
         ssh(1) to enable compression.

Avant de découvrir ce drapeau, je le faisais zipavant et après scp.

Est-il aussi efficace d’utiliser simplement la -Ccompression et le décompression? Quand utiliser un procédé ou un autre pour accélérer le transfert?

scp compression file-transfer Remi.b
la source

La meilleure façon, à mon avis, est une référence par vous-même. Utilisation scp -rvet scp -Crvcomparaison du débit.

jeudi

Ceci est totalement hors de propos pour la question, mais zipest un format de fichier très "windows" -ish. Vous ne le verrez presque jamais ou n’en aurez pas besoin lorsque vous utiliserez une machine Linux avec un logiciel Linux natif. tarest utilisé pour enrouler des répertoires dans un fichier tout en conservant les autorisations et les noms et autres, alors que gzip, bzip2, xz, etc sont utilisés pour Compresser des fichiers. tars sont souvent compressés, créant tar.gzainsi tar.xzdes formats communs pour les archives sur Linux. J'ai vu des gens lancer leur propre scpworkalike avec des commandes comme tar cvz directory | ssh machine 'cd somewhere; tar xz'.

Score_Under

@Score_Under - Le format zip est également utilisé par Java pour conditionner les fichiers .jar. Le zip est donc encore largement utilisé sur de nombreux serveurs Linux.

Johnny

Au lieu d'utiliser l'option à chaque transfert de fichier, vous pouvez mettre Compression yesvotre .ssh/configfichier.

Barmar

Si vous voulez vraiment de la vitesse, vous pouvez peut-être éviter SSH: unix.stackexchange.com/questions/227951/…

rogerdpack

Réponses:

Cela ne fera jamais vraiment une grosse différence, mais compresser le fichier avant de le copier devrait être un peu moins efficace, car l'utilisation d'un format de conteneur tel que zipcelui-ci peut encapsuler plusieurs fichiers (comme tar) n'est pas nécessaire et il n'est pas possible de lire en continu entrée et sortie (vous avez donc besoin d’un fichier temporaire).

Utiliser gzipen revanche, au lieu de zipdevrait être exactement le même puisque c’est ce qui se ssh -Cfait sous le capot ... sauf que gzipper est plus de travail que de simplement utiliser ssh -C.

Celada
la source

Ok, je vais vérifier ce qui gzipest. Votre réponse signifie-t-elle que scp -rCc'est probablement la solution la plus efficace que j'ai?

Remi.b

Votre réponse ne considère pas que -Ccompresse un flux de protocole interactif. Vous ne considérez que les données. Donc, vos conclusions sont fausses. Voir ma réponse

Martin Prikryl

@ Celada Zip peut écrire dans un pipeline puisque le répertoire des membres est placé à la fin. Cependant, comme vous l'avez dit, la décompression nécessite de rechercher plusieurs membres et ne peut donc pas lire à partir d'un pipeline.

jrw32982 prend en charge Monica le

L' -Cindicateur permet la compression gzip d'un flux SSH.

C'est un équivalent de Accept-Encoding: gzipHTTP.

Le comportement de l'indicateur dépend du type de données que vous transférez:

Lors du transfert d'un seul fichier volumineux, les performances seraient pratiquement identiques à celles du fichier compressé avant le transfert (efficacité négligée de l'algorithme zip par rapport à l'algorithme gzip).

Mais utiliser -Cest un effort moindre pour vous en tant qu'utilisateur.
Lors du transfert de nombreux petits fichiers, les performances seront inférieures à la compression des fichiers avant le transfert.

Cela s'explique par le fait qu'avant chaque transfert de fichier, il existe une communication interactive entre le serveur SCP et le client (pour l'échange de métadonnées de fichier, telles que l'horodatage et les autorisations). Les deux parties doivent donc attendre un peu pour que l'autre partie réponde (la compression ne résoudra pas le problème en attendant). C'est un temps perdu pour chaque fichier transféré. La perte de temps dépend de la latence de la connexion. En fin de compte, le transfert peut être plus lent.

Lorsque vous transférez un seul fichier compressé, cette communication ne se produit qu'une seule fois.

Martin Prikryl
la source

Il active la compression gzip en ssh (sous le scp).

Sur des connexions lentes , cela accélérera les choses. Sur toute connexion raisonnablement rapide (100 Mbits ou plus rapide), la compression risque fort de ralentir les choses.

Il sera plus ou moins efficace que zip selon que gzip (plus précisément gzip -6) sera plus ou moins efficace que le niveau de compression zip que vous avez choisi.

Wayne Walker
la source

Dans mon cas particulier, la connexion est relativement bonne (je suis sur le campus), mais les dossiers que je dois copier sont très volumineux (~ 100 Go sur 442 .binet les .txtfichiers). Donc, vous suggéreriez simplement d’utiliser scp -r, pas de -Cdrapeau et non zip, gzipnon tar?

Remi.b

@ Remi.b: Vous devez probablement comparer les résultats et voir. La question est de savoir si le processeur est suffisamment rapide pour compresser les données plus rapidement qu’elles ne pourraient être envoyées sans compression sur le réseau. La réponse dépendra donc de votre machine et de votre réseau.

Nate Eldredge

Ok j'ai le point +1. Merci pour votre aide

Remi.b

SSH lui-même semble prendre un peu de temps CPU je remarque, parfois même au-delà de votre bande passante maximale. Je ne sais pas quoi faire là-bas ...

rogerdpack

La performance dépend également des données. La copie d'un fichier composé essentiellement de zéros sera hautement compressée. J'ai un lien de 500 Mo entre deux serveurs distants et je viens de copier un fichier 50G (VMWare VMDK) contenant tous les zéros sur ce lien à environ 128-130 Mo / s (vraisemblablement avec une limite de mémoire tampon de compression scp), ne prenant que 6 à 7 minutes environ. Sans compression, cela prendrait 1h45. Votre kilométrage variera en fonction de la complexité des données et de la qualité de la compression.

Topher le