@qnnnnez

我同意你说的, 只是我看评论区喷楼主给我的感觉,
就像是一堆研究生拿着科研的方式来讨论初中课本上的一条理论是否正确

某个层次的知识肯定需要一定程度的概括, 便于理解
概括肯定有一定的信息丢失(比如极端情况)

然后一帮人在喷楼主丢失了信息而忽略的要表达的东西本身

@bombless
一张图把它要表达的表达就行了, 你说它没有把其他细节表达出来就是错的, 我是不赞同的
就比如第二张图, 它就是想表达, 读写都需要先 经过 甚至重点强调了 分别经过读写 buffer
这张图就可以了
你不是在看论文, 不需要那么讲究的好么
那它没有表达其他东西, 不能说它错吧?

@bombless 看你怎么理解这个图吧
在 tcp 报文 这个角度, 确实是把 Data 业务层的"包" 拆掉了
一个"报文" 包含的 业务包 的个数和完整性不确定 就是 拆和粘
在这个"报文"层面这个图没问题

只不过 tcp 协议的报文对业务层透明, 对业务层只表现出 "流"特性
所以根本也没有所谓报文拆了业务包的事情
在这个角度, 这图就是错的

这图把要发的那么多字节在 tcp 层实际怎么传输的画出来了而已
所以很多人看图不看字, 就自然的以为是 tcp 报文导致楼主说的问题

但是其实楼主的文字里本来就说了, 缓冲区, 缓冲区, 缓冲区

===
为什么会发生 TCP 粘包、拆包
应用程序写入的数据大于套接字缓冲区大小，这将会发生拆包。
应用程序写入数据小于套接字缓冲区大小，网卡将应用多次写入的数据发送到网络上，这将会发生粘包。
进行 MSS （最大报文长度）大小的 TCP 分段，当 TCP 报文长度-TCP 头部长度>MSS 的时候将发生拆包。
接收方法不及时读取套接字缓冲区数据，这将发生粘包。
===

@bombless 早就说了...根本原因是 缓冲区

@iwtbauh 可能应用程序想一次性读取 512 个字节但是剩下的数据只有 100 字节了

那这个不就是 我的 512 被拆成 100 和 xxx 了吗?

@iwtbauh 根本没必要故意隐藏“文件描述符”, 一个 read 接口肯定有这个, 隐含掉就看不懂?

读取到的长度=read(文件描述符, 缓冲区, 缓冲区长度)
这个 api 就是 "块" "包" 式的接口
每次操作返回 读取到的长度 这一块, 1B 也是一块

@bombless 你自己都说要拼接了, 为啥要拼接? 拆了才要接啊

@bombless 我已经说了, 问题不是 tcp, 而是缓冲区

@bombless 我为啥不关注啊?
读取到的长度=read(文件描述符, 缓冲区, 缓冲区长度)
"读取到的长度" 跟 我想要的长度不一定一样啊

@iwtbauh 那你有没有想过, 为啥 这个接口 是
读取到的长度=read(文件描述符, 缓冲区, 缓冲区长度)
它为何有个 读取到的长度 ?
而不是
read(文件描述符, 缓冲区, 我就要这么长不读够不返回) ?

@iwtbauh 你说的接口跟我的没区别, 我的最大长度说的就是 缓冲区长度, 实际长度 就是 read 到的"实际"长度

@bombless
第三张图?
Data 理解成是一个业务层定义的包 没问题啊
tcp 是流式, 但是它也不完全是像水一样的,
水的最小流动单位是 "一个原子??"
tcp 的"流动"最小单位是 "报文", 也还是"一块"

Data 跟 报文的大小不一致, 那么报文到达缓冲区之后
某个特定时刻 缓冲区内部 Data 的个数和完整性是不确定的
所以你如果按缓冲区 "整个" 来读, 那 Data 就肯定不完整

这个根本不是 tcp 是不是流式的问题, 而是 缓冲区把 流 "块" 化了

所以关键是使用缓冲区这个东西的方式
按"块"来用 "缓冲区" 就有问题
如果用流式来用缓冲区就没问题

@zhicheng
我同意 "tcp 这种流协议就应该用流式 api"
我也同意 "2018 年了不应该还在讨论粘包"

但是我不同意 "tcp 不存在这个问题"
因为一开始根本没有 流式 api

所以不要拿着 2018 年的 api 去嘲笑 2000 年的 api

@zhicheng

(用)tcp(缓冲区读取的使用方式)(实现业务层的包协议) 会有(被缓冲区)粘(业务层的)包问题.
这样够确切了吗?
理解楼主要表达的意思就好了, 拿一些不相关的东西喷楼主是为啥呢?

@zhicheng
楼主说的是: (用)tcp(这种流协议)(实现业务层的包协议) 会有粘(业务层的)包问题.

所以你们一再强调 tcp 没有包是为啥? 楼主什么时候说 tcp 有包了?

楼主帖子里, "为什么会发生 TCP 粘包、拆包" 说的清清楚楚, 哪一句说 tcp 包了?

@zhicheng 楼主的题目是: (用)tcp(做业务会有)粘包问题

然后一堆人在教楼主 tcp 是流式协议...

@zhicheng 你到底拿上层高特性的 api 在较什么劲?
底层能跑的开这种方式收数据吗? 动不动流式协议? 你硬件缓冲区是流式的吗? 你硬件缓冲区有 1TB 吗?

拿着一堆流式协议高级的 api, 然后说"不存在拆和粘的问题, 因为我是流式的" ?

实际长度=read(缓冲区, 最大长度) 底层就这个接口,
在这段代码层面, 每次 read 完了, "缓冲区" 就是这一段代码这个层面的"包"
这个层面的"包" 跟应用层面的 "包" 不一一对应, 所以出现 两个层面的"包" 的拆和 粘的问题

就算 tcp 是个流, 你有一堆高级特性的 api, 你就骄傲了?
永远还是会遇到 2 个层面的包无法一一对应的问题
硬件缓冲区是不是"包" ? 现在硬件缓冲区能当"流"对待了? 总线不也还是一次按总线位数取"一块"?

拿着一堆高级特性 api 在嘲笑底层特性的 api 用法, 你们到底是在骄傲个啥?