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

[Richard14]

询问

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

[Buges]

@kingjpa 你说的那是 UDP ，基于 TCP 的应用层协议，尤其是这种主要用于内网的非 p2p 等需要面对复杂网络环境的应用，还要自己处理错误校验和重传的话，用 TCP 干嘛？

[choury]

要是完全纠结这个事情的话，那我告诉你，数据放在内存里面，都有一定概率发生 bit 翻转，你难道也要考虑并且处理这种情况吗？

[Richard14]

@choury 我觉得需要建立在实际工业环境上去考虑概率问题。比如如果说 uuid 碰撞概率低于在宇宙中随机选一个原子，那么我们生产上认为这是不可能事件，虽然它可能。硬件处理比特翻转问题有方案，内存方面上 ecc ，总线间传输时也有冗余纠错，可以认为硬件选择合适配置后不考虑比特翻转角度的不可靠性。TCP 传输则不一样，Redis 一天跑出 T 级流量也不是什么稀奇事，我有很关键的数据恰好错了，服务编写不严谨导致崩溃，或者核心数据无法解码造成损失，这怎么办。

[kome]

如果单系统不可靠，你可以建立三套一样的系统，所有数据三套系统都要单独处理，处理好以后都提供给终端，终端对比三套系统传输的数据，只要其中一个跟另外两个对不上，数据库就回滚，数据重新处理。这样怎么样？

[wd]

@kome 楼主认为宇宙里面一个原子那种概率才行，你这三套差远了

[ZRS]

网络各层都有自己的 checksum 和重传机制，一般情况下是不会出问题的；但是我也见过因为灵车设备充当了攻击中间人导致 TCP 流被污染的情况，所以应用层或者传输层的数据完整性校验还是很有必要的，TLS 就是一个成熟方案

[echo1937]

以前看过一些内容，转贴过来，欢迎指出错误：
传输差错包括很多方面：比特差错、分组丢失、分组失序、分组重复。
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]

@wy315700 16bit 太容易构造了，随便改 17bit 的一段数据，一定会产生重复的 checksum ，穷举 30bit 大概率能构造出你想要的任何 checksum

[LeeReamond]

@zhzy0077 一个东西全世界用了几十年了，不需要担心，你指的是 log4j 吗（逃

[yyfearth]

@LeeReamond 为啥要重新发明 TLS 呢？一个 hash/checksum 就可以解决的事情
TLS 本来就是加密用的 为了校验数据完全没必要这么复杂
应用层发现 hash/checksum 不对 直接丢掉请求重传就是

[cheng6563]

@kingjpa redis 直接 telnet 就能连上用，协议裸的不能再裸了、、、

[xuanbg]

@Richard14 你不应该防止程序遇到不可预料的数据，而是要去应对程序遇到不可预料的数据。

[zhzy0077]

@LeeReamond 对的 就算你事先担心也没法逃过 log4j 这一劫 因为事实上几乎所有 Java 生态圈的企业都糟了

[Jooooooooo]

担心可以不用.

[mtrec]

“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 上 不如多考虑设计的问题 毕竟设计出问题的概率高得多