Почему, по вашему мнению, использование TCP замедляет передачу? TCP обычно может использовать всю доступную пропускную способность. Использование UDP вместо этого вряд ли будет быстрее. На самом деле, если вы попытаетесь сделать надежную передачу файлов на основе UDP, вы, скорее всего, в конечном итоге внедрите более низкую альтернативу TCP - поскольку вам придется реализовать надежность самостоятельно.
* * * * * * * * * * * * * * * * * * * * * * * * * * * * проблема с FTP заключается в том, что он выполняет несколько синхронных команд запрос-ответ для каждого передаваемого файла и открывает новое подключение для передачи данных для каждого файла. Это приводит к крайне неэффективной передаче, когда передается много файлов меньшего размера, потому что большая часть времени тратится на ожидание запросов / ответов и установление соединений с данными вместо фактической передачи данных.
Простой способ обойти эту проблему - упаковать файлы / папки в архив. Хотя вы, конечно, можете просто сделать архив, отправить его по FTP или аналогичному устройству и распаковать его на другой стороне, время, потраченное на упаковку и распаковку, может быть неприемлемым. Вы можете избежать этой задержки, выполнив упаковку и распаковку онлайн. Я не знаю ни о каком программном обеспечении, которое объединяет такую онлайн упаковку / распаковку. Однако вы можете просто использовать программы nc и tar в конвейере (Linux, в Windows используется Cygwin ):
Первый запуск на приемнике:
nc -l -p 7000 | tar x -C <destination_folder>
Это заставит получателя ждать соединения на порту с номером 7000. Затем запустите на отправителе:
cd /some/folder
tar c ./* | nc -q0 <ip_address_of_receiver>:7000
Это заставит отправителя подключиться к получателю, начав передачу. Отправитель создаст архив tar, отправит его получателю, который будет извлекать его - и все это одновременно. При необходимости вы можете поменять роли отправителя и получателя (подключив получателя к отправителю).
В этом подходе онлайн-tar нет ни одной из двух проблем производительности FTP; он не выполняет никаких команд запрос-ответ и использует только одно TCP-соединение.
Однако учтите, что это небезопасно; любой может подключиться к получателю до того, как наш отправитель отправит ему свой собственный архив tar. Если это проблема, можно использовать VPN в сочетании с соответствующими правилами брандмауэра.
EDIT : вы упомянули потерю пакетов как проблему с производительностью TCP, что является серьезной проблемой, если верить странице FileCatalyst . Это правда, что TCP может работать неоптимально с высокими потерями пакетов. Это связано с тем, что TCP обычно агрессивно реагирует на потерю пакетов, поскольку предполагает, что потеря вызвана перегрузкой; см. Additive_increase / multiplicative_decrease . Я не знаю ни одной бесплатной программы с открытым исходным кодом для передачи файлов, которая пыталась бы преодолеть это с помощью пользовательских протоколов. Однако вы можете попробовать другие алгоритмы предотвращения перегрузки TCP . В частности, попробуйте Vegas , который не использует потерю пакетов в качестве сигнала для снижения скорости передачи.