Как я могу убедиться, что файл размером 1 ТБ передан правильно?

Я часто передаю образы виртуальных машин с гипервизоров на архивный сервер для длительного хранения.

Я перевожу с помощью netcat, так как он быстрее, чем scp, rsync и т. Д.

hypervisor$ cat foo.box | nc <archive IP> 1234

archive$ nc -l -p 1234 > foo.box

Когда файл завершил передачу, я проверяю, что не было никакого повреждения, запустив md5sumи на цели и на источнике.

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

Обновить:

• Моя передача редко прерывается, поэтому перезапуск не является проблемой.
• Обычно для передачи через NC требуется 3-4 часа, а затем для получения md5sum - 40 минут.
• Безопасность хеша не является проблемой в этом случае.

Вы можете использовать tee для суммирования на лету с чем-то вроде этого (адаптируйте команды netcat для своих нужд):

Сервер:

netcat -l -w 2 1111 | tee >( md5sum > /dev/stderr )

Клиент:

tee >( md5sum > /dev/stderr ) | netcat 127.0.0.1 1111

Ответ Nerdwaller об использовании teeодновременной передачи и вычисления контрольной суммы является хорошим подходом, если вы в первую очередь беспокоитесь о коррупции в сети. Однако он не защитит вас от повреждения на пути к диску и т. Д., Поскольку он принимает контрольную сумму перед тем, как попасть на диск.

Но я бы хотел кое-что добавить:

1 ТиБ / 40 минут ≈ 437 МБ / с ¹ .

Это довольно быстро, на самом деле. Помните, что если у вас нет много оперативной памяти, это должно вернуться из хранилища. Поэтому первое, что нужно проверить, это посмотреть, iostat -kx 10как вы запускаете свои контрольные суммы; в частности вы хотите обратить внимание на %utilколонку. Если вы привязываете диски (около 100%), то ответ заключается в том, чтобы купить более быстрое хранилище.

В противном случае, как упоминалось в других постерах, вы можете попробовать разные алгоритмы контрольной суммы. MD4, MD5 и SHA-1 спроектированы как криптографические хеши (хотя ни один из них больше не должен использоваться для этой цели; все они считаются слишком слабыми). Скорость мудрая, вы можете сравнить их с openssl speed md4 md5 sha1 sha256. Я добавил в SHA256 хотя бы один достаточно сильный хеш.

The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
md4              61716.74k   195224.79k   455472.73k   695089.49k   820035.58k
md5              46317.99k   140508.39k   320853.42k   473215.66k   539563.35k
sha1             43397.21k   126598.91k   283775.15k   392279.04k   473153.54k
sha256           33677.99k    75638.81k   128904.87k   155874.91k   167774.89k

Из вышесказанного видно, что MD4 самый быстрый, а SHA256 самый медленный. По крайней мере, этот результат типичен для ПК-подобного оборудования.

Если вы хотите еще большей производительности (за счет тривиального вмешательства, а также с меньшей вероятностью обнаружения коррупции), вам нужно взглянуть на хэш CRC или Adler. Адлер, как правило, быстрее, но слабее. К сожалению, я не знаю каких-либо действительно быстрых реализаций командной строки; все программы в моей системе работают медленнее, чем md4 в OpenSSL.

Таким образом, ваша лучшая ставка по скорости openssl md4 -r( -rэто выглядит как вывод md5sum).

Если вы хотите выполнить некоторую компиляцию и / или минимальное программирование, посмотрите код Марка Адлера в Stack Overflow, а также xxhash . Если у вас SSE 4.2, вы не сможете побить скорость аппаратной инструкции CRC.

¹¹ TiB = 1024 байта; 1 МиБ = 1024² байт. Достигается до ≈417 МБ / с при энергопотреблении 1000 единиц.

Команда opensslподдерживает несколько дайджестов сообщений. Из тех, которые я смог попробовать, md4кажется, работает примерно в 65% времени md5и примерно в 54% времени sha1(для одного файла, с которым я тестировал).

Там также есть md2в документации, но, похоже, дает те же результаты, что и md5.

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

Вы могли бы посмотреть на старые и более простые дайджесты сообщений (был ли md1, например)?

Незначительный момент: у вас бесполезное использованиеcat . Скорее, чем:

cat foo.box | nc <archive IP> 1234

вы можете использовать:

nc <archive IP> 1234 < foo.box

или даже:

< foo.box nc <archive IP> 1234

Это экономит процесс, но, вероятно, не окажет существенного влияния на производительность.

Два варианта:

использование sha1sum

sha1sum foo.box

В некоторых случаях sha1sum быстрее .

использование rsync

Передача займет больше времени, но rsync проверяет, что файл прибыл без изменений.

Со страницы руководства rsync

Обратите внимание, что rsync всегда проверяет, что каждый переданный файл был правильно восстановлен на принимающей стороне, проверяя контрольную сумму всего файла, которая генерируется при передаче файла ...

Наука прогрессирует. Похоже, что новая хеш-функция BLAKE2 работает быстрее, чем MD5 (и криптографически намного сильнее для загрузки).

Ссылка: https://leastauthority.com/blog/BLAKE2-harder-better-faster-stronger-than-MD5.html

Из слайдов Зуко:

циклов на байт в Intel Core i5-3210M (Ivy Bridge) 

функциональных циклов на байт

          длинные сообщения 4096 B 64 B
MD5 5.0 5.2 13.1
SHA1 4,7 4,8 13,7
SHA256 12,8 13,0 30,0
Keccak 8.2 8.5 26.0
BLAKE1 5,8 6,0 14,9
BLAKE2 3,5 3,5 9,3

Вы, вероятно, не можете сделать ничего лучше, чем хороший хэш. Возможно, вы захотите проверить другие функции хэш / контрольной суммы, чтобы увидеть, являются ли какие-либо значительно быстрее, чем md5sum. Обратите внимание, что вам может не понадобиться что-то столь же сильное, как MD5. MD5 (и такие вещи, как SHA1) предназначены для криптографической защиты, поэтому злоумышленнику / самозванцу невозможно создать новый файл, который имеет такое же значение хеш-функции, что и существующее значение (т. Е. Усложнить подделку со знаком e -почта и другие документы). Если вас не беспокоит атака на ваши коммуникации, а только обычная ошибка связи, может быть достаточно что-то вроде проверки циклическим избыточным кодом (CRC). (Но я не знаю, будет ли это быстрее.)

Другой подход - попытаться сделать хеш параллельно с передачей. Это может сократить общее время и определенно уменьшить фактор раздражения, связанный с необходимостью ждать окончания передачи, а затем снова ждать завершения MD5. Я не проверял это, но должно быть возможно сделать что-то вроде этого:

• На исходном компьютере:

  mkfifo myfifo
  тройник myfifo < исходный_файл | н.д. dest_host  номер_порта & md5sum myfifo
  

• На машине назначения:

  mkfifo myfifo
  nc -l -p номер_порта | tee myfifo> dest_file & md5sum myfifo
  

Конечно, проверка размеров файлов - это хороший и быстрый способ определить, были ли сброшены какие-либо байты.

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

Вы также можете настроить персональную сеть BitTorrent. Это гарантировало бы, что все это безопасно.