¿Cuál es la manera más rápida de transferir archivos a través de una red (FTP, HTTP, RSync, etc.)

Question

Estoy tratando de averiguar la mejor manera de transferir grandes cantidades de datos a través de una red entre dos sistemas. Actualmente estoy buscando ya sea FTP, HTTP o RSync, y me pregunto cuál es el más rápido. He mirado en línea para algunas respuestas y encontré los siguientes sitios:

• http://daniel.haxx.se/docs/ftp-vs-http.html
• http://www.isi.edu/lsam/publications/http-perf/

El problema es que estos son de edad, y hablar más sobre las diferencias teóricas entre cómo los protocolos comunicar. Estoy más interesado en los puntos de referencia reales, que pueden decir que para una configuración específica, cuando se transfieren archivos de diferentes tamaños, un protocolo es x% más rápido que los demás.

Ha probar cualquiera que estos y publicado los resultados en alguna parte?

Answer 1

Muy bien, así que la configuración de la siguiente prueba:

• hardware: 2 escritorios Intel Core Duo a 2,33 GHz CPU @, con 4G de memoria RAM.
• Sistema operativo: Ubuntu 11.10 en ambas máquinas
• Red: interruptor dedicado de 100Mb, ambas máquinas se conectan a ella.
• software:
  • servidor HTTP de Python (inspired by this).
  • Servidor FTP de Python (inspired by this).
  • Cliente HTTP Python (inspired by this).
  • Cliente FTP de Python (inspired by this).

he subido los siguientes grupos de archivos en cada servidor:

1. 1 100 millones de archivos.
2. 10 10M archivos.
3. 100 archivos de 1M.
4. 1,000 100K archivos.
5. 10,000 10K archivos.

Me dieron los siguientes resultados medios obtenidos durante múltiples carreras (números en segundos):

|-----------+---------+----------| 
| File Size | FTP (s) | HTTP (s) | 
|-----------+---------+----------| 
|  100M |  8 |  9 | 
|  10M |  8 |  9 | 
|  1M |  8 |  9 | 
|  100K |  14 |  12 | 
|  10K |  46 |  41 | 
|-----------+---------+----------| 

Por lo tanto, parece que FTP es ligeramente más rápido en archivos de gran tamaño, y HTTP es un poco más rápido en muchos pequeños archivos. Con todo, creo que son comparables, y la implementación del servidor es mucho más importante que el protocolo.

Answer 2

rsync comprime opcionalmente sus datos. Eso típicamente hace que la transferencia sea mucho más rápida. Ver rsync -z.

Usted no ha mencionado SCP, pero scp -C también comprime.

Tenga en cuenta que la compresión puede hacer que la transferencia sea más rápida o más lenta, dependiendo de la velocidad de su CPU y de su enlace de red. (Los enlaces más lentos y la CPU más rápida hacen que la compresión sea una buena idea; los enlaces más rápidos y la CPU más lenta hacen que la compresión sea una mala idea). Como con cualquier optimización, mida los resultados en su propio entorno.

Answer 3

Si las máquinas en cada extremo son razonablemente potentes (es decir, no netbooks, cajas NAS, tostadoras, etc.), entonces esperaría que todos los protocolos que funcionan con TCP tengan la misma velocidad para transferir datos masivos. El trabajo del protocolo de aplicación es simplemente llenar un búfer para que se transfiera TCP, de modo que mientras lo mantengan lleno, TCP establecerá el ritmo.

protocolos que hacen compresión o cifrado pueden atascarse en la CPU en máquinas menos potentes. Mi netbook hace FTP mucho más rápido que SCP.

rsync hace cosas inteligentes para transmitir los cambios incrementales de forma rápida, pero para las transferencias a granel no tiene ninguna ventaja sobre los protocolos más mudos.

Answer 4

Me temo que si quiere saber la respuesta para sus necesidades y configuración, debe ser más específico o realizar sus propias pruebas de rendimiento (y fiabilidad). Ayuda a tener una comprensión al menos rudimentaria de los protocolos en cuestión y su comunicación, por lo que consideraría que los artículos que ha estado citando son un recurso útil. También ayuda saber qué restricciones enfrentaron los primeros inventores de estos protocolos: ¿su objetivo era mantener el impacto de la red bajo, estaban hambrientos de memoria o tenían que contar sus ciclos de CPU? Aquí hay algunas cosas a tener en cuenta o responder si desea obtener una respuesta adaptada a su situación:

• sistema OS/archivo relacionado:
  • ¿Está copiando entre el mismo sistema operativo combinación/FS o tiene preocuparse por las incompatibilidades, como los tipos de archivos sin equivalente equivalente en el extremo receptor?
  • I.e. ¿tienes algo especial para transportar? Metadatos, fuentes de recursos, atributos extendidos, permisos de archivos pueden no ser transportados por el protocolo/herramienta de su elección, o no tener sentido en el extremo receptor.
  • Lo mismo ocurre con los archivos dispersos, que pueden terminar hinchados a tamaño completo en el otro extremo de la copia, arruinando todos los planes que pueda haber tenido sobre el tamaño.
• limitaciones físicas relacionadas: impacto
  • Red
  • carga de la CPU: hoy en día, la compresión es mucho "más barato", ya que los CPU modernos son menos desafiados por la compresión que los de vuelta en los momentos en que la mayoría de los protocolos de transferencia fueron diseñados.
  • tolerancia a fallas: ¿necesita poder continuar donde lo dejó una transferencia interrumpida o prefiere comenzar de nuevo?
  • transferencias incrementales, o transferencias completas? ¿Una transferencia incremental representa grandes ahorros para usted, o tiene transferencias completas por diseño de su tarea de todos modos? En este último caso, la latencia añadida y el impacto de la memoria para construir la lista de transferencias antes de comenzar la transferencia serían un compromiso menos deseable.
  • ¿Qué tan bueno es el protocolo al utilizar la MTU disponible en su protocolo de red subyacente?
  • ¿Necesita mantener un flujo constante de datos, por ejemplo, para mantener la transmisión de una unidad de cinta en el extremo receptor?

Hay muchas cosas a tener en cuenta, y estoy seguro de que el anuncio no es aún completa.

Answer 5

Otra utilidad a considerar es bbcp: http://www.slac.stanford.edu/~abh/bbcp/.

Un buen tutorial pero anticuado para usarlo está aquí: http://pcbunn.cithep.caltech.edu/bbcp/using_bbcp.htm. Descubrí que bbcp es extremadamente bueno para transferir archivos de gran tamaño (varios GB). En mi experiencia, es más rápido que rsync en promedio.