个人的看法是：网盘传输文件，为实现断点续传等功能，可以底层使用 http 或者一些 RPC 协议传输，然后自己在其上封装一下函数，并且可能增加一些校验，重传机制。从这个角度来看网盘传输依旧存在坏包的概率是很小的，但是事实是包括百度云盘在内的网盘下载压缩文件时，依旧存在坏包的概率。
求解，那个环节出了问题，或者思考疏漏了。
https://www.cnblogs.com/my_life/articles/5367814.html
以前做某个分布式系统, 测试组测试了大量的数据, 发现过各种问题, 比如内存跳变, 磁盘的 silence data cruption, 网卡驱动 bug, 还没有探测到过网络传输后数据出问题的. 我们的测试都是大概 200 台机器网络跑满跑几周的那种.
网盘底层也算是分布式存储, 可能在某些方面一致性上做了妥协, 小概率出现不一致的问题.
不知道什么时候看到的，希望没错
在我的历史下载中 百度云盘下载损坏多数有以下几种情况
– 单个文件过大( >4GB)
– 下载过程中 PC 断网 /睡眠
所以当上面任何一个条件满足的时候我都会对下载后的文件校验（压缩软件上的测试按钮）
如果有损坏的重新下一遍。
不过我可以猜测一下，或许和用户鉴权，写缓存有关。
http://akaptur.com/blog/2017/11/12/love-your-bugs/
我也曾遇到过一次疑似案例，导致了灾难性后果…
打个比方说，你快递寄包裹，走空运的话，传输协议的保证等于是保证飞机不会掉，你包裹放飞机上是安全的，但是没法保证机场装卸工会不会把你箱子搞破一个道理。
2.越复杂的算法，无法验证出错误的概率就越小。一般来说，中小公司不做大数据的话，其实 MD5 的验证算法已经足够了。大文件传输的话，以 16MB 或 32MB 等进行分块，每块传输 md5 校验码，可以保证文件的正确性。
3.TCP 的目的是保证传输性能，并不是完全是保证数据安全。
4.如果要彻底保障数据安全，那么需要完全异构的多套硬件系统以及软件算法，并且进行操作对比来确保安全性。
还有就是 bit flip 这个概率其实很低很低，tcp 层发生了 但是逻辑层还有 md5 这样的 按照块 按照文件校验的。
其实 这种错 客户端 服务器端都知道。只是你们不知道。
想一想一款软件， 主要就是 存储 上传 下载， 运维 开发 怎么可能没有 bug, 对运营方来说 某个版本有错 导致某些数据是错的，是再正常不过的，怎么办？慢慢修复呗 等你再上传一次。
其实云存储 最难的 metadata 的存储。不是纯数据， 纯数据校验容易。