这是一个创建于 923 天前的主题，其中的信息可能已经有所发展或是发生改变。
询问
- Redis6.0 新特性是加入 tls 支持，是否同义词是之前版本不支持 tls
- 如果 1 成立的话，Redis 基于 tcp 构建通信协议，tcp 的和校验本身有一定纠错能力，但小概率偶发多点同错时 tcp 只能保证流本身可靠，无法保证传输数据一定可靠。
- 这是否意味着我们基于 redis 构建内网服务时，比如多节点靠 redis 集群同步状态，存在状态传着传着就错了的可能性？
- 例子方面，之前似乎从未见过 Redis 传输错误的类似新闻，我在本地和内网环境使用也从未遇到过错误。
 |
1
wy315700 2022-04-30 10:38:24 +08:00
tcp 的校验和重发机制保证了数据不会出错。
tls 协议是传输层安全协议，是保证数据不被窃听 |
 |
2
Richard14 OP  1
|
 |
3
3dwelcome 2022-04-30 11:03:20 +08:00 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 出错，对大部分应用都是无感知的。也许互联网天然有容错机制。 |
|
4
wy315700 2022-04-30 11:13:55 +08:00
@Richard14 每个装入 IP 数据报文的 TCP 数据都有一个 16 位校验码，如果有多个错误然后校验码还没变的话，，建议写一篇论文去发表如何构造这种错误。
|
 |
5
eason1874 2022-04-30 11:18:59 +08:00
Redis 数据校验是应用层自己的事，不关 TCP 传输层的事
多端同步保证数据一致性，这活不是 TCP 干的，也不是 TLS 干的。加 TLS 只是防监听和篡改，适应复杂的内网环境。可以确保内网绝对安全时，加不加都无所谓 |
 |
7
adadada 2022-04-30 11:58:38 +08:00 via iPhone
如果对数据完整性又严格要求，建议还是在业务逻辑中也加上额外的检查。隔壁组遇到过网卡的 tcp offload 实现有 bug ，csum 过的报文会以极小概率随机出现几个 bit 的错误
|
 |
8
zhzy0077 2022-04-30 12:02:06 +08:00 via Android 29
程序的健壮性永远是个概率学的问题 不然世上就不会有人用 UUID 了
首先 TCP 的 checksum 无法保证数据不会错 事实上所有的 hash 算法都没法保证数据不被修改 但是在物理层传输的时候 一般的错误就是一两个位 bit 的翻转 这种情况下 checksum 的效果是很好的 其次你提到的 tls 同样没法保证数据不会错误 最后如果一个东西全世界用了几十年了 你担心满足不了你的需求 建议你同样考虑下太阳黑子对你内存数据的修改 |
 |
9
shuax 2022-04-30 12:05:37 +08:00 via Android
tls 和这个有关系？
|
 |
11
hxndg 2022-04-30 12:11:23 +08:00
@Richard14 不好意思，刚才按错了。。。
即使用了 tls 也可能数据传输出错，即使是小概率。所以如果你问会不会发生，那确实会，不过你应用层上 hash 也会遇到碰撞，所以你要怎么防备呢？ 没明白 |
 |
12
ysc3839 2022-04-30 12:28:54 +08:00 via Android 1
|
 |
13
IvanLi127 2022-04-30 12:35:14 +08:00 via Android
你要说可能性有没有，那肯定是有。。op 的意思是 tls 能保证数据不会传错？
|
 |
14
momocraft 2022-04-30 12:36:51 +08:00 2
1bit/15T 的漏过率在大量传输的情况下不算低了。
在 TCP checksum 基础上，消息内部再加个基于内容的 checksum 应该可以再减小概率。 |
 |
15
yianing 2022-04-30 12:59:51 +08:00 via Android
tls 只是数据加密，和出错也没关系啊？
|
 |
16
yolee599 2022-04-30 13:18:39 +08:00 via Android
tcp 会检验数据啊，发现出错会丢弃数据包，让对方重新传输
|
 |
17
yyfearth 2022-04-30 13:23:00 +08:00
人家加上 TLS 主要为了加密 防止中间人窃听和资料泄漏
保证资料的正确性有 TCP 层和应用层校验足够了 |
 |
18
kingjpa 2022-04-30 13:25:34 +08:00
我的理解是 redis 和其他应用一样 有自己的打包和解包协议， 不可能是裸 tcp ,
数据传输错误，redis 自己就会重发。 就连我们自己做 tcp 通行不也会 加包头和包尾 来确认是否完整的包啊。 |
 |
19
smdbh 2022-04-30 13:53:41 +08:00
担心不可靠，就不要用呗
|
 |
20
LeeReamond 2022-04-30 14:05:58 +08:00
@yyfearth 应用层校验可还行，所以应用层重新发明 tls ？
|
 |
21
Buges 2022-04-30 14:06:24 +08:00 via Android
@kingjpa 你说的那是 UDP ，基于 TCP 的应用层协议，尤其是这种主要用于内网的非 p2p 等需要面对复杂网络环境的应用，还要自己处理错误校验和重传的话，用 TCP 干嘛？
|
 |
22
choury 2022-04-30 14:08:42 +08:00
要是完全纠结这个事情的话，那我告诉你，数据放在内存里面，都有一定概率发生 bit 翻转，你难道也要考虑并且处理这种情况吗？
|
|
23
Richard14 OP @choury 我觉得需要建立在实际工业环境上去考虑概率问题。比如如果说 uuid 碰撞概率低于在宇宙中随机选一个原子，那么我们生产上认为这是不可能事件，虽然它可能。硬件处理比特翻转问题有方案，内存方面上 ecc ，总线间传输时也有冗余纠错，可以认为硬件选择合适配置后不考虑比特翻转角度的不可靠性。TCP 传输则不一样，Redis 一天跑出 T 级流量也不是什么稀奇事，我有很关键的数据恰好错了，服务编写不严谨导致崩溃，或者核心数据无法解码造成损失，这怎么办。
|
 |
24
kome 2022-04-30 15:01:23 +08:00 via iPhone
如果单系统不可靠，你可以建立三套一样的系统，所有数据三套系统都要单独处理，处理好以后都提供给终端，终端对比三套系统传输的数据，只要其中一个跟另外两个对不上，数据库就回滚，数据重新处理。这样怎么样？
|
 |
26
ZRS 2022-04-30 15:24:22 +08:00 via iPhone 1
网络各层都有自己的 checksum 和重传机制，一般情况下是不会出问题的；但是我也见过因为灵车设备充当了攻击中间人导致 TCP 流被污染的情况，所以应用层或者传输层的数据完整性校验还是很有必要的，TLS 就是一个成熟方案
|
 |
27
echo1937 2022-04-30 15:28:07 +08:00 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 发生碰撞照样检测不出来。 |
 |
28
sagaxu 2022-04-30 15:38:42 +08:00
@wy315700 16bit 太容易构造了，随便改 17bit 的一段数据，一定会产生重复的 checksum ，穷举 30bit 大概率能构造出你想要的任何 checksum
|
|
29
LeeReamond 2022-04-30 15:50:48 +08:00 1
@zhzy0077 一个东西全世界用了几十年了，不需要担心，你指的是 log4j 吗（逃
|
|
30
yyfearth 2022-04-30 16:44:57 +08:00
@LeeReamond 为啥要重新发明 TLS 呢？一个 hash/checksum 就可以解决的事情
TLS 本来就是加密用的 为了校验数据完全没必要这么复杂 应用层发现 hash/checksum 不对 直接丢掉请求重传就是 |
|
33
zhzy0077 2022-04-30 22:02:55 +08:00
@LeeReamond 对的 就算你事先担心也没法逃过 log4j 这一劫 因为事实上几乎所有 Java 生态圈的企业都糟了
|
 |
34
Jooooooooo 2022-04-30 23:13:57 +08:00
担心可以不用.
|
 |
35
mtrec 2022-04-30 23:44:33 +08:00
“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 上 不如多考虑设计的问题 毕竟设计出问题的概率高得多 |
Select Language