我有一个从服务器下载文件的应用程序。连接非常不稳定，因此我们正在实施一项功能来检查文件完整性，以便我们可以知道文件是否未正确下载并进行相应管理。
我应该如何进行这个过程？现在我向服务器请求文件的哈希值，然后我对文件本身发出另一个请求，然后计算下载文件的哈希值并比较两个哈希值。
这是正确的方法吗？有些东西告诉我它不是。如果发现哈希值不同，我会多次执行完全相同的过程，包括再次请求哈希值（应该相同）。我应该每次都麻烦请求哈希吗？如果没有正确传输，我会这样做吗？这是不必要的吗？有没有办法让我减少请求的数量，因为它们很昂贵，而且现在事情非常缓慢。
有任何想法吗？
以防万一服务器使用 C# 而客户端是 android 设备 (JAVA)。
谢谢，
TCP/IP 自己进行完整性检查；你不必。每个数据包的完整性通过 CRC 来确保，TCP 协议会检查丢失的数据包并请求重新提交。因此，只要您的服务器生成 Content-Length 标头，您就可以确保检测到错误传输并且客户端出错。
也就是说，文件哈希的好地方是自定义 HTTP 标头。在其名称前加上“X-”，这样它就不会与现有或未来的标准标题冲突。
是的，有更好的方法。首先，不是请求整个文件的哈希，而是压缩文件并将压缩数据分割成（比如说）100KB 的块，并提供一个哈希序列，每个块一个，然后是这些哈希序列的自哈希。通过自散列，我只是指获取散列向量，对其进行散列并将其粘贴在向量的末尾。
您现在可以通过检查自哈希来验证此哈希向量是否正确传输。如果没有通过，重新请求哈希向量。
然后第二阶段是请求传输压缩数据。当遇到这种情况时，您可以以 100KB 的间隔检查传输是否正确，一旦出现错误就会中止。然后（如果可能的话）从你离开的地方开始重新请求，一个“高潮标记”。
最后，您可以安全地解压缩数据。许多解压缩算法会执行进一步的完整性检查，从而为您提供进一步的验证——防止任何编程错误。免费检查是值得的。
无论您使用的是 TCP/IP 等经过检查的协议还是 UDP 等不可靠的协议，这种方法都将有效。压缩数据，如果你还没有这样做，也将是一个显着的改进。
唯一的缺点 - 这显然是更多的工作。