La velocidad no es la diferencia importante entre FTP y los demás.
ceejayoz
2
No estoy seguro de por qué se votó fuera de tema. Ciertamente, es muy relevante para mi trabajo como administrador de sistemas profesional: ¿por qué las transferencias de archivos no se utilizaron cerca del ancho de banda de toda la ruta de conexión?
Dan Pritts
Puede compensar la diferencia de velocidad de SFTP utilizando múltiples conexiones TCP controladas por LFTP y el subsistema espejo usando SFTP sin sacrificar la seguridad. Incluso puede usar múltiples hilos para un solo archivo grande.
Aaron
Respuestas:
29
Si tiene una red rápida de área amplia, encontrará eso sftpy tendrá scpaproximadamente la misma velocidad, que es lenta. Ambos sufren problemas de rendimiento en el openssh subyacente. Con el hardware moderno, esto no se debe a la sobrecarga de cifrado, sino a problemas con la implementación de openssh: implementa su propio mecanismo interno de ventanas que se descompone en conexiones rápidas.
Estos problemas se vuelven más obvios en las conexiones de larga distancia (mayor latencia), pero he experimentado lentitud incluso en las LAN.
Estos están bien documentados y hay parches disponibles para solucionar el problema. Parchear cualquier extremo de la conexión puede ayudar; Lo ideal sería parchear ambos extremos. Para obtener más información y los parches, consulte SSH de alto rendimiento en Pittsburgh Supercomputer Center.
Por cierto, la sobrecarga de cifrado también puede convertirse en un problema, una vez que se resuelve el problema de la ventana. Los parches también tienen soluciones para eso.
Mientras tanto, encontrarás que ftpes lamentablemente inseguro; envía contraseñas en texto plano.
ftpsCreo que envuelve el protocolo ftp en SSL. Probablemente sea más rápido que SFTP / SCP sin parchear.
Una nota final: en mi experiencia, el cliente WinSCP es (al menos a veces) dolorosamente lento. No sé por qué, pero según sus preguntas frecuentes, no soy la única persona que ha tenido este problema. Entonces, si está scp''desde Windows, y parece lento, intente con un cliente diferente. Incluso con un servidor openssh no parcheado, puede hacerlo mucho, mucho mejor con un cliente diferente. No estoy seguro de cuáles son buenos clientes, desafortunadamente.
Finalmente. Alguien que sabe de qué están hablando. Sí, FTPS es básicamente FTP en SSL. SFTP / SCP siempre será más lento que cuando se utiliza FTP
Jason
¿Tienes alguna idea de por qué obtengo 300 kb / s con scp mientras obtengo alrededor de 10 Mb / s (casi la velocidad máxima) con sftp? Eso no parece ser "aproximadamente la misma velocidad". Esto es más de 100Mbps ethernet.
graywolf
Supongo que su scp es una implementación defectuosa (por ejemplo, WinSCP), pero su sftp no lo es. Incluso si están en el mismo contenedor GUI, pueden ser diferentes en el interior.
Dan Pritts
Dan, ¿alguna idea de por qué este parche SSH no se aplica al OpenSSH principal? Claramente, es 1 ~ 2 órdenes de magnitud mejor (> 10x incluso en una LAN de 100Mbps), entonces ¿por qué no es este el nuevo estándar OpenSSH? ¿Cómo podemos hacerlo?
Gabriel Staples
Tengo entendido que PSC envió los parches a la gente de openbsd (que escribe openssh). No estaban interesados. Escuché vagas declaraciones de que ninguna de las personas de openbsd tenía conexiones de gran ancho de banda y no notaron ningún problema, y / o necesariamente creyeron que había un problema real. Esto fue hace varios años, y es un rumor, por lo que no puedo garantizar su precisión.
Dan Pritts
4
En general, todos los protocolos funcionarán aproximadamente igual. Es más probable que esté limitado por la velocidad de su red o disco que por el protocolo.
Las versiones anteriores de OpenSSH (SFTP / SCP) usaban un tamaño de ventana fijo que limitaría la velocidad en redes de alta latencia (digamos transatlántico). Hay un conjunto de parches para solucionar este problema llamado HPN (red de alto rendimiento) y se incluye en la mayoría de las instalaciones modernas de OpenSSH.
Si se encuentra en una situación como un enlace LAN de gigabit o más rápido y una CPU más lenta, SFTP / SCP puede encontrarse con un cuello de botella. Podrá saberlo porque el proceso ssh / scp / sftp utilizará el 100% de la CPU en el alojamiento de envío o recepción. Si está utilizando una versión más reciente de OpenSSH (6.4+), puede habilitar una versión roscada del cifrado AES que podrá utilizar más de 1 núcleo para manejar el cifrado y será menos probable que esté limitado por la CPU en lugar del disco o ancho de banda de la red.
Si controla tanto el lado de envío como el de recepción, OpenSSH 6+ también tiene un modo opcional 'NONECIPHER'. Esto utiliza el cifrado regular / claves, etc. para iniciar sesión en la máquina remota, pero luego cae a una conexión no cifrada para la copia del archivo real. Esto eliminará la sobrecarga de la CPU. Hay salvaguardas integradas en NONECIPHER que le impiden obtener un shell que no está encriptado.
Al final, el protocolo no debería ser la limitación de la velocidad, aunque las versiones anteriores de ssh tienen problemas con los enlaces de alta latencia.
Es bueno saber que los valores predeterminados ahora son tener los parches instalados, aunque parece que redhat ha decidido explícitamente no hacerlo ( access.redhat.com/site/solutions/53215 ). Además, tenga en cuenta que la latencia transatlántica no es realmente tanto. Ping rtts actuales: umich -> stanford (california): 89ms. umich -> cambridge (reino unido): 134ms. Además, ¿no es la combinación de latencia y ancho de banda que causa el problema? así que la latencia más baja pero los enlaces de mayor ancho de banda aún pueden tener problemas.
Dan Pritts
3
Basado en la sobrecarga de cifrado, diría que el FTP simple probablemente tenga un rendimiento ligeramente mejor que los otros protocolos, pero probablemente sea insignificante. Usaría el protocolo que proporciona la seguridad que necesita primero, luego me preocuparía por el rendimiento.
Dicho esto, tendrás que configurar una prueba para encontrar los números reales. Todo lo anterior es solo mi opinión. Si está probando el rendimiento localmente, configure un servidor en su red. Si el uso final será a través de Internet, realice la prueba desde un host externo.
El rendimiento general es de órdenes de magnitud, no leve. Más cerca de 10x que 2x más lento. Me sorprendí a mí mismo.
Gomibushi
2
Como siempre, google tiene las respuestas, FTP v / s SFTP v / s FTPS
que dice FTP> FTPS> SFTP
FTP también parece ser más rápido que SCP en la prueba de otra persona ( http://www.lysesoft.com/support/forums /viewtopic.php?f=5&t=542 ) pero recomendaría probarlo usted mismo para verlo.
Por lo tanto, configure SCP y FTP en cualquier casilla aleatoria de su red, luego ejecute una transferencia de archivos típica y vea cuánto tarda en ambos
¿Por qué dice que FTP es un protocolo de Internet y SCP para LAN?
Dan Pritts
55
Ah, veo que obtuviste eso del artículo vinculado de eHow. ¿Cómo está mal? Ambos protocolos fueron diseñados para el uso de Internet. El artículo tiene varios otros errores; el escritor claramente no sabe de qué está hablando.
Dan Pritts
Ahora que lo pienso, tienes razón, probablemente debería haberlo comprobado.
1
Sitios como eHow nunca saben de qué están hablando.
Respuestas:
Si tiene una red rápida de área amplia, encontrará eso
sftpy tendráscpaproximadamente la misma velocidad, que es lenta. Ambos sufren problemas de rendimiento en el openssh subyacente. Con el hardware moderno, esto no se debe a la sobrecarga de cifrado, sino a problemas con la implementación de openssh: implementa su propio mecanismo interno de ventanas que se descompone en conexiones rápidas.Estos problemas se vuelven más obvios en las conexiones de larga distancia (mayor latencia), pero he experimentado lentitud incluso en las LAN.
Estos están bien documentados y hay parches disponibles para solucionar el problema. Parchear cualquier extremo de la conexión puede ayudar; Lo ideal sería parchear ambos extremos. Para obtener más información y los parches, consulte SSH de alto rendimiento en Pittsburgh Supercomputer Center.
Por cierto, la sobrecarga de cifrado también puede convertirse en un problema, una vez que se resuelve el problema de la ventana. Los parches también tienen soluciones para eso.
Mientras tanto, encontrarás que
ftpes lamentablemente inseguro; envía contraseñas en texto plano.ftpsCreo que envuelve el protocolo ftp en SSL. Probablemente sea más rápido que SFTP / SCP sin parchear.Una nota final: en mi experiencia, el cliente WinSCP es (al menos a veces) dolorosamente lento. No sé por qué, pero según sus preguntas frecuentes, no soy la única persona que ha tenido este problema. Entonces, si está scp''desde Windows, y parece lento, intente con un cliente diferente. Incluso con un servidor openssh no parcheado, puede hacerlo mucho, mucho mejor con un cliente diferente. No estoy seguro de cuáles son buenos clientes, desafortunadamente.
fuente
En general, todos los protocolos funcionarán aproximadamente igual. Es más probable que esté limitado por la velocidad de su red o disco que por el protocolo.
Las versiones anteriores de OpenSSH (SFTP / SCP) usaban un tamaño de ventana fijo que limitaría la velocidad en redes de alta latencia (digamos transatlántico). Hay un conjunto de parches para solucionar este problema llamado HPN (red de alto rendimiento) y se incluye en la mayoría de las instalaciones modernas de OpenSSH.
Si se encuentra en una situación como un enlace LAN de gigabit o más rápido y una CPU más lenta, SFTP / SCP puede encontrarse con un cuello de botella. Podrá saberlo porque el proceso ssh / scp / sftp utilizará el 100% de la CPU en el alojamiento de envío o recepción. Si está utilizando una versión más reciente de OpenSSH (6.4+), puede habilitar una versión roscada del cifrado AES que podrá utilizar más de 1 núcleo para manejar el cifrado y será menos probable que esté limitado por la CPU en lugar del disco o ancho de banda de la red.
Si controla tanto el lado de envío como el de recepción, OpenSSH 6+ también tiene un modo opcional 'NONECIPHER'. Esto utiliza el cifrado regular / claves, etc. para iniciar sesión en la máquina remota, pero luego cae a una conexión no cifrada para la copia del archivo real. Esto eliminará la sobrecarga de la CPU. Hay salvaguardas integradas en NONECIPHER que le impiden obtener un shell que no está encriptado.
Al final, el protocolo no debería ser la limitación de la velocidad, aunque las versiones anteriores de ssh tienen problemas con los enlaces de alta latencia.
fuente
Basado en la sobrecarga de cifrado, diría que el FTP simple probablemente tenga un rendimiento ligeramente mejor que los otros protocolos, pero probablemente sea insignificante. Usaría el protocolo que proporciona la seguridad que necesita primero, luego me preocuparía por el rendimiento.
Dicho esto, tendrás que configurar una prueba para encontrar los números reales. Todo lo anterior es solo mi opinión. Si está probando el rendimiento localmente, configure un servidor en su red. Si el uso final será a través de Internet, realice la prueba desde un host externo.
fuente
Como siempre, google tiene las respuestas,
FTP v / s SFTP v / s FTPS
que dice FTP> FTPS> SFTP
FTP también parece ser más rápido que SCP en la prueba de otra persona ( http://www.lysesoft.com/support/forums /viewtopic.php?f=5&t=542 ) pero recomendaría probarlo usted mismo para verlo.
Por lo tanto, configure SCP y FTP en cualquier casilla aleatoria de su red, luego ejecute una transferencia de archivos típica y vea cuánto tarda en ambos
fuente