sitios servidores servidor paginas gratuitos direccion definicion cliente http networking file-upload ftp rsync

http - paginas - servidores ftp gratuitos



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

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

El problema es que son viejos y hablan más sobre las diferencias teóricas entre cómo se comunican los protocolos. Estoy más interesado en los puntos de referencia reales, que pueden decir que para una configuración específica, al transferir archivos de diferentes tamaños, un protocolo es x% más rápido que los otros.

¿Alguien ha probado esto y publicado los resultados en alguna parte?

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

  • OS / Sistema de archivos relacionados:
    • ¿está copiando entre la misma combinación de OS / FS o tiene que preocuparse por las incompatibilidades, como los tipos de archivos sin el equivalente equivalente en el extremo receptor?
    • ¿Tienes algo especial para transportar? Los metadatos, las bifurcaciones de recursos, los atributos extendidos, los permisos de archivos pueden no ser transportados por el protocolo / herramienta de su elección, o pueden ser sin sentido en el extremo receptor.
    • Lo mismo ocurre con los archivos dispersos, que pueden terminar hinchándose hasta el tamaño completo en el otro extremo de la copia, arruinando todos los planes que pueda haber tenido sobre el tamaño.
  • Restricciones físicas relacionadas:
    • Impacto de red
    • carga de la CPU: hoy en día, la compresión es mucho más "barata", ya que las CPU modernas tienen menos desafíos con la compresión que aquellas en los tiempos en que se diseñaron la mayoría de los protocolos de transferencia.
    • tolerancia a fallos: ¿necesita poder continuar donde lo dejó una transferencia interrumpida o prefiere comenzar de nuevo?
    • ¿Transferencias incrementales, o transferencias completas? ¿Una transferencia incremental supone un gran ahorro para usted, o tiene transferencias completas por el diseño de su tarea de todos modos? En este último caso, la latencia agregada y el impacto en la memoria para construir la lista de transferencia antes de comenzar la transferencia sería una compensación menos deseable.
    • ¿Qué tan bueno es el protocolo para utilizar la MTU disponible por 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 que considerar, y estoy seguro de que la lista ni siquiera está completa.

Muy bien, entonces configuro la siguiente prueba:

  • Hardware: 2 computadoras Intel Core Duo CPU a 2.33 GHz, con 4G de RAM.
  • OS: Ubuntu 11.10 en ambas máquinas
  • Red: conmutador dedicado de 100Mb, ambas máquinas están conectadas a él.
  • Software:

Subí los siguientes grupos de archivos a cada servidor:

  1. 1 archivo de 100M.
  2. 10 archivos 10M.
  3. 100 archivos 1M.
  4. 1.000 archivos de 100K.
  5. 10.000 archivos 10K.

Obtuve los siguientes resultados promedio en varias ejecuciones (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 | |-----------+---------+----------|

Entonces, parece que FTP es un poco más rápido en archivos grandes, y HTTP es un poco más rápido en muchos archivos pequeños. En general, creo que son comparables, y la implementación del servidor es mucho más importante que el protocolo.

Si las máquinas en cada extremo son razonablemente poderosas (es decir, no son netbooks, cajas NAS, tostadoras, etc.), entonces esperaría que todos los protocolos que funcionan sobre TCP tengan una velocidad similar a la de la transferencia de datos en masa. El trabajo del protocolo de la aplicación es realmente solo llenar un búfer para que TCP pueda transferir, por lo que mientras puedan mantenerlo lleno, TCP marcará el ritmo.

Los protocolos que realizan compresión o encriptación pueden producir cuellos de botella 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 cambios incrementales rápidamente, pero para transferencias masivas no tiene ninguna ventaja sobre los protocolos más tontos.

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

No mencionaste scp, pero scp-C también se 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). Al igual que con cualquier optimización, mida los resultados en su propio entorno.