¿Por qué crees que usar TCP hace que la transferencia sea más lenta? TCP generalmente puede usar todo el ancho de banda disponible. No es probable que usar UDP sea más rápido. De hecho, si intentara realizar una transferencia de archivos confiable basada en UDP, probablemente terminaría implementando una alternativa inferior a TCP, ya que usted mismo tendría que implementar la confiabilidad.
Qué es problemático de FTP es que realiza varios comandos de respuesta de solicitud de sincronismo para cada archivo a transferir, y se abre una nueva conexión de datos para cada archivo. Esto resulta en transferencias extremadamente ineficientes cuando se transfieren muchos archivos más pequeños, porque la mayor parte del tiempo se usa para esperar solicitudes/respuestas y establecer conexiones de datos en lugar de transferir datos.
Una forma simple de evitar este problema es empacar los archivos/carpetas en un archivo. Si bien puede, por supuesto, hacer el archivo, enviarlo usando FTP o similar, y descomprimirlo en el otro lado, el tiempo de embalaje y desempaquetado puede ser inaceptable. Puede evitar este retraso haciendo el embalaje y desempacando en línea. No conozco ningún software que integre un embalaje/desembalaje en línea. Puede, sin embargo, sólo tiene que utilizar los programas nc y tar en una tubería (Linux, en Windows utilizar Cygwin):
Primera corrida en el receptor:
nc -l -p 7000 | tar x -C <destination_folder>
Esto hará que el receptor espera para una conexión en el puerto número 7000. a continuación, ejecute en el remitente:
cd /some/folder
tar c ./* | nc -q0 <ip_address_of_receiver>:7000
Esto hará que el emisor se conectan al receptor, a partir de la transferencia. El remitente creará el archivo tar, enviándolo al receptor, que lo extraerá, todo al mismo tiempo. Si lo necesita, puede revertir los roles del remitente y el receptor (haciendo que el receptor se conecte con el remitente).
Este enfoque de alquitrán en línea no tiene ninguno de los dos problemas de rendimiento de FTP; no ejecuta ningún comando de solicitud-respuesta, y usa solo una sola conexión TCP.
Sin embargo, tenga en cuenta que esto no es seguro; cualquiera puede conectarse al receptor antes de que lo haga nuestro remitente, enviarle su propio archivo tar. Si esto es un problema, se puede usar una VPN, en combinación con las reglas de firewall apropiadas.
EDIT: mencionó la pérdida de paquetes como un problema con el rendimiento de TCP, que es un problema importante, si se cree que la página FileCatalyst.Es cierto que TCP puede funcionar de forma no óptima con enlaces de pérdida de paquetes altos. Esto se debe a que el TCP generalmente reacciona agresivamente a la pérdida de paquetes, porque asume que la pérdida se debe a la congestión; ver Additive_increase/multiplicative_decrease. No conozco ningún programa de transferencia de archivos de código abierto/libre que intente superar esto con protocolos personalizados. Sin embargo, puede probar diferentes TCP congestion avoidance algorithms. En particular, intente con Vegas, que hace no use la pérdida de paquetes como una señal para reducir la velocidad de transmisión.
¿Revisaste los enlaces que incluí? Si tiene un archivo de 500 GB para transferir, las conexiones de control de FTP son completamente insignificantes, y lo que termina con el rendimiento TCP sin procesar. Lo cual no necesariamente está ajustado para una transferencia lo más rápida posible de archivos de gran tamaño, en particular no a través de enlaces con pérdida de paquetes. Los productos en los enlaces que incluí DO implementan la fiabilidad ellos mismos, obviamente. – stolsvik
@stolsvik no ha mencionado enlaces de alta pérdida, que AFAIK son raros en Internet. He agregado algo sobre eso. –
En realidad, el protocolo TCP en realidad no está diseñado para la transferencia de un solo sentido. Claro que se puede hacer para hacerlo, pero TCP requiere paquetes de devolución de tal manera que provoque paradas breves y puede ser un acto de equilibrio elegir tamaños de buffer y tamaños de ventana para una velocidad verdaderamente óptima. Además, las implementaciones pueden no hacer siempre lo que realmente se supone que deben hacer con varias configuraciones opcionales. –