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

Question

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

Я перевожу с помощью 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 минут.
• Безопасность хеша не является проблемой в этом случае.

Answer 1

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

Сервер:

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

Клиент:

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

Answer 2

Ответ 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 единиц.

Answer 3

Команда 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

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

Answer 4

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

Используйте sha1sum

sha1sum foo.box

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

---

Используйте rsync

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

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

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

Answer 5

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

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

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

cycles per byte on Intel Core i5-3210M (Ivy Bridge)

function      cycles per byte

          long msg  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

Answer 6

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

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

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

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

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

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

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

Answer 7

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

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