Як я можу переконатися, що файл 1 ТБ переданий правильно?

Я часто передаю VM-зображення від гіпервізорів на сервер архіву для тривалого зберігання.

Я передаю за допомогою netcat, оскільки це швидше, ніж scp, rsync, ect ..

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

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

Коли файл закінчує передачу, я переконуюсь, що не було пошкоджень, запускаючи md5sumі цільовий, і джерело.

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

Оновлення:

• Моя передача рідко переривається, тому можливість перезапуску не є проблемою.
• Як правило, потрібно тривати 3-4 години для передачі через NC, а потім 40 хвилин, щоб отримати md5sum.
• Безпека хешу не є проблемою в цьому випадку.

Ви можете використовувати трійник, щоб зробити суму на льоту таким чином (адаптуйте команди netcat під свої потреби):

Сервер:

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

Клієнт:

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

Відповідь Нердваллера про використання teeодночасно для передачі та обчислення контрольної суми є хорошим підходом, якщо ви в першу чергу переживаєте за корупцію в мережі. Це не захистить вас від корупції на шляху до диска тощо, хоча його приймають контрольну суму до того, як вона потрапить на диск.

Але я хотів би додати щось:

1 TiB / 40 хвилин ≈ 437 MiB / сек ¹ .

Це дуже швидко, насправді. Пам’ятайте, що якщо у вас багато оперативної пам’яті, це повертається зі сховища даних. Тому перше, що потрібно перевірити, - це спостерігати 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 або Адлера. З двох, Адлер, як правило, швидший, але слабший. На жаль, я не знаю жодної реально швидкої реалізації командного рядка; програми в моїй системі все повільніше, ніж md4 OpenSSL.

Таким чином, ваш кращий вибір швидкості мудрий openssl md4 -r( -rробить його схожим на вихід md5sum).

Якщо ви готові виконати компіляцію та / або мінімальне програмування, перегляньте код Марка Адлера на Stack Overflow, а також xxhash . Якщо у вас SSE 4.2, ви не зможете перемогти швидкість інструкції щодо апаратної CRC.

¹ 1 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 перевіряє, що файл прибув недоторканим.

З сторінки man rsync

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

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

Довідка: https://leastauthority.com/blog/BLAKE2-harder-better-faster-stronger-than-MD5.html

З слайдів Zooko:

циклів на байт на 

функціональних циклах Intel Core i5-3210M (Ivy Bridge) на байт

          довгі мсг 4096 Б 64 В
MD5 5.0 5.2 13.1
SHA1 4,7 4,8 13,7
SHA256 12,8 13,0 30,0
Кекак 8,2 8,5 26,0
BLAKE1 5,8 6,0 14,9
BLAKE2 3,5 3,5 9,3

Ви, мабуть, не можете зробити краще, ніж хороший хеш. Ви можете перевірити інші функції хеш-контрольної суми, щоб побачити, чи є якісь значно швидшими, ніж md5sum. Зауважте, що вам може не знадобитися щось таке міцне, як MD5. MD5 (і такі речі, як SHA1) розроблені таким чином, щоб бути криптографічно сильними, тому зловмисник / самозванець може не створити новий файл, який має те саме хеш-значення, як і існуюче значення (тобто, щоб важко підробляти підписані е -пошти та інші документи). Якщо вас не турбує атака на ваші комунікації, а лише помилка запуску верстатів, щось на зразок циклічної перевірки надмірності (CRC) може бути досить хорошою. (Але я не знаю, чи буде це швидше.)

Інший підхід - спробувати зробити хеш паралельно з передачею. Це може скоротити загальний час і, безумовно, може зменшити коефіцієнт роздратування необхідності чекати закінчення передачі, а потім знову чекати, коли MD5 закінчиться. Я цього не перевіряв, але слід зробити щось подібне:

• На вихідній машині:

  mkfifo myfifo
  tee myfifo < source_file | н.д. dest_host  номер_порту & md5sum myfifo
  

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

  mkfifo myfifo
  nc -l -p port_number | tee myfifo> dest_file & md5sum myfifo
  

Звичайно перевірка розмірів файлів - це хороший, швидкий спосіб виявити, чи потрапили будь-які байти.

Надсилання величезних файлів - це біль. Чому б не спробувати з’єднати файли, що генерують хеш для кожного фрагменту, а потім надіслати його до пункту призначення, а потім перевірити хеш і з'єднати шматки.

Ви також можете створити персональну мережу BitTorrent. Це забезпечило б безпечне досягнення всієї справи.