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

Вы можете использовать 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

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

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

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

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

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

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

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

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

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