¿Por qué Dropbox puede ser súper rápido en comparación con FTP?


36

Me gustaría saber por qué técnicamente Dropbox es mucho más rápido que FTP. ¿Qué tipo de tecnología utiliza?

No estoy hablando de archivos diff, estoy hablando de transferir archivos nuevos en ambos casos, Dropbox es mucho más rápido.

Lo digo en serio, mucho más rápido, tal vez 10 veces más rápido que FTP para los archivos que cargué. Experimentaré nuevamente para archivos más grandes más tarde.


2
¿Qué tamaño, tipo y número de archivos subiste? ¿Cuánto tiempo tardó cada uno en cargar? ¿Dónde estaba cargando los archivos a través de FTP? Dropbox no es mágico, la explicación más simple es que el servidor FTP que estaba cargando también tiene mucho menos ancho de banda que Amazon.
usuario23307

2
si ya lo tienen, no se vuelve a cargar; p
Journeyman Geek

44
Dices "nuevos archivos", pero a menos que estos archivos sean datos nuevos y aleatorios, probablemente estés viendo el beneficio de la sincronización a nivel de bloque (como en rsync y otras herramientas).
Chris Johnsen

1
Esto es más una comparación de alojamiento, sé que los servidores FTP son más rápidos que Dropbox y también uso múltiples conexiones con Filezilla, por lo que las declaraciones enumeradas en estas respuestas no son válidas.
Tamara Wijsman

Dropbox utiliza la desduplicación para ahorrar espacio de almacenamiento de archivos comunes, por lo que no es necesario cargarlos si ya los tiene.
paradroid

Respuestas:


31

Podría haber varias razones para esto.
El protocolo FTP está lejos de ser eficiente.

  1. Una transferencia FTP necesita al menos dos conexiones (una para control y otra para datos) donde DropBox puede estar usando solo una conexión HTTP. Además, la conexión de datos para una sesión FTP puede abrirse desde el servidor a su cliente y si tiene NAT esto puede fallar, por lo que su cliente FTP puede estar intentando conectarse de esa manera, fallando y luego intentando lo contrario.

  2. Hay muchas cosas que hacer en una conexión FTP. Para enviar un archivo, el cliente debe enviar un mínimo de dos comandos (uno para abrir la conexión de datos y otro para iniciar el envío) y cada vez que necesita esperar a que el servidor responda, agregando latencia adicional. Además de estos dos viajes de ida y vuelta por archivo, hay varios viajes de ida y vuelta de comando para la conexión inicial: uno para enviar el nombre de usuario, otro para la contraseña y al menos uno para establecer los parámetros de transferencia (para asegurarse de que el servidor esté esperando datos binarios, no ASCII). El cliente también puede emitir un par de comandos adicionales para recuperar información del servidor sobre sí mismo. Es probable que Dropbox esté usando solo esa solicitud HTTP, o como máximo dos (una para autenticar, otra para enviar los datos).

  3. Además de esto, dependiendo del cliente que esté utilizando para las transferencias FTP (que no especifique, sería una buena idea editar su pregunta para incluir esa información), puede estar desconectando la conexión después de cada operación de envío y volviendo a conectarse. hora. No es improbable que DropBox mantenga una conexión abierta por un tiempo con fines de sondeo largo, para reaccionar tan pronto como sea posible a los nuevos datos disponibles que este cliente debe descargar, por lo que necesitará abrir un nuevo Conexión HTTP para enviar un archivo que no necesitará volver a autenticar.

  4. No es improbable que el cliente DropBox esté comprimiendo datos antes de enviarlos (para mejorar la velocidad y ahorrar ancho de banda) donde su cliente FTP no estará. Entonces, incluso para archivos más grandes (a menos que estén precomprimidos o encriptados) DropBox, y las utilidades similares, pueden ser más rápidas que una transferencia FTP básica por algún margen.

Para archivos grandes, los primeros tres puntos anteriores palidecerán en insignificancia en comparación con el tiempo necesario para transferir los datos, pero el punto 4 aún puede ser bastante importante. Para archivos pequeños, todo el tiempo de configuración adicional agregado por el protocolo FTP puede ser potencialmente un par de veces más largo que el tiempo necesario para enviar los datos.


+1 para la respuesta detallada. Yo también me había preguntado cómo Dropbox fue tan rápido.
Grant Palin

1
Leí en alguna parte que los datos de Dropbox están encriptados antes de la transferencia, por lo que tendría sentido que también estén comprimidos (al menos un poco).
Dean Rather

Un archivo encriptado no debe ser comprimible. De todos modos
Martin Beckett

@mgb: tiene razón en que las técnicas de compresión de archivos no deberían encontrar suficiente redundancia en los datos cifrados para ser útiles, por lo que inicialmente enviar un archivo no resultará en ayuda de la compresión. Pero si Dropbox ya tiene el archivo y lo acaba de actualizar (y la clave sigue siendo la misma), entonces es probable que no necesite transferir todo el archivo para actualizar la copia remota. Si bien los datos no se pueden comprimir, la cantidad que necesita enviar para mantenerlos actualizados aún se puede reducir (considerablemente para archivos grandes que ven pequeñas actualizaciones).
David Spillett

1
Estoy bastante seguro de que usan HTTPS para la transferencia (HTTP sobre SSL) en lugar de enviar datos en forma simple. No sé qué cifrado (si lo hay) se usa para el almacenamiento real, pero si sus datos son confidenciales, debería cifrarlos a su lado de todos modos, por lo que solo tiene una copia de las claves relevantes.
David Spillett

15

Como otros han mencionado, Dropbox puede omitir partes de archivos que no han cambiado . Pero también, Dropbox omitirá la carga de archivos si ya tiene una copia en el lado del servidor (una que usted o cualquier otra persona ya haya subido).

Entonces, si está intentando cargar un archivo que es idéntico a un archivo que Dropbox ya tiene, la carga se omite (y las otras máquinas vinculadas pueden comenzar a descargarlo desde los servidores de Dropbox). Si está cargando un archivo que es casi idéntico a otro archivo ya cargado (no está claro si el archivo ya cargado debe ser 'suyo' o ​​podría provenir de algún usuario), simplemente enviará suficientes partes del para recrearlo en el servidor cuando se combina con el archivo que ya se cargó.

FTP no puede hacer ninguna de estas cosas (es un protocolo simple para enviar y recibir flujos de datos sin referencia a ningún otro dato disponible en el extremo remoto). Las herramientas como rsync y Unison pueden "omitir fragmentos que el otro lado ya tiene", pero generalmente se limitan a comparar fragmentos dentro de archivos en una ruta idéntica en la jerarquía sincronizada. Dropbox parece extender esta idea a colecciones de archivos (por lo que si 'carga' dos archivos casi idénticos, presumiblemente podría hacer arreglos para enviar solo uno más suficiente 'diff' para volver a crear el otro).


11

Supongo que quieres decir más rápido en términos de transferencia de archivos. Cuando guarda un archivo en su carpeta de Dropbox, Dropbox solo envía el delta (o diff) de los datos al servidor de almacenamiento remoto. FTP (muy probablemente) envía el archivo byte a byte (en lugar de enviar los cambios), lo que potencialmente demora mucho más en transferirse a través de una red. Del mismo modo, al sincronizar desde el servidor remoto, los clientes locales descargarán solo los cambios.

La función de sincronización LAN también puede acelerar las sincronizaciones y reducir el tráfico de red necesario.


De hecho, estoy hablando de nuevos archivos para ambos casos.

0

Dropbox puede ser más rápido cuando envía una mayor cantidad de archivos. FTP es lo más rápido que puede obtener cuando hablamos de velocidad, pero se necesita demasiada "conversación" entre el servidor y la computadora del cliente para cada archivo, por lo que el ftp parece ser más lento. Si está cargando alguna aplicación de código abierto con miles de archivos, es más conveniente comprimir todos los archivos, cargarlos a través de FTP y descomprimirlos en el servidor.


0

Supongo que usan técnicas de hashing simples similares a md5 / sha

Cada vez que suelta un archivo dentro de "dropbox" local, dropbox-client calcula el hash de ese archivo y debe enviar algunos datos adicionales como tamaño de archivo, nombre de archivo al servidor de dropbox.

Si dropbox-server encuentra archivos similares (deben mantener un índice de hashes y datos de archivo en su servidor) , simplemente informará al cliente que el archivo se ha "cargado" con éxito. ;-)

De esta manera, terminas "cargando" el archivo lógicamente. Como no hay una transferencia real de contenido de archivos, esto tiene que ser más rápido que cualquier otra cosa.

No estoy seguro de qué algoritmo de hashing utiliza Dropbox, pero estoy 100% seguro de que su principio de funcionamiento es similar al que describí anteriormente.


0

Aunque Dropbox está utilizando otros servicios, históricamente han estado utilizando Amazon AWS (Amazon Web Services). Parece que su transferencia desde el origen al destino tiene una tubería de transferencia muy grande. En mi experiencia, Dropbox está utilizando un destino que puede aceptar grandes cantidades de datos a la vez. Dropbox también distribuye la carga a diferentes direcciones IP. El sitio al que está enviando FTP probablemente tenga una tubería de transferencia mucho más pequeña y no tenga la capacidad de distribuir cargas tan eficientemente.

Si ejecuta el Monitor de recursos (resmon) y va a la pestaña Red, notará los diferentes procesos que utilizan el ancho de banda de la red.

  • En Procesos con actividad de red, seleccione la columna para Total (B/sec)
  • En Conexiones TCP, seleccione la columna para Total (B/sec)

Para mí, cuando estoy cargando un archivo en Dropbox, está usando 4 conexiones para enviar 4 direcciones IP diferentes.

ingrese la descripción de la imagen aquí

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.