为什么面向 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/

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