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