为什么面向 TCP 连接是可靠的，网盘传输依旧存在坏包的概率？

[yukinotech]

先排除部分网盘会使用 P2P 技术。

个人的看法是：网盘传输文件，为实现断点续传等功能，可以底层使用 http 或者一些 RPC 协议传输，然后自己在其上封装一下函数，并且可能增加一些校验，重传机制。从这个角度来看网盘传输依旧存在坏包的概率是很小的，但是事实是包括百度云盘在内的网盘下载压缩文件时，依旧存在坏包的概率。

求解，那个环节出了问题，或者思考疏漏了。

[registerrr]

硬盘坏块🤣

[jeffersonpig]

概率很小不就是意味着概率存在吗……

[FS1P7dJz]

可靠只是相对而言啊...

https://www.cnblogs.com/my_life/articles/5367814.html

[yukinotech]

@FS1P7dJz 谢谢分享好文章

[wish198]

TCP 只是通过 ACK 保证不丢包,至于内容其实是可能有差错的,TCP 校验就只是校验了个大概

[yukinotech]

@wish198 如果说应用层还是得自己写校验，比如添加文件的哈希散列值，来保证不出错？

[songco]

不一定是 tcp 的问题

以前做某个分布式系统, 测试组测试了大量的数据, 发现过各种问题, 比如内存跳变, 磁盘的 silence data cruption, 网卡驱动 bug, 还没有探测到过网络传输后数据出问题的. 我们的测试都是大概 200 台机器网络跑满跑几周的那种.

网盘底层也算是分布式存储, 可能在某些方面一致性上做了妥协, 小概率出现不一致的问题.

[wish198]

@yukinotech
比如两边做个 md5 的比较?
从需求来说 可能产品设计认为这种情况遇到的较少,如果所有用户都做了这个校验,资源耗费较大,就忽略了吧
而且说不定他们是 UDP+自定义协议有问题,然后代码有 BUG

[alphatoad]

可能是百度那边的问题，bitrot 了
别的大厂没听说过有这种情况

[arloor]

tcp 的可靠是循环冗余检测 就是算下校验和
这意味着你收到的包，字节数一定对，但是内容不一定对。

不知道什么时候看到的，希望没错

[blu10ph]

这个就像你点外卖,外卖员保证能送过来,但是路上有可能会偷吃~

[JerryCha]

CRC 的纠正能力有限
而且你没发现百度云客户端完整下载下来的文件，最后修改时间基本都不能保持原始数据吗

[las917vki]

TCP 是保证经它流的数据，不保证到底他之前的数据，如果百度的后台在提交数据到网络发送之前生产的数据就是有问题的，那自然就有问题了。

[augustheart]

不做额外校验的话确实是不可能真正保证文件准确的，其实单纯 http 下载出问题的情况很多的。比如早期直接用 http 下电影的年代，电影某一块损坏是非常常见的事（某些帧绿了，花了）。但是问题很多是出在其它方面，比如多线程下载软件断点续传的 bug。http 封包本身出问题的概率相当之小，从我个人的经验还没碰上，如果 http 或 ftp 传输文件错误的话，首先考虑服务器内存是不是有问题，云服务器之前，我们找机房托管 ftp 服务，由于内存损坏导致问题的居然概率颇高，嘛，虽然用的只是便宜机房……
真正要保证文件准确的，比如 bt 这种文件共享方式是要对文件的每一块进行校验，如果有某一块校验不通过，会重新下载这一块。

[Reficul]

内存损坏之后，代码还能跑，但是跑出奇怪结果的一年看见了两次了。。。

[shenlanAZ]

作为一个程序员，我确实无法解释为什么百度云盘有时候下载东西会出错（云盘上的数据是完好的），而迅雷从未出过错。

在我的历史下载中 百度云盘下载损坏多数有以下几种情况

- 单个文件过大( >4GB)
- 下载过程中 PC 断网 /睡眠

所以当上面任何一个条件满足的时候我都会对下载后的文件校验（压缩软件上的测试按钮）

如果有损坏的重新下一遍。

不过我可以猜测一下，或许和用户鉴权，写缓存有关。

[gefranks]

网盘上下来的东西是坏掉的概率还是挺高的,无论是百度还是 115，很多时候坏掉的文件下下来都比正常的文件大几 MB.第二次下载有可能就是正确的

[augustheart]

@shenlanAZ 迅雷出错的是有的。不过自从迅雷变成 bt 客户端后，它大多时候走的是 bt 协议，而 bt 协议是有严格校验的。
实际上多看看迅雷下载日志是能找到块重传的记录的。

[lc7029]

概率小不等于没有

[ETiV]

有篇文章介绍过 dropbox 会发生的 bit flip 问题

http://akaptur.com/blog/2017/11/12/love-your-bugs/

我也曾遇到过一次疑似案例，导致了灾难性后果…

[rainbowchou]

出问题感觉也不是协议和软件上的事情，应该是端到端的硬件设备出错可能性较大，然后你所说的在 http 协议上再封装不是很能看懂，你说的校验 /重传不是 TCP 运输层对 ip 包做的事情吗，为何还要在应用层再搞一次，tcp 可以保证数据完整透传到应用层

[mingliang2015]

得看 crc 的机制了。

[luoqeng]

TCP 不能保证应用层处理了，这是问题的关键，一条消息有没有被处理或者处理失败是应用层的 ACK 机制了。

[ace12]

可以看看 crc,并不是百分之百保证正确，但是 99%是没问题的

[imn1]

@blu10ph #11
少了不可怕，多了就可怕了

[niubee1]

传输协议并不能保证最终到达不会出错，因为最终是执行下载的应用程序把文件数据最终写入存储设备的，应用程序写入的时候出错了，确切的说是从接收到 TCP 数据到写入存储的中间过程出错了，那么你得到的也就是一个坏的文件。

打个比方说，你快递寄包裹，走空运的话，传输协议的保证等于是保证飞机不会掉，你包裹放飞机上是安全的，但是没法保证机场装卸工会不会把你箱子搞破一个道理。

[msg7086]

文件存储出问题或者应用层出问题。TCP 是更底层的东西，救不了上层。

[kljsandjb]

可靠是可靠在假如不可靠的情况下它的处理方式

[wanguorui123]

硬盘坏快下载下来也是坏的；网盘的文件存储的业务逻辑有 Bug ； TCP 协议自身没问题。

[love]

下载 BT 完成的时候会有一次 hash 校验，网盘是没有做的

[RLado]

@alphatoad
就是百度网 P 的问题，BT 都没问题。 大文件百度要下 N 次才正常。

[wangyzj]

可以买彩票了吗？

[xiadong1994]

TCP 的可靠传输就是丢包重传，包校验和错误基本等于这个包丢了。校验和不能完全保证数据正确……

[laminux29]

1.除了整体对比之外，没有任何摘要或校验算法，能够保证 100%的校验出错误，包括 CRC、MD5、SHA512 等等。

2.越复杂的算法，无法验证出错误的概率就越小。一般来说，中小公司不做大数据的话，其实 MD5 的验证算法已经足够了。大文件传输的话，以 16MB 或 32MB 等进行分块，每块传输 md5 校验码，可以保证文件的正确性。

3.TCP 的目的是保证传输性能，并不是完全是保证数据安全。

4.如果要彻底保障数据安全，那么需要完全异构的多套硬件系统以及软件算法，并且进行操作对比来确保安全性。

[vmebeh]

还有可能网盘收到的文件就是坏的

[roychan]

任何一层都需要做容错

[Kagari]

我用百度云下同一个文件，不点暂停直接下完就没事，点了暂停再继续下载，解压就报错，你觉得是哪的锅？

[firefox12]

基本都是代码问题，比如服务器有 bug, 导致一些数据上传的时候 校验就有问题。代码 bug，保存数据时 自己覆盖了自己某些部分， 其实服务器端也能验证出来，但是它也直接传给你了。

还有就是 bit flip 这个概率其实很低很低，tcp 层发生了 但是逻辑层还有 md5 这样的 按照块 按照文件校验的。
其实 这种错 客户端 服务器端都知道。只是你们不知道。

想一想一款软件， 主要就是 存储 上传 下载， 运维 开发 怎么可能没有 bug, 对运营方来说 某个版本有错 导致某些数据是错的，是再正常不过的，怎么办？慢慢修复呗 等你再上传一次。

其实云存储 最难的 metadata 的存储。不是纯数据， 纯数据校验容易。

[kojirou]

直接说百度 LJ 不就完事了？

[ps1aniuge]

百度网盘太 LJ，百度网盘太 LJ，百度网盘越来越 LJ----------大文件下载完不校验！大文件下载完不校验！大文件下载完不校验！

[DOLLOR]

没人说 115 么？我用了 115 发现，这货出现坏档的概率也很高，有时要重下几次才能成功，说明服务器的文件是完整的，而传输过程出现了问题，或者客户端有 bug

[cheng6563]

tls 这些加密协议应该会校验数据完整吧

[favourstreet]

@cheng6563 是的，tls 会计算数据的 HMAC，所以不论是对数据安全的保护还是数据完整性的保护都比 tcp 强太多了