performance - tls - sftp linux ejemplo

¿Por qué cuando transfiero un archivo a través de SFTP, toma más tiempo que FTP? (9)

A modo de comparación, traté de transferir una imagen de disco ntfs de 299 GB de una computadora portátil i5 que ejecutaba Redy Ringtail Ubuntu alpha 2 live cd a un escritorio i7 con Ubuntu 12.04.1. Velocidades informadas:

sobre wifi + línea de alta tensión: scp: 5MB / sec (40 Mbit / sec)

sobre gigabit ethernet + netgear G5608 v3:

scp: 44MB / sec

sftp: 47MB / sec

sftp -C: 13MB / sec

Por lo tanto, en un buen enlace de gigabit, sftp es ligeramente más rápido que scp, las CPU rápidas de la era 2010 parecen ser lo suficientemente rápidas para encriptar, pero la compresión no es una ganancia en todos los casos.

Sin embargo, a pesar de un mal enlace gigabit de ethernet, he superado ampliamente a sftp scp. Algo acerca de que scp es muy hablador, consulte "scp UNBELIEVABLY slow" en comp.security.ssh desde 2008: https://groups.google.com/forum/?fromgroups=#!topic/comp.security.ssh/ldPV3msFFQw http://fixunix.com/ssh/368694-scp-unbelievably-slow.html

Copio manualmente un archivo a un servidor, y el mismo a un servidor SFTP. El archivo es de 140 MB.

FTP: tengo una tasa de alrededor de 11 MB / s

SFTP: tengo una tasa de alrededor de 4.5MB / s

Entiendo que el archivo debe ser encriptado antes de ser enviado. ¿Es el único impacto en la transferencia de archivos? (y en realidad este no es exactamente el tiempo de transferencia, sino el tiempo de encriptación).

Estoy sorprendido de tales resultados.

El cifrado no solo tiene CPU, sino también una sobrecarga de red.

Hay todo tipo de cosas que pueden hacer esto. Una posibilidad es "Traffic Shaping". Esto se hace comúnmente en entornos de oficina para reservar ancho de banda para actividades comerciales críticas. También puede ser realizado por la empresa de alojamiento web o por su ISP, por razones muy similares.

También puede configurarlo en casa de manera muy simple.

Por ejemplo, puede haber una regla que reserve el ancho de banda mínimo para FTP, mientras que SFTP podría estar bajo una regla de "todo lo demás". O puede haber una regla que limita el ancho de banda para SFTP, pero otra persona también está utilizando SFTP al mismo tiempo que usted.

Entonces: ¿Dónde transfieres el archivo desde y hacia?

Sí, el cifrado agrega algo de carga a su CPU, pero si su CPU no es antigua, eso no debería afectar tanto como usted dice.

Si habilita la compresión para SSH, SCP es realmente más rápido que FTP a pesar del cifrado SSH (si mal no recuerdo, el doble de rápido que los archivos que probé con FTP). Realmente no he usado SFTP, pero creo que usa SCP para la transferencia de archivos real. Por favor, intente esto y háganos saber :-)

SFTP no es FTP sobre SSH, es un protocolo diferente y es similar a SCP, ofrece más capabilities .

Soy el autor de HPN-SSH y un comentarista me pidió que lo hiciera. Me gustaría comenzar con un par de artículos de fondo. En primer lugar, es importante tener en cuenta que SSHv2 es un protocolo multiplexado: múltiples canales en una sola conexión TCP. Como tal, los canales SSH esencialmente desconocen el algoritmo subyacente de control de flujo utilizado por TCP. Esto significa que SSHv2 tiene que implementar su propio algoritmo de control de flujo. La implementación más común básicamente reimplementa ventanas deslizantes. Esto significa que tiene la ventana deslizante SSH montada en la parte superior de la ventana deslizante de TCP. El resultado final es que el tamaño efectivo del búfer de recepción es el mínimo de los búferes de recepción de las dos ventanas deslizantes. Stock OpenSSH tiene un tamaño máximo de buffer de recepción de 2MB, pero esto realmente termina siendo más cercano a ~ 1.2MB. La mayoría de los sistemas operativos modernos tienen un búfer que puede crecer (utilizando búferes de recepción de ajuste automático) hasta un tamaño efectivo de 4 MB. ¿Por qué importa esto? Si el tamaño del búfer de recepción es menor que el producto de retardo de ancho de banda (BDP), entonces nunca podrá llenar completamente el conducto, independientemente de qué tan rápido sea su sistema.

Esto se complica por el hecho de que SFTP agrega otra capa de control de flujo a los controles de flujo TCP y SSH. SFTP usa un concepto de mensajes sobresalientes. Cada mensaje puede ser un comando, un resultado de un comando o un flujo de datos masivo. Los mensajes pendientes pueden tener un tamaño de datagrama específico. Entonces terminas con lo que bien podrías pensar como otro buffer de recepción. El tamaño de este búfer de recepción es el tamaño del datagrama * mensajes pendientes máximos (ambos pueden establecerse en la línea de comando). El valor predeterminado es 32k * 64 (2MB). Por lo tanto, al usar SFTP, debe asegurarse de que el búfer de recepción TCP, el búfer de recepción SSH y el búfer de recepción SFTP tengan el tamaño suficiente (sin ser demasiado grande o puede tener problemas de búfer en sesiones interactivas).

HPN-SSH aborda directamente el problema del búfer SSH al tener un tamaño de búfer máximo de alrededor de 16 MB. Lo que es más importante, el búfer crece dinámicamente al tamaño adecuado mediante el sondeo de la entrada de proceso para el tamaño del búfer de la conexión TCP (básicamente haciendo un hoyo entre las capas 3 y 4). Esto evita el exceso de buffer en casi todas las situaciones. En SFTP elevamos el número máximo de solicitudes pendientes a 256. Al menos deberíamos estar haciendo eso, parece que el cambio no se propagó como se esperaba al conjunto de parches 6.3 (aunque está en 6.2. Lo arreglaré pronto). ) No hay una versión 6.4 porque 6.3 parches limpiamente contra 6.4 (que es una solución de seguridad de 1 línea desde 6.3). Puede obtener el conjunto de parches de sourceforge.

Sé que esto suena extraño, pero el tamaño correcto de los buffers fue el cambio más importante en términos de rendimiento. A pesar de lo que mucha gente piensa, el cifrado no es la verdadera fuente de bajo rendimiento en la mayoría de los casos. Puede probarse esto transfiriendo datos a fuentes que están cada vez más lejos (en términos de RTT). Notarás que cuanto más largo sea el RTT, menor será el rendimiento. Eso indica claramente que este es un problema de rendimiento dependiente de RTT.

De todos modos, con este cambio empecé a ver mejoras de hasta 2 órdenes de magnitud. Si entiende TCP, entenderá por qué esto marcó la diferencia. No se trata del tamaño del datagrama o la cantidad de paquetes ni nada de eso. Está completo porque para hacer un uso eficiente de la ruta de red debe tener un búfer de recepción igual a la cantidad de datos que pueden estar en tránsito entre los dos hosts. Esto también significa que es posible que no veas ninguna mejora si el camino no es suficientemente rápido y lo suficientemente largo. Si el BDP es inferior a 1,2 MB, HPN-SSH puede no ser útil para usted.

El cifrado AES-CTR paralelizado es un refuerzo de rendimiento en sistemas con múltiples núcleos si necesita tener un cifrado completo de extremo a extremo. Por lo general, sugiero a las personas (o tienen control sobre el servidor y el cliente) que utilicen el modificador de cifrado NONE (autenticación encriptada, datos masivos pasados sin cifrar) ya que la mayoría de los datos no son tan sensibles. Sin embargo, esto solo funciona en sesiones no interactivas como SCP. No funciona en SFTP.

También hay otras mejoras de rendimiento, pero nada tan importante como el correcto dimensionamiento de los buffers y el trabajo de cifrado. Cuando tenga algo de tiempo libre, probablemente canalizaré el proceso HMAC (actualmente el mayor lastre para el rendimiento) y realizaré un poco más el trabajo de optimización.

Entonces, si HPN-SSH es tan impresionante, ¿por qué OpenSSH no lo ha adoptado? Esa es una larga historia y la gente que conoce el equipo de OpenBSD probablemente ya sepa la respuesta. Entiendo muchas de sus razones: es un gran parche que requeriría trabajo adicional de su parte (y son un equipo pequeño), no les importa tanto el rendimiento como la seguridad (aunque no hay implicaciones de seguridad para HPN-SSH). ), etc, etc. Sin embargo, a pesar de que OpenSSH no utiliza HPN-SSH Facebook lo hace. También lo hacen Google, Yahoo, Apple, la mayoría de los grandes centros de datos de investigación, la NASA, la NOAA, el gobierno, el ejército y la mayoría de las instituciones financieras. Está muy bien investigado en este punto.

Si alguien tiene alguna pregunta, no dude en preguntar, pero es posible que no esté al día con este foro. Siempre puede enviarme correos a través de la dirección de correo electrónico HPN-SSH (google it).

Tus resultados tienen sentido. Dado que FTP opera a través de un canal no encriptado, es más rápido que SFTP (que es un subsistema sobre el protocolo SSH versión 2). También recuerde que SFTP es un protocolo basado en paquetes a diferencia de FTP basado en comandos.

Cada paquete en SFTP se cifra antes de ser escrito en el socket de salida del cliente y posteriormente descifrado cuando lo recibe el servidor. Esto, por supuesto, conduce a tasas de transferencia lentas pero una transferencia muy segura. El uso de compresión como zlib con SFTP mejora el tiempo de transferencia, pero aún así no estará cerca del texto plano FTP. ¿Tal vez una mejor comparación es comparar SFTP con FTPS que ambos usan cifrado?

La velocidad para SFTP depende del cifrado utilizado para el cifrado / descifrado, la compresión utilizada, por ejemplo, zlib, tamaños de paquetes y tamaños de búfer utilizados para la conexión del zócalo.

Varios factores afectan la velocidad de transferencia de SFTP:

Cifrado Aunque el cifrado simétrico es rápido, no es tan rápido para pasar desapercibido. Si compara las velocidades en una red rápida (100mbit o superior), el cifrado se convierte en un descanso para su proceso.
Cálculo y comprobación de hash
Copia de Buffer SFTP corriendo sobre SSH hace que cada bloque de datos se copie al menos 6 veces (3 veces en cada lado) más en comparación con FTP simple donde los datos en el mejor de los casos se pueden pasar a la interfaz de red sin copiarse en absoluto. Y la copia en bloque también lleva un poco de tiempo.

ACTUALIZACIÓN : Como señaló un comentarista, el problema que esbozo a continuación se corrigió un tiempo antes de esta publicación. Sin embargo, sabía del proyecto HP-SSH y le pedí al autor que interviniera. Como explican en la respuesta (con razón) la más votada, el cifrado no es la fuente del problema. ¡Yay por correo electrónico y personas más inteligentes que yo!

Guau, una pregunta de un año con nada más que respuestas incorrectas. Sin embargo, debo admitir que asumí que la desaceleración se debía a la encriptación cuando me hice la misma pregunta. Pero pregúntese cuál es la siguiente pregunta lógica: ¿con qué rapidez puede su computadora cifrar y descifrar datos? Si crees que la tasa está cerca de los 4.5Mb / segundo informados por el OP (.5625MBs o aproximadamente la mitad de la capacidad de un disquete de 5.5 ") hazlo unas cuantas veces, toma un café y hazte la misma pregunta otra vez .

~~Aparentemente tiene que ver con lo que equivale a un descuido en la selección del tamaño del paquete, o al menos eso es lo que dice el autor de LIBSSH2:~~

La naturaleza de SFTP y su ACK para cada pequeño fragmento de datos que envía hace que una implementación inicial ingenua de SFTP sufra mal al enviar datos a través de redes de alta latencia. Si tiene que esperar unos cientos de milisegundos por cada 32 KB de datos, nunca habrá transferencias rápidas de SFTP. Este tipo de implementación ingenua es lo que libssh2 ha ofrecido hasta e incluyendo libssh2 1.2.7.

Por lo tanto, el golpe de velocidad se debe a pequeños tamaños de paquete x respuestas de respuesta obligatoria para cada paquete, lo que es claramente una locura.

El proyecto High Performance SSH / SCP (HP-SSH) proporciona un conjunto de parches OpenSSH que aparentemente mejora los búferes internos y paralelamente el cifrado. Sin embargo, tenga en cuenta que incluso las versiones no paralelizadas funcionaron a velocidades superiores a las velocidades sin cifrar de 40Mb / s obtenidas por algunos comentaristas. La solución implica cambiar la forma en que OpenSSH llamaba a las bibliotecas de cifrado, NO el cifrado y la diferencia de velocidad entre AES128 y AES256. La encriptación toma algo de tiempo, pero es marginal. Pudo haber importado en los 90 pero (como la velocidad de Java vs C) ya no importa.