¿Acelerar las cargas de SFTP en la red de alta latencia?

27

Estoy tratando de transferir un conjunto de archivos grandes internacionalmente usando SFTP, pero descubro que mi socio internacional no puede obtener velocidades de carga superiores a ~ 50k a pesar de las muy buenas conexiones en ambos lados. Podemos cargar múltiples conexiones a esta velocidad (¿entonces no ancho de banda?), Pero ninguna carga mejora la velocidad, lo cual es un problema ya que muchos archivos tienen un tamaño de varios GB.

El SFTP se aloja utilizando el sistema SFTP estándar de "Inicio de sesión remoto" de Apple OSX.

¿Hay alguna manera de mejorar las velocidades de carga o hay un host SFTP diferente que ayudaría? No me queda claro si se trata de un problema de configuración o una limitación inherente del protocolo.

(Por razones de seguridad, necesito usar una conexión punto a punto cifrada de extremo a extremo, sin servicios en la nube).

nick_eu
fuente
Si tiene el presupuesto, existen soluciones comerciales que funcionan mucho mejor que los sistemas de transferencia de archivos basados ​​en TCP como SFTP.
Kenster
44
Si se trata de una transferencia de una vez en varios gb, ¿por qué no probar una alternativa a Internet ?
vasin1987
1
Un simple script de shell para iniciar N rsynctransferencias logrará fácilmente sus requisitos de 1. Transferencia segura y 2. Maximización de su ancho de banda. Vea aquí un ejemplo de cómo iniciar rsynctransferencias N stackoverflow.com/a/38014502/52074
Trevor Boyd Smith
2
O simplemente use uftp-multicast.sourceforge.net. El deseo cifrará y Mac eliminará su ancho de banda.
Trevor Boyd Smith
44
Contrariamente a su última oración, el servicio en la nube debería estar bien si encripta el archivo localmente, lo transfiere a través de la nube y luego lo desencripta localmente en el otro extremo), lo que aún significaría encriptación de extremo a extremo. (Es posible que desee agregar algunos comentarios breves sobre una recepción exitosa). Utiliza el cifrado sftp para evitar ataques de alguien capaz de rastrear todo su tráfico. Por lo tanto, simplemente darles los datos cifrados no es peor que asumir que podrían obtenerlos de todos modos.
Hagen von Eitzen

Respuestas:

29

Con el cliente OpenSSHsftp (que parece usar), puede usar:

  • -Rcambiar para aumentar la longitud de la cola de solicitud (el valor predeterminado es 64)
  • -Bcambie para aumentar el tamaño de la solicitud de lectura / escritura (el valor predeterminado es 32 KB)

Para empezar, intenta duplicar ambos:

sftp -R 128 -B 65536 user@host

Probablemente no importa mucho, cuál de ellos aumenta.

El aumento de cualquiera debería ayudar a saturar su conexión de alta latencia. Con la configuración anterior, mantendrá un flujo de datos de 8 MB en la tubería en cualquier momento (128 * 64K = 8M).

Tenga en cuenta que esto solo ayuda con las transferencias de archivos grandes. No tendrá ningún efecto cuando transfiera muchos archivos pequeños.


Para algunos antecedentes y una discusión sobre otros clientes SFTP (GUI), vea la sección "Retraso / latencia de red" de mi respuesta a ¿Por qué la transferencia de archivos SFTP de FileZilla tiene un límite máximo de 1.3MiB / seg en lugar de saturar el ancho de banda disponible? rsync y WinSCP son aún más lentos .

Martin Prikryl
fuente
4

Podría intentar habilitar la compresión y ver si eso ayuda.

De man sftp:

-C Habilita la compresión (a través de ssh's -C flag).

Y de man ssh:

-C Solicita la compresión de todos los datos (incluidos stdin, stdout, stderr y datos para conexiones de dominio X11, TCP y UNIX reenviadas). El algoritmo de compresión es el mismo que usa gzip (1), y el "nivel" puede controlarse mediante la opción CompressionLevel para la versión de protocolo 1. La compresión es deseable en las líneas de módem y otras conexiones lentas, pero solo ralentizará las cosas en redes rápidas . El valor predeterminado se puede establecer host por host en los archivos de configuración; ver la opción de compresión.

Parece que la conexión podría tener una velocidad limitada en algún punto a lo largo de su ruta (o más bien, me parece la explicación más simple para sus 50kB / s por conexión, pero es posible que existan múltiples conexiones de este tipo), aunque podría no ser un mala idea para asegurarse de que los discos en ambos lados no sean un factor.

También puede ejecutar un pcap rápido para ver si hay problemas 'obvios' (como una gran cantidad de retransmisiones), pero a menos que tenga cierta confianza en que podrá abordar esto, probablemente vería si habilitar la compresión podría ayuda.

iwaseatenbyagrue
fuente
¡Gracias! Lamentablemente, los archivos están precomprimidos, así que dudo que haga algo ...: /
nick_eu
La compresión no acelera las cosas aquí, incluso si los datos no se comprimen. Es una sobrecarga de tiempo de CPU (y retraso) demasiado grande, por lo que no tiene sentido en estos días.
Jakuje
1
Si el cuello de botella es la red, un poco más de CPU en ambos lados no debería ralentizar nada @Jakuje, a menos que la caja no pueda comprimirse a 50kB / s, lo que no debería ser un problema.
Ben
@Ben La pregunta establece claramente que la red no es un cuello de botella.
Jakuje
4

Estoy tratando de transferir un conjunto de archivos grandes internacionalmente usando SFTP

Todavía no se ha mencionado como respuesta, pero al transferir varios archivos a través de un enlace de alta latencia, hay una solución realmente simple para obtener un mejor rendimiento:

Transfiere múltiples archivos en paralelo.

Y es una solución que incluso mencionaste en tu pregunta. Úsalo.

Básicamente, el protocolo TCP no maneja muy bien las conexiones con un gran producto de retraso de ancho de banda: una sola conexión no puede mantener suficientes datos en movimiento en cualquier momento. Ver https://en.wikipedia.org/wiki/TCP_tuning

Como cada conexión está limitada por el protocolo TCP, solo use más conexiones.

Andrew Henle
fuente
1
Aquí se explica cómo paralelizar las transferencias SFTP: serverfault.com/questions/248105/…
niutech
3

Acelera las transferencias sftp

Suponiendo que sus problemas sean el ajuste de la red y / o la limitación por conexión TCP, eche un vistazo a sftp utilizando el subsistema espejo lftp

El ajuste de la red en cada extremo es un tema mucho más grande y requeriría mucho de ida y vuelta, lo que lleva el tema fuera del alcance de ServerFault. Para conexiones individuales, la compresión mencionada por iwaseatenbyagrue puede ayudar de cualquier manera. Esto supone que el extremo remoto permite la compresión.

Aaron
fuente
3

(Mencionas "alta latencia" en el título de la pregunta, pero no en el texto del cuerpo. ¿Has medido la latencia real y cuáles son los resultados?)

Hay un parche para OpenSSH que mejora explícitamente el rendimiento en un enlace de red de alta latencia: HPN-SSH : (énfasis mío)

SCP y la implementación del protocolo SSH2 subyacente en OpenSSH es el rendimiento de la red limitado por buffers de control de flujo interno definidos estáticamente. Estos búferes a menudo terminan actuando como un cuello de botella para el rendimiento de red de SCP, especialmente en enlaces de red de banda larga y alta. La modificación del código ssh para permitir que se definan los búferes en tiempo de ejecución elimina este cuello de botella. Hemos creado un parche que eliminará los cuellos de botella en OpenSSH y es totalmente interoperable con otros servidores y clientes. Además, los clientes de HPN podrán descargar más rápido desde servidores que no sean de HPN, y los servidores de HPN podrán recibir cargas más rápido desde clientes que no sean de HPN.

Por lo tanto, intente compilar y usar HPN-SSH en el lado de recepción, y vea si mejora su velocidad de transferencia.

embajador twisteroid
fuente
¡Gracias! En realidad no he medido, ahora me da vergüenza admitirlo, pero voy a dar la vuelta al mundo en un país con Internet, así que supongo que tengo razón. :) Parche suena muy útil!
nick_eu
@nick_eu He visto anécdotas de que los científicos usarían HPN-SSH para transferir grandes cantidades de datos científicos a través del Atlántico. Parece que debería ser perfecto para su caso de uso.
embajador twisteroid
0

No estoy seguro de si esta es una opción para usted, pero ¿ha intentado tirar frente a enviar los datos al sitio internacional? ¿Y también en diferentes momentos para ver si es un problema con la contienda por los recursos de la red?

Sleepyweasel
fuente
Gran idea, lo intentaré.
nick_eu
0

Podemos cargar múltiples conexiones a esta velocidad (¿no es así el ancho de banda?)

Suena como un problema de configuración, ya sea deliberadamente (como una forma de aumentar la venta de servicios sin tener que hacer ninguna provisión adicional) o por accidente (p. Ej. , Escala de ventanas rotas o control de tráfico excesivo). Si bien puede hacer que las transferencias sean paralelas, no nos ha dicho nada sobre lo que hay en el otro extremo de la conexión o si vale la pena desarrollar algunos scripts simples para manejar la división / reconstitución de archivos.

Es poco probable que ajustar el tamaño de la cola y la compresión tengan un impacto significativo, a menos que la causa esté muy mal escrita en el software (y openSSH no entra en esta categoría; no tiene mucho sentido usar openssh con una cola de solicitud más larga / tamaño de bloque más grande a menos que la latencia sea más de 250 ms. Puede considerar probar con diferentes clientes de diferentes ubicaciones para descartar un problema con el servidor.

Mi primera llamada sería identificar qué proveedor tiene la culpa del problema, pedirles que solucionen el problema o cambiar a un proveedor diferente.

symcbean
fuente
Lo siento, debería haber sido más claro. No hay un "proveedor": estoy alojando en mi propio escritorio y un colega está intentando conectarse desde su computadora. El colega solo está abriendo una sesión ssh (no estoy seguro del protocolo pero puede verificar) y está usandoput
nick_eu
@nick_eu está hablando de los proveedores de internet.
Džuris
Parece un problema de configuración No. No es un problema de configuración. El protocolo TCP en sí mismo no funciona bien en conexiones con un gran producto de retraso de ancho de banda. Básicamente, si la conexión es tal que muchos datos pueden estar en vuelo a la vez, el protocolo TCP en sí mismo no puede mantener esa cantidad de datos en movimiento en ningún momento. Es por eso que las conexiones TCP paralelas funcionan para mejorar las tasas de transferencia de datos.
Andrew Henle
"no funciona bien en conexiones con un producto de gran retraso de ancho de banda" - lea RFC 1323 (desde 1992) y 7323 (reemplazado 1323 en 2014)
symcbean
@symcbean Luego explique los OP's. Podemos cargar múltiples conexiones a esta velocidad (¿entonces no el ancho de banda?), pero ninguna carga mejora la velocidad. Ese es un síntoma clásico de TCP sobre una conexión con latencia extrema: lo único que pueden hacer las extensiones TCP es mitigar el problema un poco ya que no pueden abordar los problemas fundamentales con el protocolo en sí. Y buena suerte con la identificación de qué proveedor es el culpable del problema, pídales que solucionen el problema mientras intentan "transferir un conjunto de archivos grandes internacionalmente".
Andrew Henle