Каков самый быстрый способ передачи файлов по сети (FTP, HTTP, RSync и т.д.).

Ответ 1

Хорошо, поэтому я настраиваю следующий тест:

• Оборудование: 2 рабочих стола Intel Core Duo CPU @2,33 ГГц, с 4 ГБ оперативной памяти.
• ОС: Ubuntu 11.10 на обеих машинах
• Сеть: выделенный коммутатор 100Mb, к которому подключаются обе машины.
• Программное обеспечение:
  • HTTP-сервер Python (вдохновленный этим).
  • FTP-сервер Python (вдохновленный этим).
  • HTTP-клиент Python (вдохновленный этим).
  • FTP-клиент Python (вдохновленный этим).

Я загрузил следующие группы файлов на каждый сервер:

• 1 100M файл.
• 10 10M файлов.
• 100 1M файлов.
• 1,000 100K файлов.
• 10 000 файлов 10K.

Я получил следующие средние результаты по нескольким прогонам (числа в секундах):

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

Итак, кажется, что FTP в нескольких файлах немного быстрее, а HTTP во многих небольших файлах немного быстрее. В целом, я думаю, что они сопоставимы, а реализация сервера намного важнее протокола.

Ответ 2

Если машины на каждом конце достаточно мощные (т.е. не нетбуки, NAS-боксы, тостеры и т.д.), я бы ожидал, что все протоколы, которые работают над TCP, будут иметь одинаковую скорость при передаче массивных данных. Задание протокола приложения действительно просто для заполнения буфера для передачи TCP, поэтому, пока они могут поддерживать его, TCP будет устанавливать темп.

Протоколы, которые выполняют сжатие или шифрование, могут быть узким местом в процессоре на менее мощных машинах. Мой нетбук делает FTP намного быстрее, чем SCP.

rsync делает умные вещи, чтобы быстро передавать инкрементные изменения, но для массовых передач он не имеет преимуществ по сравнению с протоколами Dumber.

Ответ 3

Еще одна полезная задача - bbcp: http://www.slac.stanford.edu/~abh/bbcp/.

Хороший, но устаревший учебник по его использованию находится здесь: http://pcbunn.cithep.caltech.edu/bbcp/using_bbcp.htm. Я обнаружил, что bbcp очень хорошо переносит большие файлы (несколько GB). По моему опыту, он быстрее, чем rsync в среднем.

Ответ 4

rsync произвольно сжимает свои данные. Это обычно делает передачу намного быстрее. См. rsync -z.

Вы не указали scp, но scp -C также сжимается.

Обратите внимание, что сжатие может привести к тому, что передача будет выполняться быстрее или медленнее, в зависимости от скорости вашего процессора и вашей сетевой ссылки. (Более медленные ссылки и более быстрый процессор делают сжатие хорошей идеей, более быстрые ссылки и более медленный процессор делают сжатие плохими.) Как и при любой оптимизации, измерьте результаты в своей собственной среде.

Ответ 5

Я боюсь, если вы хотите узнать ответ для своих нужд и настройки, вам либо нужно быть более конкретным, либо выполнять свои собственные тесты производительности (и надежности). Это помогает иметь хотя бы рудиментарное понимание рассматриваемых протоколов и их общение, поэтому я бы рассмотрел статьи, которые вы цитировали полезный ресурс. Это также помогает узнать, с какими ограничениями сталкиваются ранние изобретатели этих протоколов, была ли их цель поддерживать низкий уровень сетевого воздействия, были ли они голодны в памяти или им приходилось подсчитывать свои циклы процессора? Вот несколько вещей, чтобы рассмотреть или ответить, если вы хотите получить ответ, адаптированный к вашей ситуации:

• ОС/файловая система:
  • Вы копируете между одной и той же комбинацией OS/FS или вам приходится беспокоиться о несовместимости, например, о типах файлов, не имеющих эквивалента на принимающей стороне?
  • т.е. у вас есть что-то особенное для перевозки? Метаданные, вики-источники, расширенные атрибуты, разрешения на доступ к файлам могут быть либо просто не транспортированы по протоколу/инструменту по вашему выбору, либо быть бессмысленными на принимающей стороне.
  • То же самое относится к разреженным файлам, которые могут быть раздуты до полного размера на другом конце копии, разрушая все планы, которые вы, возможно, имели о калибровке.
• Связанные физические ограничения:
  • Влияние сети
  • загрузка cpu: в настоящее время сжатие намного "дешевле", поскольку современные процессоры менее подвержены компрессии, чем те, которые были в то время, когда были разработаны большинство протоколов передачи.
  • отказоустойчивость - вам нужно убирать, где прерванный перевод оставил вас, или вы предпочитаете начинать заново?
  • дополнительные переводы или полные переводы? Предоставляет ли инкрементная передача какие-либо большие сбережения для вас, или у вас есть полные переводы по дизайну вашей задачи? В последнем случае добавленная латентность и влияние памяти для создания списка переноса до начала передачи были бы менее желательным компромиссом.
  • Насколько хорош протокол при использовании MTU, доступного по вашему базовому сетевому протоколу?
  • Нужно ли поддерживать постоянный поток данных, например, чтобы поток ленточного накопителя передавался на приемной стороне?

Множество вещей, которые нужно учитывать, и я уверен, что листинг не завершен.