我做了几年网络通信中间件，有一个很深的体会：很多项目刚开始用现成的序列化框架和通信框架，能跑、能联调，但随着并发上来、需求变多，总会被几个问题卡住——协议不统一、粘包拆包处理混乱、排障困难、性能上不去。最后兜兜转转，还是回到“自定义一套消息协议 + 基于Netty做编解码”这条路。

这篇内容我就把从协议设计、编解码实现到实际解析应用的全过程整理出来。它不是教科书式的理论复述，而是我实际打磨项目时踩过坑、验证过的一套方案。如果你正在做IM、游戏服务端、物联网网关，或者任何需要自定义TCP通信的中间件，这篇内容可以直接拿去参考。

1. 协议设计：先定规则，再谈实现

1.1 为什么不用现成框架，而要自定义协议

很多团队一开始图省事，直接用字符串分隔符、或JSON做TCP消息体。前期联调确实快，但到了生产环境问题会一个个冒出来：JSON解析慢、消息边界不清晰、调试靠肉眼翻日志、加字段还要兼容老客户端。

自定义协议的价值不在于“自己造轮子”，而在于可控。线上出问题时，一个16进制dump就能定位问题；新增业务字段时，只要版本号管理好，老客户端不升级也能兼容；高并发场景下，二进制协议比文本解析少好几轮内存拷贝和字符转换。

我这边有个模拟项目X，早期就是JSON over TCP，上线后峰值5000连接时，GC压力大得离谱，每次协议升级还容易解析出错。后来换成自定义二进制协议，同样的业务量，CPU占用降了接近四成，排障效率也高了很多。

1.2 协议字段规划：每个字节都要有明确职责

自定义TCP协议的标准做法，是采用**“固定头 + 可变体”**的结构。我比较常用的一种设计是这样的：

这套结构里，固定头一共14字节。为什么魔数要4字节？2字节其实也够用，但4字节可以让报文的辨识度更强，抓包时一眼认出来是自己协议的包。版本号放1字节，正常情况下够用，除非你一个礼拜升级三次协议。

命令字为什么要单独占4字节？有些团队把命令字塞进数据体里，解析时就要先拆业务体再判断路由，add一个额外的分支，没必要。命令字独立设计，解码器可以直接根据它决定后续的handler，性能更高，语义也更清晰。

数据长度是整个协议里最关键的一个字段。解码器依赖它来分割粘包和半包。这里有个小细节：长度字段我建议只表示数据体长度，不含固定头。这样计算时直接data = msg - header_cursor，逻辑最简单，排查问题时也直观。

1.3 字段顺序和字节序：细节决定兼容性

字节序问题，在跨语言端接入时特别容易踩坑。 Java、Go这些服务端语言默认大端序（Big-Endian），而很多嵌入式设备、部分客户端SDK默认小端序（Little-Endian）。协议规范里如果不写明“大端序”，联调阶段就会出现一种神奇的bug：对方发来的报文，你解析出的长度是几百MB。

我吃过这个亏，联调时对方用C++写的客户端，结构体直接memcpy发送，本机是小端序，我这边按大端序解析，握手包都对不上。后来协议文档在开头就标注清楚：所有字节序统一使用大端序，并在设计上保持所有基础类型统一走大端编码，从根上断了这个隐患。

字段顺序上，魔数放最前面是行业惯例，起“敲门砖”作用。有的协议把长度放第一个字段，也不是不行，但调试时看起来没那