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

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

  •  
  •   LeeReamond · 2021-04-01 17:48:54 +08:00 · 1983 次点击
    这是一个创建于 419 天前的主题,其中的信息可能已经有所发展或是发生改变。

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

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

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

    ======

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

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

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

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

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

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