分享文章： TCP 粘包？ TCP 警察什么梗

[DonaldY]

文章地址：TCP 粘包？ TCP 警察什么梗

从 v2 学到很多，按照自己理解总结了下。0.0

[nothingistrue]

四层传输层 TCP 协议流式，七层应用层通过缓冲区映射成数据包处理，说粘包并没错。但是“粘包”这个词是生造的，用于新手快速理解还可以，再深入点就该换成“分帧取帧”，或者“帧解码”。

[qrobot]

@nothingistrue #21 你确定你理解的是楼主所说的问题, TCP 帧在应用层是不关心的。 而所谓的 “判断写入的字节什么时候已经达到的末端” 是需要自己解析的

而且你说的 “分帧取帧”，或者“帧解码”。 是指什么？ 说的是 解析 RFC 793 里面的 `TCP Header Format` 吗？ 很抱歉，在用户使用协议上，没有权限读取对应的 `TCP Header Format` ， 要么使用 tun/tap 等虚拟网卡， 要么使用 pcap/winpcap/npcap 或则 win10 的驱动网络拦截。 但是这些 TCP 协议的操作，往往都不是 TCP 使用用户来进行操作的， 楼主很明显是在使用 TCP 协议， 而不是解析 TCP 协议

[easonzh]

@Rache1 什么叫字节文化啊（后仰

[tool2d]

HTTP1.0 好像就是根据 connection:close ，来判断 HTML 是否已经完全传输完毕。

也不是所有的 TCP 都有 content-length 属性，在那个 IE 时代，经常遇见下载到一半的网页突然断开。

[someonedeng]

在 TCP 这层不用考虑这个

[lysS]

TCP 有所谓的“粘包”是使用情景出错了，你把两个以上的数据报放在一个 tcp 流里面传输了；正常的应该是一个“包”一个连接。像 HTTP 的长连接就是这种情况，不过 HTTP header 有 length 可以解决“粘包”

[nothingistrue]

@qrobot #22 网络通信是七层，不要死扣在传输层 TCP 协议这一个上。帧的英文是 Frame 。还有不要再回复了，这贴是给楼主的内容农场引流的，正方反方意见都不重要，都会给楼主引流。

[reallynyn]

他们说的 tcp 粘包，应该是指 nagle 算法吧。。

[oneisall8955]

/go/water

[exiledkingcc]

TCP 没有包，但是这篇文章非要把指出这个事实的人扣一个“粘包警察”的帽子，似乎还有点得意。
基于错误的概念讨论一大堆东西都是没有意义的。
就这篇文章来说，TCP 的包是啥它自己清楚吗？
是你调用一次 socket write 的数据，还是 wireshark 抓包看到的一个 TCP 的条目？还是你应用层自己定义的逻辑结构？
概念都不定义清楚就自说自话，就是一堆废话。

[TsubasaHanekaw]

掘金在某些人看来已经是内容农场了么 哈哈哈
国内要啥社区生态啊

[boywang004]

就喜欢看这种话题，掐！打起来！别停手！
小马扎、花生米已经就位啦！

[qwerthhusn]

奥山 YY 来人

[hankai17]

之前也看过很火的几个黏包警察的帖子
面试的时候也被问过 大概就是解决黏包的方案 比如 <content-length>[content]

[keepeye]

其实说的不是报文粘包，而是消息解析的问题

[tangchi695]

我不管，我的 TCP 就是要粘包[手动狗头]

[fkdtz]

TCP 只保证可靠数据传输，没说把数据一个个拆开好给你，这件事应该由上层协议负责处理。
如果是这样的话，你也可以提出这样一系列问题：
如何解决 IP 协议不能可靠数据传输的问题？常规解决方案是用 TCP ；
如何解决 Ethernet 协议与全球服务节点连接问题？常规解决方案是使用 IP 协议；
...
回过头来看，这正是「分层」思想的奥义所在啊，每一层只处理好自己的事儿。

[MrLin]

·粘包·真是误人子弟，还有一大堆捧的，还在那里抠概念，错的就是错的

[djoiwhud]

@reallynyn

和 nagle 没任何关系。无论怎样，接收端读都可能会读取不定次数写的内容。

我无法理解这里在嘲讽 tcp 粘包的什么问题。这确实是工程中需要处理的内容。

[byte10]

@fkdtz 这解释到位，可以。

好几年前我一直认为 tcp 粘包是一个非常复杂的事情，一直没认真去看，后来要面试就专门去看 TCP 粘包。tmad 差点颠覆我的认知，这算个屁粘包，不知道哪个土鸡 提出来的。后来终于看到 V2 原来也有很多人不认可这个事情，那我就放心了，原来我的认知没错，某些人的问题。。。