TCP 保证传输可靠是否是伪命题？

[LeeReamond]

如题，想到一个问题，即排除三次握手与四次分手所保证的连接可靠性后，服务端能否确保与客户端接收数据完全一致？

比如客户端发送了 aaaaaaa，被拆分成三个封包发送，而服务端接收到该字符串后，虽然能确保按顺序接收，但会不会因为网络不稳定或硬件因素影响，导致接收数据变成了 aaabaaa ？

看了一些文章，tcp 对于数据本身的校验采用反码求和的算法，通常我们认为确保可靠都是计算 hash 之类的，这个反码求和似乎并没有 hash 那么靠谱，按照我的理解，反码求和当中比如同时有 2 个以上的 bit 改变，是可能导致求和结果相同，但具体内容不同的。

======

是否是我理解错了？还是 TCP 确实无法保证完全相同，业务上的校验需要应用层进行进一步校验？

其实更有意思的一个问题是...据我所知 Redis 就是在 tcp 上面架了个 redis 协议，而且默认是不开启 tls 的...那是否意味着 redis 大量存取数据过程中可能因为网络波动导致数据不可靠。。。

[WIN2333]

无论是哪个 Checksum 校验，都是只防君子，不防小人
https://www.zhihu.com/question/20184058,这个回答可以解答你的问题

[iyaozhen]

有 seq number 和 ack

tcp 协议本身还有很多字段 部署 aaa 这些内容

[opengps]

业务上的校验是不可避免的，不如粘包问题，tcp 自己是解决不了的

[WIN2333]

tcp 没有粘包问题，tcp 是基于字节流传输的，不要被粘包这个词误解了，就不应该有这个词，字节流传输的边界问题本来就应该是应用层处理的 @opengps

[iyaozhen]

@iyaozhen 哦 说的不是一个事情。好像没怎么关注过数据被篡改的情况。

[love]

可能性非常小。何况重要的情况都用 HTTPS，额外加了一层可靠校验

[Aliencn]

TCP 有数据校验的功能，Google 一下“TCP md5”就能查到相关资料。

不过现在大多数都是用 TCP 来保证数据可靠性，SSL/TLS 保证数据完整性吧。

[wanguorui123]

https://www.v2ex.com/t/750528
https://www.v2ex.com/t/639845

[LeeReamond]

@Aliencn
@wanguorui123 感谢，看了一下资料，总结来说问题确实存在，而 TCP 也确实有 hash 校验选项，只不过默认不开启。Linux 内核提供了 tcp md5 的功能，但手册语焉不详，需要传入指定内存结构的结构体，导致类似 java 之类的语言里启用传输层的校验似乎比较困难。

解决方案的话，本身下层还有校验，我本人提问的时候也不觉得这是个高发情况，所以非关键业务可以忽略。特殊业务场景，可信网域的话可能有特殊需求，比如 tls 成本太高的话可以应用层自己实现，使用一些快速哈希之类的。

[3dwelcome]

这问题有意思，我去 google 查了一下( http://noahdavids.org/self_published/CRC_and_checksum.html)
文章里确切的说，用百度云下载数据，每下载 15T 数据后，会有一个随机的错误包被混入其中（ ps: 原文里是 10 亿数据包，一个包 1526 字节，相乘一下就是 15T 字节）

老外还说，15T 数据有一个 bit 出错，对大部分应用都是无感知的。也许互联网天然有容错机制。

[v2tudnew]

感觉应用校验也是有需要的（重要的话），比如 HTTP 经常下了损坏文件，BT 下个几十 GB 丢弃几十几百 MB 。

[bengol]

和你确认是的，因为我们生产环境确实出现了。

[ZRS]

绝对的可靠是不能保证的，需要应用层自己校验。其实套个 TLS 基本解决问题了

[Sanko]

crc32

[acerlawson]

end to end argument

[ysc3839]

据说当年 RAR 流行是因为支持恢复记录，加上 http 下载的错误率较高，有恢复记录可以避免重新下载。
当然这只是据说，不过为了保险起见，要保证数据完整性的话还是上 TLS 吧。

[lujjjh]

Ethernet FCS