我说的可靠是指差错、如比特翻转的，而不是不可达之类的。 1.TCP 包校验和只用 16 个比特，我们一般的摘要都要 128 以上来保证可靠，所以 TCP 包是否也会出现差错，不是那么的可靠？ 2.如果一问是肯定的，那么基于 TCP 的、比如 HTTP 有额外做校验吗？
This topic created in 1928 days ago, the information mentioned may be changed or developed.
 |
1
phpIsNumberOne OP 我说的可靠是指差错、如比特翻转的，而不是不可达之类的。
1.TCP 包校验和只用 16 个比特，我们一般的摘要都要 128 以上来保证可靠，所以 TCP 包是否也会出现差错，不是那么的可靠？ 2.如果一问是肯定的，那么基于 TCP 的、比如 HTTP 有额外做校验吗？ |
|
2
phpIsNumberOne OP 要是一问是肯定的，那 TCP 可靠这种说法未免也太误导人了
|
 |
3
zhs227 Feb 2, 2021
1. 校验只判断对错
2. 从 TCP 往下层还有链路层纠错 3. 错了的直接重传了 |
 |
4
Jooooooooo Feb 2, 2021
checksum 错了重传
不过像目前每层都有校验的情况下, 某些校验可能是多余的 |
 |
5
keepeye Feb 2, 2021
网络层校验只是简单的吧，而且也不能排除被拦截修改啥的。设计协议的时候也要加个应用层校验
|
 |
6
wanguorui123 Feb 2, 2021  1
|
 |
7
araaaa Feb 2, 2021 via iPhone
会重传
|
 |
8
zuiluo Feb 2, 2021
从传输数据的角度来看，一系列的差错检测（例如 RCR 校验），确认，重传，超时重发，序列号 足以应对（也只能应对）数据传输不会因为各种网络波动，随机 /冲击噪声导致数据发生丢失或错误。
但不能保证你的数据一定是正确的，从安全方案的角度来看，你还需要进行签名，摘要，授权，加密 /...，才能保证数据传输不会被监听 /篡改 /替换 |
 |
9
love Feb 2, 2021
你要这么说当然是有可能出错的，但一个包就上 128 以上也太浪费了。
上层协议应该也能防这种情况，比如 https 加密流错一个字节应该就不行了吧 |
 |
10
Microkernel Feb 2, 2021
会出现，都是概率问题。明文 HTTP 没有额外校验了，HTTPS 的话 TLS 有
|
|
11
phpIsNumberOne OP |
 |
12
walsh Feb 2, 2021 1
世界上没有信噪比无穷大的信道，也就没有完全可靠的协议，只有 99.99%可靠的协议，时间足够长不管多小的可能性发生概率都接近无穷大，也就是墨 菲 定 律，设计目标就是把这个发生概率的时间延长到超过宇宙重启的时间。
|
 |
13
learningman Feb 2, 2021 via Android
建议阅读自顶向下，IP 包也有 checksum，底层的电流啥的都有纠错的
|
|
14
zhs227 Feb 2, 2021
@phpIsNumberOne 如果这个错误对你的影响是 Critical 级别的，那应该由应用层校验。
任何事情都有例外。md5 也有碰撞。sha1,sha256 这些，任何哈希算法，只要是校验长度小于原文长度，因为不具备完整信息，都是有可能出错的，最终反映在数学上都是一个多对一的映射。校验长度大于或等于原文长度又没有太大的实用价值。 一般来说我们做了 md5，而且 md5 也对了，就认为是没有问题的。有些下载网站提供多种哈希供校验，也是如此。 如果链路层，TCP 层的内容都错了， 但是两层的 CRC 又同时都是能通过的，这个概率在可靠性要求不高的场合可以忽略不计。 |
 |
15
lysS Feb 2, 2021
1.是，TCP 的校验和可信度较低，校验出错会重传，出错但是没有校验出来的情况在当前网络环境概率极低，属于可接受范围。这种可能出现情况极低一方面是由于校验设计合理，另一方面也是由更底层的提供，比如像扩频通信技术，可以是在信噪比远小于 1 的情况提供可用的信道
2.HTTP 没有，HTTPS 有 所有都是概率的问题，在应用层面算概率，在物理层面上算信噪比；都没有绝对可靠的；除了数学。 |
 |
16
enihcam Feb 2, 2021 via Android 1
都不在一层，各司其职。
|
 |
17
xumng123 Feb 2, 2021 via iPhone
问度娘 ji ke
|
 |
18
zhangsanfeng2012 Feb 2, 2021
TCP 的可靠是指接收端会通知发送端，它收没收到包
|
 |
19
ryd994 Feb 3, 2021 via Android
1. 防随机传输错误，不防恶意伪造。随机错误能刚好把 CRC 翻回来，概率很小
摘要要 128 位以上是为了防恶意伪造或者碰撞攻击 2. HTTP 没有。其他协议按需要可能有。 最重要的是 CRC 在硬件里实现非常简单。所以这是一种高性能低成本的办法。如果你需要 /愿意付出更多性能成本，你可以在上层实现更复杂的加密 /校验。比如 TLS |
 |
20
ExplorerLog Feb 3, 2021
首先更低级的以太网帧就有 32‑bit 的 CRC 校验
|
 |
21
julyclyde Feb 4, 2021
tcp 可靠是针对丢包情况来说的
有重传机制 甚至能做到“死要见尸”，能明确引起高层 API 出错 |
Select Language