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

Redis 默认未使用 tls 协议,是否意味着传输数据可能会出错?

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

    询问

    1. Redis6.0 新特性是加入 tls 支持,是否同义词是之前版本不支持 tls
    2. 如果 1 成立的话,Redis 基于 tcp 构建通信协议,tcp 的和校验本身有一定纠错能力,但小概率偶发多点同错时 tcp 只能保证流本身可靠,无法保证传输数据一定可靠。
    3. 这是否意味着我们基于 redis 构建内网服务时,比如多节点靠 redis 集群同步状态,存在状态传着传着就错了的可能性?
    4. 例子方面,之前似乎从未见过 Redis 传输错误的类似新闻,我在本地和内网环境使用也从未遇到过错误。
    35 条回复    2022-04-30 23:44:33 +08:00
    wy315700
        1
    wy315700  
       107 天前
    tcp 的校验和重发机制保证了数据不会出错。

    tls 协议是传输层安全协议,是保证数据不被窃听
    Richard14
        2
    Richard14  
    OP
       107 天前   ❤️ 1
    @wy315700



    tcp 的 checksum 只有 16 位位计算校验,同发错误发生时如何保证不会出错?回答看得我一愣
    3dwelcome
        3
    3dwelcome  
       107 天前 via Android   ❤️ 1
    历史都是重复了,去年的回复:

    Reply 103dwelcome 2021-04-01 20:56:43 PM
    这问题有意思,我去 google 查了一下( http://noahdavids.org/self_published/CRC_and_checksum.html)
    文章里确切的说,用百度云下载数据,每下载 15T 数据后,会有一个随机的错误包被混入其中( ps: 原文里是 10 亿数据包,一个包 1526 字节,相乘一下就是 15T 字节)

    老外还说,15T 数据有一个 bit 出错,对大部分应用都是无感知的。也许互联网天然有容错机制。
    wy315700
        4
    wy315700  
       107 天前
    @Richard14 每个装入 IP 数据报文的 TCP 数据都有一个 16 位校验码,如果有多个错误然后校验码还没变的话,,建议写一篇论文去发表如何构造这种错误。
    eason1874
        5
    eason1874  
       107 天前
    Redis 数据校验是应用层自己的事,不关 TCP 传输层的事

    多端同步保证数据一致性,这活不是 TCP 干的,也不是 TLS 干的。加 TLS 只是防监听和篡改,适应复杂的内网环境。可以确保内网绝对安全时,加不加都无所谓
    Richard14
        6
    Richard14  
    OP
       107 天前
    @wy315700 会发生就完事了,还扯什么构造不构造,我不是为了应对攻击,我是要防止程序遇到不可预料的数据
    adadada
        7
    adadada  
       107 天前 via iPhone
    如果对数据完整性又严格要求,建议还是在业务逻辑中也加上额外的检查。隔壁组遇到过网卡的 tcp offload 实现有 bug ,csum 过的报文会以极小概率随机出现几个 bit 的错误
    zhzy0077
        8
    zhzy0077  
       107 天前 via Android   ❤️ 29
    程序的健壮性永远是个概率学的问题 不然世上就不会有人用 UUID 了

    首先 TCP 的 checksum 无法保证数据不会错 事实上所有的 hash 算法都没法保证数据不被修改 但是在物理层传输的时候 一般的错误就是一两个位 bit 的翻转 这种情况下 checksum 的效果是很好的
    其次你提到的 tls 同样没法保证数据不会错误

    最后如果一个东西全世界用了几十年了 你担心满足不了你的需求 建议你同样考虑下太阳黑子对你内存数据的修改
    shuax
        9
    shuax  
       107 天前 via Android
    tls 和这个有关系?
    hxndg
        10
    hxndg  
       107 天前
    hxndg
        11
    hxndg  
       107 天前
    @Richard14 不好意思,刚才按错了。。。
    即使用了 tls 也可能数据传输出错,即使是小概率。所以如果你问会不会发生,那确实会,不过你应用层上 hash 也会遇到碰撞,所以你要怎么防备呢?
    没明白
    ysc3839
        12
    ysc3839  
       107 天前 via Android   ❤️ 1
    @wy315700 TCP 不能保证数据完整性,只能保证流的连续性。早年间 http 下载东西容易损坏,rar 的恢复记录很流行就是这个原因。
    @zhzy0077 TLS 至少能在数据完整性不通过时报告错误吧。
    IvanLi127
        13
    IvanLi127  
       107 天前 via Android
    你要说可能性有没有,那肯定是有。。op 的意思是 tls 能保证数据不会传错?
    momocraft
        14
    momocraft  
       107 天前   ❤️ 2
    1bit/15T 的漏过率在大量传输的情况下不算低了。

    在 TCP checksum 基础上,消息内部再加个基于内容的 checksum 应该可以再减小概率。
    yianing
        15
    yianing  
       107 天前 via Android
    tls 只是数据加密,和出错也没关系啊?
    yolee599
        16
    yolee599  
       107 天前 via Android
    tcp 会检验数据啊,发现出错会丢弃数据包,让对方重新传输
    yyfearth
        17
    yyfearth  
       107 天前
    人家加上 TLS 主要为了加密 防止中间人窃听和资料泄漏
    保证资料的正确性有 TCP 层和应用层校验足够了
    kingjpa
        18
    kingjpa  
       107 天前
    我的理解是 redis 和其他应用一样 有自己的打包和解包协议, 不可能是裸 tcp ,
    数据传输错误,redis 自己就会重发。

    就连我们自己做 tcp 通行不也会 加包头和包尾 来确认是否完整的包啊。
    smdbh
        19
    smdbh  
       107 天前
    担心不可靠,就不要用呗
    LeeReamond
        20
    LeeReamond  
       107 天前
    @yyfearth 应用层校验可还行,所以应用层重新发明 tls ?
    Buges
        21
    Buges  
       107 天前 via Android
    @kingjpa 你说的那是 UDP ,基于 TCP 的应用层协议,尤其是这种主要用于内网的非 p2p 等需要面对复杂网络环境的应用,还要自己处理错误校验和重传的话,用 TCP 干嘛?
    choury
        22
    choury  
       107 天前
    要是完全纠结这个事情的话,那我告诉你,数据放在内存里面,都有一定概率发生 bit 翻转,你难道也要考虑并且处理这种情况吗?
    Richard14
        23
    Richard14  
    OP
       107 天前
    @choury 我觉得需要建立在实际工业环境上去考虑概率问题。比如如果说 uuid 碰撞概率低于在宇宙中随机选一个原子,那么我们生产上认为这是不可能事件,虽然它可能。硬件处理比特翻转问题有方案,内存方面上 ecc ,总线间传输时也有冗余纠错,可以认为硬件选择合适配置后不考虑比特翻转角度的不可靠性。TCP 传输则不一样,Redis 一天跑出 T 级流量也不是什么稀奇事,我有很关键的数据恰好错了,服务编写不严谨导致崩溃,或者核心数据无法解码造成损失,这怎么办。
    kome
        24
    kome  
       107 天前 via iPhone
    如果单系统不可靠,你可以建立三套一样的系统,所有数据三套系统都要单独处理,处理好以后都提供给终端,终端对比三套系统传输的数据,只要其中一个跟另外两个对不上,数据库就回滚,数据重新处理。这样怎么样?
    wd
        25
    wd  
       107 天前 via iPhone
    @kome 楼主认为宇宙里面一个原子那种概率才行,你这三套差远了
    ZRS
        26
    ZRS  
       107 天前 via iPhone   ❤️ 1
    网络各层都有自己的 checksum 和重传机制,一般情况下是不会出问题的;但是我也见过因为灵车设备充当了攻击中间人导致 TCP 流被污染的情况,所以应用层或者传输层的数据完整性校验还是很有必要的,TLS 就是一个成熟方案
    echo1937
        27
    echo1937  
       107 天前   ❤️ 2
    以前看过一些内容,转贴过来,欢迎指出错误:
    传输差错包括很多方面:比特差错、分组丢失、分组失序、分组重复。
    OP 说的传输数据可能会出错一般是指“比特错误”,常说“TCP 是可靠的,UDP 是不可靠的”一般是指后三者,


    数据链路层,CRC 校验、强校验,检查比特差错,Cut-Through 转发不校验;
    网络层,Checksum 校验,弱校验,检查 IP 头部错误(不包括 IP 数据),IPv6 无此机制;
    传输层,Checksum 校验,弱校验,检查 TCP 头部和 TCP 数据;
    安全层,消息验证码( MAC ,如 HMAC ),强校验,检查某段消息的完整性以及作身份验证,

    相关链接:
    为啥 Checksum 是弱校验,CRC 是强校验( https://www.baeldung.com/cs/crc-vs-checksum
    为什么应用层还要做数据完整性校验? - 知乎 https://www.zhihu.com/question/370717865


    TLDR ,
    1 、未使用 TLS 协议,是否意味着传输数据可能会出错?✅
    2 、使用了 TLS 协议,是否意味着传输数据不会出错?只能说更可靠,比如 HMAC 发生碰撞照样检测不出来。
    sagaxu
        28
    sagaxu  
       107 天前
    @wy315700 16bit 太容易构造了,随便改 17bit 的一段数据,一定会产生重复的 checksum ,穷举 30bit 大概率能构造出你想要的任何 checksum
    LeeReamond
        29
    LeeReamond  
       107 天前   ❤️ 1
    @zhzy0077 一个东西全世界用了几十年了,不需要担心,你指的是 log4j 吗(逃
    yyfearth
        30
    yyfearth  
       107 天前
    @LeeReamond 为啥要重新发明 TLS 呢?一个 hash/checksum 就可以解决的事情
    TLS 本来就是加密用的 为了校验数据完全没必要这么复杂
    应用层发现 hash/checksum 不对 直接丢掉请求重传就是
    cheng6563
        31
    cheng6563  
       107 天前
    @kingjpa redis 直接 telnet 就能连上用,协议裸的不能再裸了、、、
    xuanbg
        32
    xuanbg  
       107 天前
    @Richard14 你不应该防止程序遇到不可预料的数据,而是要去应对程序遇到不可预料的数据。
    zhzy0077
        33
    zhzy0077  
       107 天前
    @LeeReamond 对的 就算你事先担心也没法逃过 log4j 这一劫 因为事实上几乎所有 Java 生态圈的企业都糟了
    Jooooooooo
        34
    Jooooooooo  
       107 天前
    担心可以不用.
    mtrec
        35
    mtrec  
       107 天前
    “the chance of the TCP checksum being called upon to detect a splice is much less than 1 in (10^8)×(2^32) or less than one chance in 10^17.”

    ref: http://ccr.sigcomm.org/archive/1995/conf/partridge.pdf

    再者 redis 设计上更多的是缓存 要是有很重要的数据单一存储在 redis 上 不如多考虑设计的问题 毕竟设计出问题的概率高得多
    关于   ·   帮助文档   ·   API   ·   FAQ   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   1729 人在线   最高记录 5497   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 27ms · UTC 17:06 · PVG 01:06 · LAX 10:06 · JFK 13:06
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.