这是一个创建于 1672 天前的主题，其中的信息可能已经有所发展或是发生改变。
如题，想到一个问题，即排除三次握手与四次分手所保证的连接可靠性后，服务端能否确保与客户端接收数据完全一致？
比如客户端发送了 aaaaaaa，被拆分成三个封包发送，而服务端接收到该字符串后，虽然能确保按顺序接收，但会不会因为网络不稳定或硬件因素影响，导致接收数据变成了 aaabaaa ？
看了一些文章，tcp 对于数据本身的校验采用反码求和的算法，通常我们认为确保可靠都是计算 hash 之类的，这个反码求和似乎并没有 hash 那么靠谱，按照我的理解，反码求和当中比如同时有 2 个以上的 bit 改变，是可能导致求和结果相同，但具体内容不同的。
======
是否是我理解错了？还是 TCP 确实无法保证完全相同，业务上的校验需要应用层进行进一步校验？
第 1 条附言 2021-04-01 22:57:38 +08:00
其实更有意思的一个问题是...据我所知 Redis 就是在 tcp 上面架了个 redis 协议，而且默认是不开启 tls 的...那是否意味着 redis 大量存取数据过程中可能因为网络波动导致数据不可靠。。。
 | 1 WIN2333 2021-04-01 17:54:41 +08:00 无论是哪个 Checksum 校验，都是只防君子，不防小人 https://www.zhihu.com/question/20184058,这个回答可以解答你的问题 |
 | 2 iyaozhen 2021-04-01 17:55:27 +08:00 有 seq number 和 ack tcp 协议本身还有很多字段 部署 aaa 这些内容 |
 | 3 opengps 2021-04-01 17:58:02 +08:00 业务上的校验是不可避免的，不如粘包问题，tcp 自己是解决不了的 |
| 4 WIN2333 2021-04-01 18:02:04 +08:00  4 tcp 没有粘包问题，tcp 是基于字节流传输的，不要被粘包这个词误解了，就不应该有这个词，字节流传输的边界问题本来就应该是应用层处理的 @opengps |
 | 6 love 2021-04-01 18:39:32 +08:00 via Android 可能性非常小。何况重要的情况都用 HTTPS，额外加了一层可靠校验 |
 | 7 Aliencn 2021-04-01 19:13:46 +08:00 TCP 有数据校验的功能，Google 一下“TCP md5”就能查到相关资料。 不过现在大多数都是用 TCP 来保证数据可靠性，SSL/TLS 保证数据完整性吧。 |
 | 8 wanguorui123 2021-04-01 19:18:31 +08:00 |
 | 9 LeeReamond OP @Aliencn @wanguorui123 感谢，看了一下资料，总结来说问题确实存在，而 TCP 也确实有 hash 校验选项，只不过默认不开启。Linux 内核提供了 tcp md5 的功能，但手册语焉不详，需要传入指定内存结构的结构体，导致类似 java 之类的语言里启用传输层的校验似乎比较困难。 解决方案的话，本身下层还有校验，我本人提问的时候也不觉得这是个高发情况，所以非关键业务可以忽略。特殊业务场景，可信网域的话可能有特殊需求，比如 tls 成本太高的话可以应用层自己实现，使用一些快速哈希之类的。 |
 | 10 3dwelcome 2021-04-01 20:56:43 +08:00 这问题有意思，我去 google 查了一下( http://noahdavids.org/self_published/CRC_and_checksum.html) 文章里确切的说，用百度云下载数据，每下载 15T 数据后，会有一个随机的错误包被混入其中（ ps: 原文里是 10 亿数据包，一个包 1526 字节，相乘一下就是 15T 字节） 老外还说，15T 数据有一个 bit 出错，对大部分应用都是无感知的。也许互联网天然有容错机制。 |
 | 11 Overfill3641 2021-04-01 21:03:02 +08:00 感觉应用校验也是有需要的（重要的话），比如 HTTP 经常下了损坏文件，BT 下个几十 GB 丢弃几十几百 MB 。 |
 | 12 bengol 2021-04-01 21:50:19 +08:00 via Android 和你确认是的，因为我们生产环境确实出现了。 |
 | 13 ZRS 2021-04-01 23:02:49 +08:00 via iPhone 绝对的可靠是不能保证的，需要应用层自己校验。其实套个 TLS 基本解决问题了 |
 | 14 Sanko 2021-04-01 23:12:47 +08:00 via Android crc32 |
 | 15 acerlawson 2021-04-01 23:22:10 +08:00 via iPhone end to end argument |
 | 16 ysc3839 2021-04-01 23:40:16 +08:00 据说当年 RAR 流行是因为支持恢复记录，加上 http 下载的错误率较高，有恢复记录可以避免重新下载。 当然这只是据说，不过为了保险起见，要保证数据完整性的话还是上 TLS 吧。 |
 | 17 lujjjh 2021-04-02 00:22:08 +08:00 via iPhone Ethernet FCS |
Select Language