TCP 为啥是可靠的？

[phpIsNumberOne]

我说的可靠是指差错、如比特翻转的，而不是不可达之类的。 1.TCP 包校验和只用 16 个比特，我们一般的摘要都要 128 以上来保证可靠，所以 TCP 包是否也会出现差错，不是那么的可靠？ 2.如果一问是肯定的，那么基于 TCP 的、比如 HTTP 有额外做校验吗？

[phpIsNumberOne]

我说的可靠是指差错、如比特翻转的，而不是不可达之类的。
1.TCP 包校验和只用 16 个比特，我们一般的摘要都要 128 以上来保证可靠，所以 TCP 包是否也会出现差错，不是那么的可靠？
2.如果一问是肯定的，那么基于 TCP 的、比如 HTTP 有额外做校验吗？

[phpIsNumberOne]

要是一问是肯定的，那 TCP 可靠这种说法未免也太误导人了

[zhs227]

1. 校验只判断对错
2. 从 TCP 往下层还有链路层纠错
3. 错了的直接重传了

[Jooooooooo]

checksum 错了重传

不过像目前每层都有校验的情况下, 某些校验可能是多余的

[keepeye]

网络层校验只是简单的吧，而且也不能排除被拦截修改啥的。设计协议的时候也要加个应用层校验

[wanguorui123]

https://www.cnblogs.com/my_life/articles/5367814.html

[araaaa]

会重传

[zuiluo]

从传输数据的角度来看，一系列的差错检测（例如 RCR 校验），确认，重传，超时重发，序列号 足以应对（也只能应对）数据传输不会因为各种网络波动，随机 /冲击噪声导致数据发生丢失或错误。

但不能保证你的数据一定是正确的，从安全方案的角度来看，你还需要进行签名，摘要，授权，加密 /...，才能保证数据传输不会被监听 /篡改 /替换

[love]

你要这么说当然是有可能出错的，但一个包就上 128 以上也太浪费了。
上层协议应该也能防这种情况，比如 https 加密流错一个字节应该就不行了吧

[Microkernel]

会出现，都是概率问题。明文 HTTP 没有额外校验了，HTTPS 的话 TLS 有

[phpIsNumberOne]

@zhs227
@Jooooooooo
会有出错但校验不出来的情况

[walsh]

世界上没有信噪比无穷大的信道，也就没有完全可靠的协议，只有 99.99%可靠的协议，时间足够长不管多小的可能性发生概率都接近无穷大，也就是墨 菲 定 律，设计目标就是把这个发生概率的时间延长到超过宇宙重启的时间。

[learningman]

建议阅读自顶向下，IP 包也有 checksum，底层的电流啥的都有纠错的

[zhs227]

@phpIsNumberOne 如果这个错误对你的影响是 Critical 级别的，那应该由应用层校验。

任何事情都有例外。md5 也有碰撞。sha1,sha256 这些，任何哈希算法，只要是校验长度小于原文长度，因为不具备完整信息，都是有可能出错的，最终反映在数学上都是一个多对一的映射。校验长度大于或等于原文长度又没有太大的实用价值。

一般来说我们做了 md5，而且 md5 也对了，就认为是没有问题的。有些下载网站提供多种哈希供校验，也是如此。

如果链路层，TCP 层的内容都错了， 但是两层的 CRC 又同时都是能通过的，这个概率在可靠性要求不高的场合可以忽略不计。

[lysS]

1.是，TCP 的校验和可信度较低，校验出错会重传，出错但是没有校验出来的情况在当前网络环境概率极低，属于可接受范围。这种可能出现情况极低一方面是由于校验设计合理，另一方面也是由更底层的提供，比如像扩频通信技术，可以是在信噪比远小于 1 的情况提供可用的信道

2.HTTP 没有，HTTPS 有

所有都是概率的问题，在应用层面算概率，在物理层面上算信噪比；都没有绝对可靠的；除了数学。

[enihcam]

都不在一层，各司其职。

[xumng123]

问度娘 ji ke

[zhangsanfeng2012]

TCP 的可靠是指接收端会通知发送端，它收没收到包

[ryd994]

1. 防随机传输错误，不防恶意伪造。随机错误能刚好把 CRC 翻回来，概率很小
摘要要 128 位以上是为了防恶意伪造或者碰撞攻击
2. HTTP 没有。其他协议按需要可能有。

最重要的是 CRC 在硬件里实现非常简单。所以这是一种高性能低成本的办法。如果你需要 /愿意付出更多性能成本，你可以在上层实现更复杂的加密 /校验。比如 TLS

[ExplorerLog]

首先更低级的以太网帧就有 32‑bit 的 CRC 校验