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