V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX 提问指南
LeeReamond
V2EX  ›  问与答

TCP 保证传输可靠是否是伪命题?

  •  
  •   LeeReamond · 294 天前 · 1907 次点击
    这是一个创建于 294 天前的主题,其中的信息可能已经有所发展或是发生改变。

    如题,想到一个问题,即排除三次握手与四次分手所保证的连接可靠性后,服务端能否确保与客户端接收数据完全一致?

    比如客户端发送了 aaaaaaa,被拆分成三个封包发送,而服务端接收到该字符串后,虽然能确保按顺序接收,但会不会因为网络不稳定或硬件因素影响,导致接收数据变成了 aaabaaa ?

    看了一些文章,tcp 对于数据本身的校验采用反码求和的算法,通常我们认为确保可靠都是计算 hash 之类的,这个反码求和似乎并没有 hash 那么靠谱,按照我的理解,反码求和当中比如同时有 2 个以上的 bit 改变,是可能导致求和结果相同,但具体内容不同的。

    ======

    是否是我理解错了?还是 TCP 确实无法保证完全相同,业务上的校验需要应用层进行进一步校验?

    第 1 条附言  ·  294 天前
    其实更有意思的一个问题是...据我所知 Redis 就是在 tcp 上面架了个 redis 协议,而且默认是不开启 tls 的...那是否意味着 redis 大量存取数据过程中可能因为网络波动导致数据不可靠。。。
    17 条回复    2021-04-02 00:22:08 +08:00
    WIN2333
        1
    WIN2333  
       294 天前
    无论是哪个 Checksum 校验,都是只防君子,不防小人
    https://www.zhihu.com/question/20184058,这个回答可以解答你的问题
    iyaozhen
        2
    iyaozhen  
       294 天前
    有 seq number 和 ack

    tcp 协议本身还有很多字段 部署 aaa 这些内容
    opengps
        3
    opengps  
       294 天前
    业务上的校验是不可避免的,不如粘包问题,tcp 自己是解决不了的
    WIN2333
        4
    WIN2333  
       294 天前   ❤️ 4
    tcp 没有粘包问题,tcp 是基于字节流传输的,不要被粘包这个词误解了,就不应该有这个词,字节流传输的边界问题本来就应该是应用层处理的 @opengps
    iyaozhen
        5
    iyaozhen  
       294 天前
    @iyaozhen 哦 说的不是一个事情。好像没怎么关注过数据被篡改的情况。
    love
        6
    love  
       294 天前 via Android
    可能性非常小。何况重要的情况都用 HTTPS,额外加了一层可靠校验
    Aliencn
        7
    Aliencn  
       294 天前
    TCP 有数据校验的功能,Google 一下“TCP md5”就能查到相关资料。

    不过现在大多数都是用 TCP 来保证数据可靠性,SSL/TLS 保证数据完整性吧。
    LeeReamond
        9
    LeeReamond  
    OP
       294 天前
    @Aliencn
    @wanguorui123 感谢,看了一下资料,总结来说问题确实存在,而 TCP 也确实有 hash 校验选项,只不过默认不开启。Linux 内核提供了 tcp md5 的功能,但手册语焉不详,需要传入指定内存结构的结构体,导致类似 java 之类的语言里启用传输层的校验似乎比较困难。

    解决方案的话,本身下层还有校验,我本人提问的时候也不觉得这是个高发情况,所以非关键业务可以忽略。特殊业务场景,可信网域的话可能有特殊需求,比如 tls 成本太高的话可以应用层自己实现,使用一些快速哈希之类的。
    3dwelcome
        10
    3dwelcome  
       294 天前
    这问题有意思,我去 google 查了一下( http://noahdavids.org/self_published/CRC_and_checksum.html)
    文章里确切的说,用百度云下载数据,每下载 15T 数据后,会有一个随机的错误包被混入其中( ps: 原文里是 10 亿数据包,一个包 1526 字节,相乘一下就是 15T 字节)

    老外还说,15T 数据有一个 bit 出错,对大部分应用都是无感知的。也许互联网天然有容错机制。
    v2tudnew
        11
    v2tudnew  
       294 天前
    感觉应用校验也是有需要的(重要的话),比如 HTTP 经常下了损坏文件,BT 下个几十 GB 丢弃几十几百 MB 。
    bengol
        12
    bengol  
       294 天前 via Android
    和你确认是的,因为我们生产环境确实出现了。
    ZRS
        13
    ZRS  
       294 天前 via iPhone
    绝对的可靠是不能保证的,需要应用层自己校验。其实套个 TLS 基本解决问题了
    Sanko
        14
    Sanko  
       294 天前 via Android
    crc32
    acerlawson
        15
    acerlawson  
       294 天前 via iPhone
    end to end argument
    ysc3839
        16
    ysc3839  
       294 天前
    据说当年 RAR 流行是因为支持恢复记录,加上 http 下载的错误率较高,有恢复记录可以避免重新下载。
    当然这只是据说,不过为了保险起见,要保证数据完整性的话还是上 TLS 吧。
    lujjjh
        17
    lujjjh  
       294 天前 via iPhone
    Ethernet FCS
    关于   ·   帮助文档   ·   API   ·   FAQ   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   3859 人在线   最高记录 5497   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 22ms · UTC 05:39 · PVG 13:39 · LAX 21:39 · JFK 00:39
    ♥ Do have faith in what you're doing.