This topic created in 2139 days ago, the information mentioned may be changed or developed.
比如 http 里的参数 a=1 会不会因为网络故障变成 a=2 了并且服务端正常接收？
设计 RPC 组件的时候要不要考虑这个问题？
设计 RPC 组件的时候要不要考虑这个问题？
 |
1
OliverDD Jun 28, 2020 via Android
tcp 首部不是有校验和吗？校验和无法通过会重传这是网络层干的事情吧？
|
 |
2
zackwu Jun 28, 2020  1
应用层无需考虑这些，你要相信 TCP 连接是可靠的。
TCP 是具有差错检测的，会自动重传。 |
 |
3
wysnylc Jun 28, 2020
网络故障变成 2,笑出声
|
 |
4
si Jun 28, 2020
TCP 自带校验，但是可能会被拦截修改。
|
 |
5
whileFalse Jun 28, 2020
TCP 有简单的位校验和恢复能力。但如果多个位同时出错，也可能瞒过位校验，不过这种可能性很低，通常不需要考虑。
|
 |
6
liuminghao233 Jun 28, 2020 via iPhone
tcp 本身校验用的 crc 不一定可靠
但是加上 tls 的话 因为是 aead 会做校验 一般就没问题了 |
 |
7
gadsavesme Jun 28, 2020
tcp 校验的是内容的完整性吧，丢包粘包这种。不是被劫持篡改，我是想象不出来啥网络能把请求参数 a=1 变成 a=2 的。。
|
 |
8
walsh Jun 28, 2020
可以说是不存在完全可靠的通信系统，你重复发送数据 100 次都在同一个地方出现错误的可能性也是存在的，只是概率太小罢了。校验可以让误码率做到足够小，数据够多 TCP 也可以翻车，Amazon S3 在 2008 年 7 月就遇到过，单 bit 反转导致了一次严重线上事故。
|
|
9
walsh Jun 28, 2020
Amazon 吸取教训加了 check sum （非 tcp 自己的校验和，另外多加的）。你自己也可以再加一层校验，但是以一般人的数据量很难遇到这种情况罢了
|
 |
10
nicebird Jun 28, 2020
tcp crc+应用层校验和比如 tls aead 。
|
 |
11
shansing Jun 28, 2020
@liuminghao233 @nicebird
请教一下，为什么你们强调 AEAD 呢？我记得即使非 AEAD，TLS 协议也设计能保证消息完整性啊，虽然消息验证码效果可能介于 TCP checksum 跟 AEAD 就是了。 |
|
12
whileFalse Jun 28, 2020
@walsh 是数据位的单 bit 和校验位同时反转吗
|
|
13
liuminghao233 Jun 28, 2020 via iPhone 1
|
|
14
walsh Jun 28, 2020
@whileFalse 不清楚具体情况，一种可能是校验后的数据发生反转，二种可能是 checksum 也不是完全可靠的刚好碰撞上通过校验了
|
 |
15
gesse Jun 28, 2020
楼主是不是应用层代码遇到了什么无法解决的 bug，然后想甩锅给 tcp ？（ doge
|
 |
16
caviar Jun 28, 2020
一般基本的应用不需要考虑这些，tcp 有 crc 的校验，如果是 https 的话那就更安全了，毕竟 TLS 层又做了一次。
不过 tcp/udp 的 crc 校验确实出了名的弱，尤其是由于网络设备（例如交换机）的故障导致一直在随机 flip 一些 bit 的话，混过 crc 的概率并不低。近期读了一篇公司内部的 Postmortem 就是讲这样的事故，错误的数据被接受甚至处理了。 |
 |
17
opengps Jun 28, 2020 via Android
TCP 虽然没问题，会丢弃不通过检验的数据重传，但是
http 里的，很容易因为网络发生变化，很多流氓 js 就是这么注入的，注入虽然不是修改，但跟修改大同小异 |
 |
18
julyclyde Jun 28, 2020
实际上我见过 bit 翻转的情况
|
 |
19
cubecube Apr 9, 2021
tcp 的 crc 强度不够，不能校验 2bit 及之上的翻转
内存 bit 也可能翻转 强一致性的系统最好在传输过程中增加 HMAC 校验数据 |
Select Language