Làm cách nào để xác minh rằng tệp 1TB được chuyển chính xác?

Tôi thường xuyên chuyển hình ảnh VM từ máy ảo hóa sang máy chủ lưu trữ để lưu trữ lâu dài.

Tôi chuyển bằng netcat vì nó nhanh hơn scp, rsync, ect ..

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

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

Khi tệp đã chuyển xong, tôi xác minh không có tham nhũng bằng cách chạy md5sumtrên cả mục tiêu và nguồn.

Thật không may, chạy md5sum trên một tệp lớn có thể mất nhiều thời gian. Làm thế nào tôi có thể nhanh chóng so sánh tính toàn vẹn của hai tệp lớn?

Cập nhật:

• Việc truyền của tôi hiếm khi bị gián đoạn vì vậy khả năng khởi động lại không phải là vấn đề.
• Thông thường phải mất 3-4 giờ để chuyển qua NC và sau đó 40 phút để có được md5sum.
• Bảo mật của hàm băm không phải là một vấn đề trong trường hợp này.

Bạn có thể sử dụng tee để thực hiện tổng số một cách nhanh chóng với điều này (điều chỉnh các lệnh netcat cho nhu cầu của bạn):

Máy chủ:

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

Khách hàng:

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

Câu trả lời của Nerdwaller về việc sử dụng teeđể chuyển đồng thời và tính toán tổng kiểm tra là một cách tiếp cận tốt nếu bạn chủ yếu lo lắng về tham nhũng qua mạng. Tuy nhiên, điều đó sẽ không bảo vệ bạn chống lại tham nhũng trên đường vào đĩa, v.v., vì nó sẽ kiểm tra trước khi nó chạm vào đĩa.

Nhưng tôi muốn thêm một cái gì đó:

1 TiB / 40 phút ≈ 437 MiB / giây ¹ .

Điều đó khá nhanh, thực sự. Hãy nhớ rằng trừ khi bạn có nhiều RAM, điều đó phải quay trở lại từ bộ lưu trữ. Vì vậy, điều đầu tiên để kiểm tra là xem iostat -kx 10khi bạn chạy tổng kiểm tra; đặc biệt bạn muốn chú ý đến %utilcột. Nếu bạn đang chốt các đĩa (gần 100%), thì câu trả lời là mua dung lượng nhanh hơn.

Mặt khác, như các áp phích khác đã đề cập, bạn có thể thử các thuật toán tổng kiểm tra khác nhau. MD4, MD5 và SHA-1 đều được thiết kế để băm mật mã (mặc dù không nên sử dụng chúng cho mục đích đó nữa; tất cả đều được coi là quá yếu). Tốc độ khôn ngoan, bạn có thể so sánh chúng với openssl speed md4 md5 sha1 sha256. Tôi đã ném vào SHA256 để có ít nhất một hàm băm đủ mạnh.

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

Trong số trên, bạn có thể thấy MD4 là nhanh nhất và SHA256 chậm nhất. Kết quả này là điển hình trên phần cứng giống như PC, ít nhất.

Nếu bạn muốn hiệu suất cao hơn nữa (với chi phí tầm thường để giả mạo và cũng ít có khả năng phát hiện tham nhũng), bạn muốn xem xét hàm băm CRC hoặc Adler. Trong hai, Adler thường nhanh hơn, nhưng yếu hơn. Thật không may, tôi không biết về bất kỳ triển khai dòng lệnh nào thực sự nhanh; tất cả các chương trình trên hệ thống của tôi đều chậm hơn so với md4 của OpenSSL.

Vì vậy, tốc độ đặt cược tốt nhất của bạn là khôn ngoan openssl md4 -r( -rlàm cho nó trông giống như đầu ra md5sum).

Nếu bạn sẵn sàng thực hiện một số chương trình biên dịch và / hoặc tối thiểu, hãy xem mã của Mark Adler trên Stack Overflow và cả xxhash . Nếu bạn có SSE 4.2, bạn sẽ không thể đánh bại tốc độ của lệnh CRC phần cứng.

¹ 1 TiB = 1024⁴ byte; 1 MiB = 1024² byte. Có tốc độ ≈417MB / giây với công suất 1000 đơn vị.

Các openssllệnh hỗ trợ một số tiêu hóa tin nhắn. Trong số những cái tôi có thể thử, md4dường như chạy trong khoảng 65% thời gian md5và khoảng 54% thời gian sha1(đối với một tệp tôi đã thử nghiệm).

Cũng có một md2tài liệu, nhưng nó dường như cho kết quả tương tự md5.

Rất đại khái, tốc độ dường như có liên quan nghịch đảo đến chất lượng, nhưng vì bạn (có lẽ) không quan tâm đến một kẻ thù tạo ra một vụ va chạm có chủ ý, nên điều đó không thành vấn đề.

Bạn có thể nhìn xung quanh để tìm thông báo cũ hơn và đơn giản hơn ( md1ví dụ như có)?

Một điểm nhỏ: Bạn đã sử dụng vô dụngcat . Thay vì:

cat foo.box | nc <archive IP> 1234

bạn có thể dùng:

nc <archive IP> 1234 < foo.box

hoặc thậm chí:

< foo.box nc <archive IP> 1234

Làm như vậy sẽ tiết kiệm một quy trình, nhưng có lẽ sẽ không có bất kỳ ảnh hưởng đáng kể nào đến hiệu suất.

Hai lựa chọn:

Sử dụng sha1sum

sha1sum foo.box

Trong một số trường hợp, sha1sum nhanh hơn .

Sử dụng rsync

Sẽ mất nhiều thời gian hơn để chuyển, nhưng rsync xác minh rằng tệp đến nguyên vẹn.

Từ trang người đàn ông rsync

Lưu ý rằng rsync luôn xác minh rằng mỗi tệp được truyền đã được xây dựng lại chính xác ở phía bên nhận bằng cách kiểm tra tổng kiểm tra toàn bộ tệp được tạo khi tệp được truyền ...

Khoa học đang tiến bộ. Có vẻ như hàm băm BLAKE2 mới nhanh hơn MD5 (và mã hóa mạnh hơn nhiều để khởi động).

Tham khảo: https://leastmasterity.com/blog/BLAKE2-harder-better-faster-stronger-than-MD5.html

Từ slide của Zooko:

chu kỳ trên mỗi byte trên hàm Intel Core i5-3210M (Ivy Bridge) 

chu kỳ trên mỗi byte

          tin nhắn dài 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
BLaken1 5.8 6.0 14.9
BLAKE2 3.5 3.5 9.3

Bạn có thể không thể làm tốt hơn một hàm băm tốt. Bạn có thể muốn kiểm tra các hàm băm / tổng kiểm tra khác để xem liệu có bất kỳ nhanh hơn đáng kể so với md5sum. Lưu ý rằng bạn có thể không cần thứ gì đó mạnh như MD5. MD5 (và những thứ như SHA1) được thiết kế mạnh về mặt mật mã, do đó, kẻ tấn công / kẻ mạo danh không thể tạo ra một tệp mới có cùng giá trị băm như một giá trị hiện có (không có nghĩa là khó có thể giả mạo -mails và các tài liệu khác). Nếu bạn không quan tâm đến một cuộc tấn công vào thông tin liên lạc của bạn, nhưng chỉ có một lỗi giao dịch bình thường, một cái gì đó như kiểm tra dự phòng theo chu kỳ (CRC) có thể đủ tốt. (Nhưng tôi không biết liệu nó có nhanh hơn không.)

Một cách tiếp cận khác là cố gắng thực hiện băm song song với việc chuyển. Điều này có thể làm giảm thời gian tổng thể và chắc chắn có thể giảm hệ số kích thích cần phải đợi quá trình chuyển hoàn tất, và sau đó đợi MD5 kết thúc. Tôi chưa thử nghiệm điều này, nhưng có thể làm điều gì đó như thế này:

• Trên máy nguồn:

  mkfifo myfifo
  tee myfifo < source_file | nc Dest_host  port_number & md5sum myfifo
  

• Trên máy đích:

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

Tất nhiên kiểm tra kích thước của các tệp là một cách tốt, nhanh chóng để phát hiện nếu có bất kỳ byte nào bị mất.

Gửi các tập tin lớn là một nỗi đau. Tại sao không thử phân chia các tệp tạo ra một hàm băm cho mỗi khối và sau đó gửi nó đến đích và sau đó kiểm tra hàm băm và nối các khối.

Bạn cũng có thể thiết lập mạng BitTorrent cá nhân. Điều đó sẽ đảm bảo rằng toàn bộ điều đạt đến an toàn.