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

[Richard14]

询问

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

[wy315700]

tcp 的校验和重发机制保证了数据不会出错。

tls 协议是传输层安全协议，是保证数据不被窃听

[Richard14]

@wy315700

？

tcp 的 checksum 只有 16 位位计算校验，同发错误发生时如何保证不会出错？回答看得我一愣

[3dwelcome]

历史都是重复了，去年的回复：

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]

@Richard14 每个装入 IP 数据报文的 TCP 数据都有一个 16 位校验码，如果有多个错误然后校验码还没变的话，，建议写一篇论文去发表如何构造这种错误。

[eason1874]

Redis 数据校验是应用层自己的事，不关 TCP 传输层的事

多端同步保证数据一致性，这活不是 TCP 干的，也不是 TLS 干的。加 TLS 只是防监听和篡改，适应复杂的内网环境。可以确保内网绝对安全时，加不加都无所谓

[Richard14]

@wy315700 会发生就完事了，还扯什么构造不构造，我不是为了应对攻击，我是要防止程序遇到不可预料的数据

[adadada]

如果对数据完整性又严格要求，建议还是在业务逻辑中也加上额外的检查。隔壁组遇到过网卡的 tcp offload 实现有 bug ，csum 过的报文会以极小概率随机出现几个 bit 的错误

[zhzy0077]

程序的健壮性永远是个概率学的问题 不然世上就不会有人用 UUID 了

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

最后如果一个东西全世界用了几十年了 你担心满足不了你的需求 建议你同样考虑下太阳黑子对你内存数据的修改

[shuax]

tls 和这个有关系？

[hxndg]

@Richard14

[hxndg]

@Richard14 不好意思，刚才按错了。。。
即使用了 tls 也可能数据传输出错，即使是小概率。所以如果你问会不会发生，那确实会，不过你应用层上 hash 也会遇到碰撞，所以你要怎么防备呢？
没明白

[ysc3839]

@wy315700 TCP 不能保证数据完整性，只能保证流的连续性。早年间 http 下载东西容易损坏，rar 的恢复记录很流行就是这个原因。
@zhzy0077 TLS 至少能在数据完整性不通过时报告错误吧。

[IvanLi127]

你要说可能性有没有，那肯定是有。。op 的意思是 tls 能保证数据不会传错？

[momocraft]

1bit/15T 的漏过率在大量传输的情况下不算低了。

在 TCP checksum 基础上，消息内部再加个基于内容的 checksum 应该可以再减小概率。

[yianing]

tls 只是数据加密，和出错也没关系啊？

[yolee599]

tcp 会检验数据啊，发现出错会丢弃数据包，让对方重新传输

[yyfearth]

人家加上 TLS 主要为了加密 防止中间人窃听和资料泄漏
保证资料的正确性有 TCP 层和应用层校验足够了

[kingjpa]

我的理解是 redis 和其他应用一样 有自己的打包和解包协议， 不可能是裸 tcp ,
数据传输错误，redis 自己就会重发。

就连我们自己做 tcp 通行不也会 加包头和包尾 来确认是否完整的包啊。

[smdbh]

担心不可靠，就不要用呗

[LeeReamond]

@yyfearth 应用层校验可还行，所以应用层重新发明 tls ？

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