tcp 有对数据进行校验吗？

tcp 首部不是有校验和吗？校验和无法通过会重传这是网络层干的事情吧？

应用层无需考虑这些，你要相信 TCP 连接是可靠的。

TCP 是具有差错检测的，会自动重传。

网络故障变成 2,笑出声

TCP 自带校验，但是可能会被拦截修改。

TCP 有简单的位校验和恢复能力。但如果多个位同时出错，也可能瞒过位校验，不过这种可能性很低，通常不需要考虑。

tcp 本身校验用的 crc 不一定可靠
但是加上 tls 的话 因为是 aead 会做校验
一般就没问题了

tcp 校验的是内容的完整性吧，丢包粘包这种。不是被劫持篡改，我是想象不出来啥网络能把请求参数 a=1 变成 a=2 的。。

可以说是不存在完全可靠的通信系统，你重复发送数据 100 次都在同一个地方出现错误的可能性也是存在的，只是概率太小罢了。校验可以让误码率做到足够小，数据够多 TCP 也可以翻车，Amazon S3 在 2008 年 7 月就遇到过，单 bit 反转导致了一次严重线上事故。

tcp crc+应用层校验和比如 tls aead 。

@liuminghao233 @nicebird
请教一下，为什么你们强调 AEAD 呢？我记得即使非 AEAD，TLS 协议也设计能保证消息完整性啊，虽然消息验证码效果可能介于 TCP checksum 跟 AEAD 就是了。

@walsh 是数据位的单 bit 和校验位同时反转吗

@shansing 因为现在都用 aead 了
只要对数据做了 hash 就行
比自带的 crc 要好不少

@whileFalse 不清楚具体情况，一种可能是校验后的数据发生反转，二种可能是 checksum 也不是完全可靠的刚好碰撞上通过校验了

楼主是不是应用层代码遇到了什么无法解决的 bug，然后想甩锅给 tcp ？（ doge

一般基本的应用不需要考虑这些，tcp 有 crc 的校验，如果是 https 的话那就更安全了，毕竟 TLS 层又做了一次。
不过 tcp/udp 的 crc 校验确实出了名的弱，尤其是由于网络设备（例如交换机）的故障导致一直在随机 flip 一些 bit 的话，混过 crc 的概率并不低。近期读了一篇公司内部的 Postmortem 就是讲这样的事故，错误的数据被接受甚至处理了。

TCP 虽然没问题，会丢弃不通过检验的数据重传，但是
http 里的，很容易因为网络发生变化，很多流氓 js 就是这么注入的，注入虽然不是修改，但跟修改大同小异

实际上我见过 bit 翻转的情况

tcp 的 crc 强度不够，不能校验 2bit 及之上的翻转
内存 bit 也可能翻转

强一致性的系统最好在传输过程中增加 HMAC 校验数据