首页   注册   登录
V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
yukinotech
V2EX  ›  程序员

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

  •  
  •   yukinotech · 172 天前 · 6837 次点击
    这是一个创建于 172 天前的主题,其中的信息可能已经有所发展或是发生改变。
    先排除部分网盘会使用 P2P 技术。

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

    求解,那个环节出了问题,或者思考疏漏了。
    43 条回复    2020-01-26 19:00:40 +08:00
    registerrr
        1
    registerrr   172 天前
    硬盘坏块🤣
    jeffersonpig
        2
    jeffersonpig   172 天前
    概率很小不就是意味着概率存在吗……
    FS1P7dJz
        3
    FS1P7dJz   172 天前   ❤️ 5
    yukinotech
        4
    yukinotech   172 天前
    @FS1P7dJz 谢谢分享好文章
    wish198
        5
    wish198   172 天前
    TCP 只是通过 ACK 保证不丢包,至于内容其实是可能有差错的,TCP 校验就只是校验了个大概
    yukinotech
        6
    yukinotech   172 天前
    @wish198 如果说应用层还是得自己写校验,比如添加文件的哈希散列值,来保证不出错?
    songco
        7
    songco   172 天前   ❤️ 9
    不一定是 tcp 的问题

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

    网盘底层也算是分布式存储, 可能在某些方面一致性上做了妥协, 小概率出现不一致的问题.
    wish198
        8
    wish198   172 天前
    @yukinotech
    比如两边做个 md5 的比较?
    从需求来说 可能产品设计认为这种情况遇到的较少,如果所有用户都做了这个校验,资源耗费较大,就忽略了吧
    而且说不定他们是 UDP+自定义协议有问题,然后代码有 BUG
    alphatoad
        9
    alphatoad   172 天前 via iPhone
    可能是百度那边的问题,bitrot 了
    别的大厂没听说过有这种情况
    arloor
        10
    arloor   172 天前 via Android
    tcp 的可靠是循环冗余检测 就是算下校验和
    这意味着你收到的包,字节数一定对,但是内容不一定对。

    不知道什么时候看到的,希望没错
    blu10ph
        11
    blu10ph   172 天前
    这个就像你点外卖,外卖员保证能送过来,但是路上有可能会偷吃~
    JerryCha
        12
    JerryCha   172 天前
    CRC 的纠正能力有限
    而且你没发现百度云客户端完整下载下来的文件,最后修改时间基本都不能保持原始数据吗
    las917vki
        13
    las917vki   172 天前
    TCP 是保证经它流的数据,不保证到底他之前的数据,如果百度的后台在提交数据到网络发送之前生产的数据就是有问题的,那自然就有问题了。
    augustheart
        14
    augustheart   172 天前   ❤️ 1
    不做额外校验的话确实是不可能真正保证文件准确的,其实单纯 http 下载出问题的情况很多的。比如早期直接用 http 下电影的年代,电影某一块损坏是非常常见的事(某些帧绿了,花了)。但是问题很多是出在其它方面,比如多线程下载软件断点续传的 bug。http 封包本身出问题的概率相当之小,从我个人的经验还没碰上,如果 http 或 ftp 传输文件错误的话,首先考虑服务器内存是不是有问题,云服务器之前,我们找机房托管 ftp 服务,由于内存损坏导致问题的居然概率颇高,嘛,虽然用的只是便宜机房……
    真正要保证文件准确的,比如 bt 这种文件共享方式是要对文件的每一块进行校验,如果有某一块校验不通过,会重新下载这一块。
    Reficul
        15
    Reficul   172 天前 via Android
    内存损坏之后,代码还能跑,但是跑出奇怪结果的一年看见了两次了。。。
    shenlanAZ
        16
    shenlanAZ   172 天前
    作为一个程序员,我确实无法解释为什么百度云盘有时候下载东西会出错(云盘上的数据是完好的),而迅雷从未出过错。

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

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

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

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

    不过我可以猜测一下,或许和用户鉴权,写缓存有关。
    gefranks
        17
    gefranks   172 天前
    网盘上下来的东西是坏掉的概率还是挺高的,无论是百度还是 115,很多时候坏掉的文件下下来都比正常的文件大几 MB.第二次下载有可能就是正确的
    augustheart
        18
    augustheart   172 天前
    @shenlanAZ 迅雷出错的是有的。不过自从迅雷变成 bt 客户端后,它大多时候走的是 bt 协议,而 bt 协议是有严格校验的。
    实际上多看看迅雷下载日志是能找到块重传的记录的。
    lc7029
        19
    lc7029   172 天前
    概率小不等于没有
    ETiV
        20
    ETiV   172 天前 via iPhone
    有篇文章介绍过 dropbox 会发生的 bit flip 问题

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

    我也曾遇到过一次疑似案例,导致了灾难性后果…
    rainbowchou
        21
    rainbowchou   172 天前
    出问题感觉也不是协议和软件上的事情,应该是端到端的硬件设备出错可能性较大,然后你所说的在 http 协议上再封装不是很能看懂,你说的校验 /重传不是 TCP 运输层对 ip 包做的事情吗,为何还要在应用层再搞一次,tcp 可以保证数据完整透传到应用层
    mingliang2015
        22
    mingliang2015   172 天前
    得看 crc 的机制了。
    luoqeng
        23
    luoqeng   172 天前
    TCP 不能保证应用层处理了,这是问题的关键,一条消息有没有被处理或者处理失败是应用层的 ACK 机制了。
    ace12
        24
    ace12   172 天前
    可以看看 crc,并不是百分之百保证正确,但是 99%是没问题的
    imn1
        25
    imn1   172 天前
    @blu10ph #11
    少了不可怕,多了就可怕了
    niubee1
        26
    niubee1   172 天前
    传输协议并不能保证最终到达不会出错,因为最终是执行下载的应用程序把文件数据最终写入存储设备的,应用程序写入的时候出错了,确切的说是从接收到 TCP 数据到写入存储的中间过程出错了,那么你得到的也就是一个坏的文件。

    打个比方说,你快递寄包裹,走空运的话,传输协议的保证等于是保证飞机不会掉,你包裹放飞机上是安全的,但是没法保证机场装卸工会不会把你箱子搞破一个道理。
    msg7086
        27
    msg7086   172 天前 via Android
    文件存储出问题或者应用层出问题。TCP 是更底层的东西,救不了上层。
    kljsandjb
        28
    kljsandjb   172 天前 via iPhone
    可靠是可靠在假如不可靠的情况下它的处理方式
    wanguorui123
        29
    wanguorui123   172 天前
    硬盘坏快下载下来也是坏的;网盘的文件存储的业务逻辑有 Bug ; TCP 协议自身没问题。
    love
        30
    love   172 天前
    下载 BT 完成的时候会有一次 hash 校验,网盘是没有做的
    RLado
        31
    RLado   172 天前
    @alphatoad
    就是百度网 P 的问题,BT 都没问题。 大文件百度要下 N 次才正常。
    wangyzj
        32
    wangyzj   172 天前
    可以买彩票了吗?
    xiadong1994
        33
    xiadong1994   172 天前
    TCP 的可靠传输就是丢包重传,包校验和错误基本等于这个包丢了。校验和不能完全保证数据正确……
    laminux29
        34
    laminux29   172 天前
    1.除了整体对比之外,没有任何摘要或校验算法,能够保证 100%的校验出错误,包括 CRC、MD5、SHA512 等等。

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

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

    4.如果要彻底保障数据安全,那么需要完全异构的多套硬件系统以及软件算法,并且进行操作对比来确保安全性。
    vmebeh
        35
    vmebeh   172 天前 via iPhone
    还有可能网盘收到的文件就是坏的
    roychan
        36
    roychan   171 天前
    任何一层都需要做容错
    Kagari
        37
    Kagari   171 天前 via Android
    我用百度云下同一个文件,不点暂停直接下完就没事,点了暂停再继续下载,解压就报错,你觉得是哪的锅?
    firefox12
        38
    firefox12   171 天前
    基本都是代码问题,比如服务器有 bug, 导致一些数据上传的时候 校验就有问题。代码 bug,保存数据时 自己覆盖了自己某些部分, 其实服务器端也能验证出来,但是它也直接传给你了。

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

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

    其实云存储 最难的 metadata 的存储。不是纯数据, 纯数据校验容易。
    kojirou
        39
    kojirou   171 天前
    直接说百度 LJ 不就完事了?
    ps1aniuge
        40
    ps1aniuge   171 天前
    百度网盘太 LJ,百度网盘太 LJ,百度网盘越来越 LJ----------大文件下载完不校验!大文件下载完不校验!大文件下载完不校验!
    DOLLOR
        41
    DOLLOR   169 天前
    没人说 115 么?我用了 115 发现,这货出现坏档的概率也很高,有时要重下几次才能成功,说明服务器的文件是完整的,而传输过程出现了问题,或者客户端有 bug
    cheng6563
        42
    cheng6563   168 天前 via Android
    tls 这些加密协议应该会校验数据完整吧
    favourstreet
        43
    favourstreet   168 天前 via Android
    @cheng6563 是的,tls 会计算数据的 HMAC,所以不论是对数据安全的保护还是数据完整性的保护都比 tcp 强太多了
    关于   ·   FAQ   ·   API   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   4448 人在线   最高记录 5168   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 35ms · UTC 01:48 · PVG 09:48 · LAX 18:48 · JFK 21:48
    ♥ Do have faith in what you're doing.