1. 消息定长 (Fixed-Length Messages)原理发送端和接收端约定每一个消息的长度都是固定的比如 1024 字节。实现如果发送的数据不足 1024 字节就用空格或\0补齐接收端每次严格读取 1024 字节算作一个完整的消息。优点极其简单不需要复杂的解析逻辑。缺点严重浪费网络带宽。如果你的应用大部分时候只发送几个字节的短消息强行补齐到 1024 字节会导致网络吞吐量大打折扣。适用场景只在非常特定的硬件交互或定长指令集场景中使用。2. 特殊字符分隔符 (Delimiter-Based)原理在每个完整的消息末尾附加一个约定的特殊字符或字符串作为边界标识。最经典的就是\n或\r\n。实现接收端将接收到的流数据缓存起来不断扫描缓存直到发现约定的分隔符就把分隔符之前的数据截取出来当作一个完整消息。优点空间利用率高没有长度限制。缺点不适合传输二进制数据比如图片、音视频、序列化后的 protobuf 数据。因为二进制数据内部大概率会随机出现你约定的“分隔符”导致消息被错误截断。如果非要传就必须对数据体内部的“分隔符”做转义非常麻烦。适用场景文本协议如 HTTP 请求头、FTP、Redis 文本协议。3. 包头加包体长度 (Length-Prefixed / TLV 结构) ——工业界最标准解法原理将消息分为 Header头部和 Body包体。在固定长度的 Header 中专门拿出一个字段来存储后续 Body 的真实字节长度。这就是著名的TLV (Type-Length-Value)结构。实现流转重点面试官最爱听的拆解步骤接收端先固定读取 Header 的长度比如固定的 4 字节整数。将这 4 个字节解析成整数 $L$得知接下来马上要到来的包体有 $L$ 字节。接收端继续在缓存中读取确切的 $L$ 字节数据。读满 $L$ 字节后一个完整的消息就拼装成功了。优点完美解决二进制数据的传输问题精确高效是现代网络通信的标配。缺点实现相对复杂需要维护接收状态机当前是在读头部还是在读包体。适用场景绝大多数自定义 RPC 协议、游戏后端、IM 聊天软件。