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

[coderqbc]

0.看到某计算机网络教材提到:
帧(数据链路层)、报文段 /数据报(运输层)是通过“校验和”来检测传输的数据是否发生了差错，若有则丢弃。

1.存在非常非常小的概率（教材中没有给出具体概率）：
即使发生了差错，“校验和”没有检出错误。这样的概率大概有多大呢？

2.应用层编程是否需要考虑这种上述小概率事件导致发送和接收的数据不一致？
比如假如发送的数据是 1，传输过程发生差错并且没有检出，数据变为 2，应用层接收到的数据变为了 2，而且不知道这是发生差错的数据。

[ZRS]

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

[coderqbc]

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

[sujin190]

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

[ZRS]

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

[cxtrinityy]

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

[coderqbc]

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

[kokutou]

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

[coderqbc]

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

[est]

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

[misaka19000]

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

[coderqbc]

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

[misaka19000]

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

[coderqbc]

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

[coderqbc]

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

[coderqbc]

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

[Cu635]

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