网络传输协议没法 100%检出帧和报文段的比特差错，那应用层可能接收到出错的数据而且不知情?

校验用的 CRC32，的确是有可能出错的。但是逐层校验上来出错的概率其实不是非常大。更大的风险存在于被中间人恶意篡改的可能。我觉得是需要在应用层进行校验的，当然也要看数据的用途。

@ZRS 出错的概率是什么数量级呢?比如银行金融等行业，即使出错的概率很低，但是一遇上就可能造成严重问题。
应用层每次校验的话会不会比较麻烦

就现实情况来说，大多都会需要多帧链路层包才能发送一次请求数据，再者嘛，发送接收端无法要求或者保证中间节点都校验了，所以应用层完整性建议几乎是必须的，如果接收方不做校验那么自然无法区分正确与否，也许本来就是这样的呢

@coderqbc 概率这个我不太清楚，只是从原理上考虑，只靠 TCP/IP 是无法保证数据的完整性和不可篡改性的。要实现这点有很多现成的轮子，比如 TLS，不要自己造。

链路层用的 CRC 不熟，网络层和传输层用的则是对所有 16 位比特求和取反码的校验和，具体实现可以看 RFC 1071，粗略瞟了眼里面提供了一个未检测到出错的可能性边界 2^-16
由于网络层的校验和只是校验数据报的报头，而传输层才是校验整个报文段，所以说层层校验上来也够呛，但是应用层的数据如果要紧的话，应该通过 TLS 来传，会再加一层完整性校验，还提供数据安全和端点校验

@sujin190 实际开发中，应用层貌似不会校验吧，比如 http 表单传输，服务端一般直接取客户端传的值做业务处理

@coderqbc
现在都 https+前端各种骚操作传数据了。。。谁还 http 发表单。。。

@ZRS TLS 是不是只要数据有改动(包括篡改或"校验和"未检出差错导致数据的改动)都能发现?

@coderqbc tls 是数据有篡改根本解不了密。。。

我记得之前 aws 因为错误的网络数据导致了一次大规模的网络故障

@cxtrinityy 看来只能应用层再做校验或者 SSL/TLS 连接了

这个就是一个 tradeoff，如果你的数据绝对不允许错误那就需要添加多层校验

@kokutou HTTPS 一般只是客户端到 web 服务器之间，但是 web 服务器到应用服务器(比如 PHP)、应用服务器到 Redis 数据库之间的链路很多只是普通连接

@misaka19000 大多数业务一般都不会考虑这么深

@est tls 是比较好的方案，不过改造客户端和服务端使用 tls 会不会比较麻烦

@coderqbc
你的业务如果需要，那么不考虑这么深就是不合格。
大多数业务不考虑这么深是因为不需要而已。