🚀 tcp粘包问题处理
tcp粘包问题处理.png
以上图的协议结构,来举个粟子:
🌰 1.我们收到完整的一个协议串为hex码为:
232301314731424c35325037545231313535323001000000
🌰 2.对应的拆解一下,各项数值为
| 列名 | HEX值 |
|---|---|
| 起始符 | 2323 |
| 命令单元 | 01 |
| 车辆识别码 | 314731424c353250375452313135353230 |
| 数据加密方式 | 01 |
| 数据单元长度 | 0000 |
| 校验码 | 00 |
🌰 3.而我们收到粘包的时，或者半包的情况是这样的。
- 3.1 🎯 场景1
一次性接收收到完整的两个数据串:
232301314731424c35325037545231313535323001000000232301314731424c35325037545231313535323001000000
- 3.2 🎯 场景2
第一次只收到半包的数据串:
232301314731424c353250375
- 3.2 🎯 场景3
第一次收到一个半的数据串:
232301314731424c35325037545231313535323001000000232301314731424c35325037545231
第二次会收到剩余的数据串:
313535323001000000
🌰 4. 第三点就是我们收到粘包，半包，大概就这些情况。
一般处理的方法也很简单，就通过起始符处理分割一下就可以。这个协议在定义的时候，就有考虑到了。
☕ 如:遇到场景1
通过起始符进行分割，就可以拆成两个单独的包了。
☕ 如:遇到场景2
包未完整,继续等待,阻塞不处理就好.
☕ 如:遇到场景3
通过起始符进行分割，可以拿到第一个包。
再继续等待后面的数据包过来，这样第二个包也就完整了。
☕ 这种具体代码中处理的时候，流程大概是这样:
前提补充一下:
一般我们设计系统时,线程分为两部分
一部分用于专门处理接收处理.(这部分的线程数量一般设置为CPU核心数的两倍.).下文称收包线程
一部分用于专门处理解析处相关业务处理..下文称业务线程
4.1 "收包线程"-->读取流的数据串，
4.2 "收包线程"-->检查数据串格式
4.3 "收包线程"-->如果满足一个整包，"收包线程"就丢给"业务线程"去处理.
4.4 "收包线程"-->如果不满足,将读标重置为读取之前就好.
(每次也要注意去检索一下缓冲区，以防垃圾包太多过来让缓冲区爆了，程序挂了）
