¿Qué hace exactamente la bandera `-C` en` scp`?

Siempre uso cualquiera rsynco scppara copiar archivos desde / a una máquina remota. Recientemente, descubrí en el manual de scp( man scp) la bandera-C

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

Antes de descubrir esta bandera, solía hacerlo zipantes y después scp.

¿Es tan eficiente usar solo la -Ccompresión y descompresión? ¿Cuándo está utilizando uno u otro proceso hacer que la transferencia sea más rápida?

scp compression file-transfer

— Remi.b
fuente

La mejor forma en que creo es un punto de referencia para usted. Usando scp -rvy scp -Crvpara comparar el rendimiento.

— Cuonglm

Esto es totalmente irrelevante para la pregunta, pero zipes un formato de archivo muy "windows". Casi nunca lo verá ni lo necesitará cuando opere una máquina Linux con software nativo de Linux. tarse utiliza para enrollar directorios en un solo archivo, preservando permisos y nombres y tal, mientras que gzip, bzip2, xz, etc se utilizan para comprimir archivos. tars se comprimen, lo que hace tar.gzy tar.xzformatos comunes de archivos en Linux. He visto a personas rodar su propio scptrabajo con comandos como tar cvz directory | ssh machine 'cd somewhere; tar xz'.

— Score_Under

@Score_Under: Java también usa el formato zip para empaquetar archivos .jar, por lo que zip todavía se usa ampliamente en muchos servidores Linux.

— Johnny

En lugar de utilizar la opción en cada transferencia de archivos, puede colocar Compression yessu .ssh/configarchivo.

— Barmar

Si realmente quiere velocidad, puede evitar SSH: unix.stackexchange.com/questions/227951/…

— rogerdpack

Respuestas:

Realmente nunca hará una gran diferencia, pero comprimir el archivo antes de copiarlo debería ser un poco menos eficiente ya que usar un formato de contenedor como zipese puede encapsular múltiples archivos (como tar) es innecesario y no es posible transmitir zip entrada y salida (por lo que necesita un archivo temporal).

Por gzipotro lado, usarlo en lugar de zipdebería ser exactamente lo mismo, ya que es lo que ssh -Chace debajo del capó ... excepto que tragarse es más trabajo que simplemente usarlo ssh -C.

— Celada
fuente

Ok, verificare que gzipes. ¿Su respuesta significa que esa scp -rCes probablemente la solución más eficiente que tengo?

— Remi.b

Su respuesta no considera que -Ccomprime un flujo de protocolo interactivo. Solo considera los datos. Entonces tus conclusiones están equivocadas. Ver mi respuesta

— Martin Prikryl

@Celada Zip puede escribir en una canalización ya que el directorio de miembros se coloca al final. Sin embargo, como dijiste, descomprimir requiere buscar extraer más de un miembro y, por lo tanto, no se puede leer desde una tubería.

— jrw32982 apoya a Monica el

El -Cindicador permite una compresión gzip de una secuencia SSH.

Es un equivalente de Accept-Encoding: gzipen HTTP.

El rendimiento del indicador depende de un tipo de datos que transfiera:

Al transferir un solo archivo grande, el rendimiento sería casi el mismo que comprimir el archivo antes de la transferencia (descuidando la eficiencia del algoritmo zip vs gzip).

Pero usar -Ces un esfuerzo menor para usted como usuario.
Al transferir muchos archivos pequeños, el rendimiento será inferior a comprimir los archivos antes de la transferencia.

Una razón detrás de eso es que antes de cada transferencia de archivos, hay una comunicación interactiva entre el servidor SCP y el cliente (para intercambiar metadatos de archivos, como la marca de tiempo y los permisos). Entonces, ambos lados tienen que esperar un poco para que el otro lado responda (la compresión no ayudará mientras se espera) Es un tiempo perdido para cada archivo transferido. La cantidad de tiempo perdido depende de la latencia de la conexión. Al final, la transferencia puede ser de magnitud más lenta.

Cuando transfiere un solo archivo comprimido, esa comunicación ocurre solo una vez.

— Martin Prikryl
fuente

Permite la compresión gzip en ssh (debajo del scp).

En conexiones lentas esto acelerará las cosas, en cualquier conexión razonablemente rápida (100Mbit o más rápido) es muy probable que la compresión desacelere las cosas.

Será más o menos eficiente que zip en función de si gzip (específicamente gzip -6) sería más o menos eficiente que el nivel de compresión zip elegido

— Wayne Walker
fuente

En mi caso específico, tengo una conexión relativamente buena (estoy en el campus) pero las carpetas que tengo que copiar son muy grandes (~ 100GB sobre 442 .biny .txtarchivos). ¿Entonces sugeriría simplemente usar scp -ry sin -Cbandera y no zip, gzipno tar?

— Remi.b

@ Remi.b: Probablemente tenga que compararlo en ambos sentidos y ver. La pregunta es si la CPU es lo suficientemente rápida como para comprimir los datos a una velocidad mayor de la que podría enviarse a través de la red sin comprimir. Por lo tanto, la respuesta dependerá de su máquina y red en particular.

— Nate Eldredge

Ok, entendí el punto +1. Gracias por su ayuda

— Remi.b

El SSH en sí parece tomar algo de CPU, noto, a veces llegando al máximo por debajo de su ancho de banda máximo. No estoy seguro de qué hacer allí ...

— rogerdpack

El rendimiento también depende de los datos. Copiar un archivo que es esencialmente todos ceros estará muy comprimido. Tengo un enlace de 500Mb entre dos servidores remotos, y acabo de copiar un archivo 50G (VMWare VMDK) que contiene todos los ceros a través de este enlace a ~ 128-130MB / s (probablemente un límite de búfer de compresión scp), lo que toma solo unos 6-7 minutos. Sin compresión, esto llevaría 1:45 hrs. Su kilometraje variará según la complejidad de los datos y qué tan bien se puede comprimir.

— Topher