Быстрый способ скопировать большой файл в локальной сети

У меня проблемы с NFS, и я хотел бы попробовать использовать простой старый TCP.

Однако я не знаю, с чего начать.

Аппаратно, я использую Ethernet-кроссовер для подключения двух нетбуков.

Чтобы связать их, я печатаю

$ sudo ifconfig eth0 192.168.1.1 up && ping -c 10 -s 10 192.168.1.2 && sudo /etc/init.d/nfs-kernel-server start 

на первом нетбуке и

 $ sudo ifconfig eth0 192.168.1.2 up $ ping -c 10 -s 10 192.168.1.1 $ mount /mnt/network1 

На втором

где /mnt/network1 указано в / etc / fstab как

192.168.1.1:/home /mnt/network1 nfs noauto,user,exec,soft,nfsvers=2 0 0

а также в /etc/exports (используя синтаксис этого файла), на первом нетбуке.

Вышеописанное работает отлично, но файлы и каталоги огромны. Файлы в среднем составляют около половины гигабайта, а каталоги – от 15 до 50 гигабайт.

Я использую rsync для их передачи, а команда (по 192.168.1.2 )

 $ rsync -avxS /mnt/network1 ~/somedir 

Я не уверен, есть ли способ настроить мои настройки NFS для обработки огромных файлов лучше, но я хотел бы посмотреть, работает ли демон rsync поверх обычного старого TCP лучше, чем rsync через NFS.

Итак, чтобы повторить, как настроить аналогичную сеть с TCP?

ОБНОВИТЬ:

Итак, после нескольких часов работы, пытаясь вытащить себя из болота моего собственного невежества (или, как мне нравится думать об этом, чтобы подтянуться к моим собственным бутстрапам), я придумал некоторые полезные факты.

Но прежде всего, что привело меня к этой тропе кролика вместо того, чтобы просто принять текущий лучший ответ, было так: nc – невероятно крутая программа, которая решительно не работает для меня. Я пробовал netcat-openbsd и netcat-traditional пакеты без всякой удачи.

Ошибка, которую я получаю на принимающей машине ( 192.168.1.2 ):

 me@netbook:~$ nc -q 1 -l -p 32934 | tar xv Can't grab 0.0.0.0:32934 with bind tar: This does not look like a tar archive tar: Exiting with failure status due to previous errors 

route дает:

 me@netbook:~$ route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface default dir-615 0.0.0.0 UG 0 0 0 wlan0 link-local * 255.255.0.0 U 1000 0 0 eth0 192.168.0.0 * 255.255.255.0 U 2 0 0 wlan0 192.168.1.0 * 255.255.255.0 U 0 0 0 eth0 

Но вот хорошая новость: наличие статических IP-адресов, установленных в /etc/network/interfaces , которые я начал делать, пытаясь заставить nc работать, устранить все мои проблемы с NFS и возродить мою любовь к NFS.

Точная конфигурация, которую я использовал (с 192.168.1.1 для первого нетбука, конечно), была:

 auto eth0 iface eth0 inet static address 192.168.1.2 netmask 255.255.255.0 

С этими настройками два нетбука смогут пинговать друг друга сразу после загрузки, даже без ifup .

Во всяком случае, мне все равно очень хотелось бы видеть nc в действии, поэтому я надеюсь, что кто-то поможет мне отладить этот процесс.

3 Solutions collect form web for “Быстрый способ скопировать большой файл в локальной сети”

Быстрый способ

Самый быстрый способ передачи файлов по локальной сети, скорее всего, не rsync, если только не будет изменений. rsync тратит справедливое время на выполнение контрольных сумм, вычисляет различия и т. д. Если вы знаете, что в любом случае вы будете передавать большую часть данных, просто сделайте что-нибудь подобное (обратите внимание: существует несколько реализаций netcat ; для правильных параметров. В частности, ваш может не хотеть -p ):

 user@dest:/target$ nc -q 1 -l -p 1234 | tar xv user@source:/source$ tar cv . | nc -q 1 dest-ip 1234 

Это использует netcat ( nc ) для отправки tar поверх необработанного TCP-соединения на порту 1234. Нет шифрования, проверки подлинности и т. Д., Поэтому его очень быстро. Если ваш кросс-коннектор работает на гигабите или меньше, вы привязаете сеть; если его больше, вы привяжете диск (если у вас нет массива хранения или быстрого диска). v флаги для tar позволяют распечатывать имена файлов по своему усмотрению (подробный режим). С большими файлами это практически не накладные расходы. Если бы вы делали тонны небольших файлов, вы бы отключили это. Кроме того, вы можете вставить что-то вроде pv в конвейер, чтобы получить индикатор прогресса:

 user@dest:/target$ nc -q 1 -l -p 1234 | pv -pterb -s 100G | tar xv 

Вы можете, конечно, вставить и другие вещи, например gzip -1 (и добавить флаг z в принимающий конец – флаг z на стороне отправки будет использовать более высокий уровень сжатия, чем 1, если вы не установите переменную окружения GZIP, конечно ). Хотя gzip, вероятно, будет на самом деле медленнее, если ваши данные действительно не сжимаются.

Если вам действительно нужен rsync

Если вы действительно переносите небольшую часть данных, которые изменились, rsync может быть быстрее. Вы также можете посмотреть на параметр -W / – --whole-file , как на очень быструю сеть (например, кросс-коннект), которая может быть быстрее.

Самый простой способ запустить rsync – через ssh. Вы хотите поэкспериментировать с ssh-шифрами, чтобы узнать, какой из них самый быстрый, это будут AES, ChaCha20 или Blowfish (хотя есть некоторые проблемы с безопасностью с размером бит-битов Blowfish), в зависимости от того, имеет ли ваш чип AES от Intel -NI (и ваш OpenSSL использует их). На новом достаточно ssh rsync-over-ssh выглядит так:

 user@source:~$ rsync -e 'ssh -c aes128-gcm@openssh.com' -avP /source/ user@dest-ip:/target 

Для старшего ssh / sshd попробуйте aes128-ctr или aes128-cbc вместо aes128-gcm@openssh.com .

ChaCha20 будет chacha20-poly1305@openssh.com (также нужен новый достаточно ssh / sshd), а Blowfish – blowfish-cbc. OpenSSH не позволяет работать без шифрования. Вы можете, конечно, использовать любые параметры rsync, которые вам нравятся вместо -avP . И, конечно же, вы можете пойти в другом направлении и запустить rsync с машины назначения (pull) вместо исходной машины (push).

Повышение скорости rsync

Если вы запустите демон rsync, вы можете избавиться от накладных расходов crypto. Во-первых, вы создадите файл конфигурации демона ( /etc/rsyncd.conf ), например, на исходном компьютере (подробнее см. Man-страницу rsyncd.conf):

 [big-archive] path = /source read only = yes uid = someuser gid = somegroup 

Затем на машине назначения вы должны запустить:

 user@dest:~$ rsync -avP source-ip::big-archive/ /target 

Вы можете сделать это и наоборот (но, конечно, вам нужно установить только чтение). Существуют варианты проверки подлинности и т. Д., Проверьте man-страницу для деталей.

Как? Или TL; DR

Самый быстрый метод, который я нашел, представляет собой комбинацию tar , mbuffer и ssh .

Например:

 tar zcf - bigfile.m4p | mbuffer -s 1K -m 512 | ssh otherhost "tar zxf -" 

Используя это, я добился устойчивой передачи локальной сети более 950 Мбит / с на 1Gb-ссылках. Замените пути в каждой команде tar, чтобы они соответствовали тому, что вы передаете.

Зачем? mbuffer!

Крупнейшим узким местом в передаче больших файлов по сети является, безусловно, дисковый ввод-вывод. Ответ на это – mbuffer или buffer . Они во многом похожи, но у mbuffer есть некоторые преимущества. Размер буфера по умолчанию – 2 МБ для mbuffer и 1 МБ для buffer . Более крупные буферы, скорее всего, никогда не будут пустыми. Выбор размера блока, который является самым низким общим кратным размера собственного блока как целевой, так и целевой файловой системы, даст лучшую производительность.

Буферизация – это то, что делает всю разницу! Используйте его, если он у вас есть! Если у вас его нет, получите его! Использование (m}?buffer plus ничего лучше, чем что-либо само по себе. Это почти буквально панацея для медленной передачи сетевых файлов.

Если вы переносите несколько файлов, используйте tar чтобы «объединить» их вместе в один поток данных. Если это один файл, вы можете использовать перенаправление cat или I / O. Накладные расходы на tar и cat статистически незначимы, поэтому я всегда использую tar (или zfs -send где могу), если только он не является tarball . Ни один из них не гарантирует вам метаданные (и, в частности, cat не будет). Если вы хотите метаданные, я оставлю это как упражнение для вас.

Наконец, использование ssh для транспортного механизма является безопасным и несет очень незначительные накладные расходы. Опять же, накладные расходы ssh против nc статистически незначимы.

Вам даже не нужно использовать TCP. AoE – это реализация ATA по Ethernet, являющаяся уровнем 2, это подход с более низкими затратами, без знания стека TCP / IP. Это обеспечит вам самую быструю передачу с наименьшими издержками. ***

https://en.wikipedia.org/wiki/ATA_over_Ethernet

*** Если сеть является узким местом, убедитесь, что вы отправляете сжатые данные.

  • Ошибка: «TCP_NODELAY» не был объявлен в этой области
  • Какие порты будут использовать ssh-демон?
  • Как узнать имя процесса, которое открывает порт tcp?
  • как подключить ssh 'с указанным портом?
  • vnc через назначение порта ssh
  • Перенаправить stdin и stdout в порты
  • что такое спецификация формата для `ss -D`?
  • Как обеспечить, чтобы исходящий трафик TCP / IP всегда использовал VPN, даже при использовании Wi-Fi?
  • Инструмент для генерации трафика TCP
  • Почему у меня установлены TCP-соединения без PID владельца?
  • Доступна реализация TCP Westwood?
  • Linux и Unix - лучшая ОС в мире.