如何验证1TB文件正确传输？

我经常将VM映像从虚拟机管理程序传输到存档服务器以进行长期存储。

我使用netcat进行传输，因为它比scp，rsync等更快。

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

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

文件传输完成后，通过md5sum在目标和源上运行，我确认没有损坏。

不幸的是，在大文件上运行md5sum可能会花费很长时间。如何更快地比较两个大文件的完整性？

更新：

• 我的传输很少中断，因此重启能力不是问题。
• 通过NC传输通常需要3-4个小时，然后需要40分钟才能获得md5sum。
• 在这种情况下，哈希的安全性不是问题。

您可以使用tee 这样进行实时求和（根据需要调整netcat命令）：

服务器：

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

客户：

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

tee如果您主要担心网络损坏，那么Nerdwaller的有关同时传输和计算校验和的答案是一个好方法。但是，它无法保护您免遭磁盘损坏等问题，因为它在到达磁盘之前先接受校验和。

但我想补充一点：

1 TiB / 40分钟≈437 MiB /秒¹。

实际上，那非常快。请记住，除非您有大量 RAM，否则必须从存储中恢复。因此，要检查的第一件事是在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最低。至少在类似PC的硬件上，这种结果是典型的。

如果您希望获得更高的性能（以琐碎的代价来进行篡改，并且也不太可能检测到损坏），则需要查看CRC或Adler哈希。在这两者中，阿德勒通常更快，但更弱。不幸的是，我不知道任何真正快速的命令行实现。我系统上的程序都比OpenSSL的md4慢。

因此，最好的选择是速度openssl md4 -r（-r使其看起来像md5sum输出）。

如果您愿意进行一些编译和/或最少的编程，请在Stack Overflow和xxhash 上查看Mark Adler的代码。如果您具有SSE 4.2，将无法超越硬件CRC指令的速度。

¹ 1 TiB =1024⁴字节; 1 MiB =1024²字节。功率为1000时约为417MB /秒。

该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

从Zooko的幻灯片中：

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
凯科克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
  tee myfifo <源文件 | nc dest_host  port_number和md5sum myfifo
  

• 在目标计算机上：

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

当然，检查文件的大小是一种检测是否丢失任何字节的好方法。

发送大文件很痛苦。为什么不尝试对文件进行分块，则为每个块生成一个哈希，然后将其发送到目标，然后检查哈希并合并这些块。

您还可以设置个人BitTorrent网络。那将确保整个事情安全到达。