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

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).

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 .

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.

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.

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.

(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.

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?

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.