如果只用 Nginx 等现成的 HTTP Server 搭建 HTTP 服务，不自行建立 TCP 连接，是否就不用考虑 TCP 粘包这类传输层的问题？

[drymonfidelia]

[franswish]

很久很久以前还是学生的时候，搞嵌入式设备测试，用串口做上下位机通信，每帧报文几十字节不等，数据周期性发送，间隔固定且可调（从几百毫秒到数秒），简单做一个定时接收逻辑即可满足需求，不需要再做应用层根据帧头帧尾校验分帧。
后来用以太网口，走 TCP 协议做差不多的事，但是数据量大了很多，通信也变成非周期性且短间隔的了。还按原来串口的思维去理解 TCP ，发现完全搞不定，然后才领悟了为什么数据要有帧头帧尾校验，TCP 只负责收发数据的可靠性和连续性，要用数据得应用层自己去解。
结合我自己经历，我觉得喜欢说“粘包”的怕不是像我以前认知串口的一样，发一次就是一帧所以通过调整接收逻辑能一次收到完整一帧就不用在接收端先分帧再解帧了。

[kneo]

正经回答下，不用。

[ipwx]

@franswish 不知道怎么搞定协议解析、切分消息（俗称解决粘包） = 我高中玩编程的水平。

那时候是真觉得这玩意儿也忒复杂了，怎么这么难搞。

现在嘛，不就是把 TcpConn 放到一个 Stream 里面，然后

string readNextChunk(int size) {
int nLeft = size;
string ret;
char buffer[8192];
while (nLeft > 0) {
int nRead = read(conn, buffer, min(nLeft, sizeof(buffer));
if (nRead == 0) {
break; // EOF
}
for (int i=0; i<nRead; ++i) {
ret.push_back(buffer[i]);
}
nLeft -= nRead;
}
return ret;
}

其实第一个认知更新，是在网络条件下，read(..., 8192) 不一定能给你真的读出来 8192 bytes ，你得用循环读。然后这部分写成一个通用函数（比如上面这个 readNextChunk) 就行了。用的时候

int nextMsgLength = fromLittleEndianUint32Bytes(readNextChunk(4));
string msg = readNextChunk(nextMsgLength)

[zxjxzj9]

http 都已经包了一层应用层了你怎么粘。只有自己读 tcp 字节流，把字节流拆成了一小段之后读，读不干净才会粘啊！

[codingmiao]

粘包警察是什么梗，自己 netty 写个通信，还是要考虑粘包半包的嘛

[csfreshman]

在 v2 ，关键字"粘包"自带流量………

[julyclyde]

@yolee599 tcp 并非源源不断，而是经常断。指定长度读，结果没收到那么长的数据，但是等会再读发现又有了
所以才会产生这些问题

[qbmiller]

感谢 dubbo ，让我学习了一次粘包。2.6.x 版本的 thrift 协议。