我们从一个很常见的现象聊起。很多人在熟悉了 socket 编程的基础 API 之后会先写一个“客户端发一段字符串、服务端收下再打印”的 Demo。跑通之后立刻会面临一个绕不开的问题如果我想传的是一个结构体一个对象甚至一个带嵌套字段的订单该怎么办直接把struct用send()发过去把对象toString()之后发过去还是先把字段拼成一个字符串再发这些做法在本地能跑一旦换机器、换语言、换业务需求就崩。这一篇我就围绕着 Linux 下的 socket 网络编程把“应用层自定义协议”和“序列化”这件事掰开揉碎地讲一遍为什么你需要一份属于自己的协议协议头该怎么设计序列化方案怎么选最后再给出一个完整的登录认证协议示例附带完整可跑的 C 代码。适合刚接触网络编程、想把 socket 从“玩具”推向“真能用”阶段的开发者。1. 为什么应用层要自己设计协议直接从“内存里的结构体”到“网线上的字节流”1.1 TCP 只给你一个“字节流”而不是“消息边界”很多刚上手的人对 TCP 的抽象理解是我调一次send(fd, buf, len)对面就应该正好通过一次recv()收到同样长度的数据。实际完全不是这样。TCP 是一个流协议它只会保证你发出的字节按顺序到达对方但是“从第几个字节到第几个字节算一条消息”TCP 自己并不知道。比如你连续调用了两次send()send(fd, hello, 5); send(fd, world, 5);对端的一次recv()可能一口气收到 10 个字节helloworld也可能第一次只收到 3 个字节hel第二次才收到loworld。这跟网络延迟、对端缓冲区大小、内核调度都有关。所以“调用一次 send 对应一次 recv”是一个错误直觉。要想让接收方知道“一条消息到哪里结束”就必须在应用层自己给出答案。这个答案就是协议。1.2 别把结构体直接扔到网线上初次写网络程序的人最容易犯的错误是直接这样干struct User { int id; char name[64]; double score; }; User u {1, tom, 99.5}; send(fd, u, sizeof(u), 0);本机测试经常能通因为发送端和接收端在同一台机器上内存布局完全一致。但只要一端是 64 位系统、另一端是 32 位系统或者一个用 GCC、一个用 Clang甚至只是编译器版本不同出来的字节都可能不一样。这里有几个本质问题内存对齐结构体里int、double之间可能被编译器塞入 padding 字节。sizeof(User)在不同平台可能分别是 80、84、88。你以为发的是 struct其实发的是“带有本机私货”的二进制块。整数大小端x86 是小端序PowerPC 或某些嵌入式平台是大端序。同一个int 0x01020304内存里可能是04 03 02 01也可能是01 02 03 04。对端按自己的字节序解读数字直接错乱。指针、string、map结构体里包含指针的时候你发送的是指针地址这个地址在另外一台机器上毫无意义。std::string内部更是一堆堆指针和容量字段根本不能直接发送。所以“网络传输”要求你放弃“在内存里长什么样就传什么样”的思路转而在应用层把数据转换成一种两端都认可的、独立于内存布局的字节表示。这就是序列化要解决的问题。1.3 没有边界就没有“解析”的起点假设你决定用一个简单的分隔符来区分消息比如用\n作为消息结尾。发方把每条消息末尾加上\n收方读到\n就认为一条消息结束了。这是“行协议”像 HTTP/1.1 的 header 行或者 Redis 的 RESP 协议本质上都在做类似的事。分隔符方案的优点是简单缺点是payload 本身不能包含分隔符否则需要转义无法高效传输二进制数据接收方需要一直缓冲并搜索分隔符复杂度并不低对于大消息搜索性能很差。所以更通用的做法是在消息开头加一个“长度字段”告诉接收方后续还有多少字节属于当前消息。接收方先读定长头部解析出长度再循环读取完整 payload。这就是“长度前缀法”也是绝大多数自定义二进制协议的基础。从底层原因来看应用层协议本质上要回答四个问题这条消息从哪里开始用 magic 或固定头部大小确定这条消息是什么类型用 type 字段确定这条消息有多长用 length 字段确定这条消息的载荷怎么解析用序列化方案和 type 配合确定。把这四个问题想明白协议骨架就稳了。2. 一个可落地的最小协议设计头部长度、magic 与 type 如何定2.1 12 字节头部magic version type length我在实际项目里最常用、也最推荐新手作为起步的协议头长这样0-3 magic 4字节 固定魔数 LSNF 4-5 version 2字节 协议版本当前为 1 6-7 type 2字节 消息类型 8-11 length 4字节 payload 长度头部固定 12 字节后面紧接着是 length 字节的 payload。为什么用 12 字节而不是更短的定长 8 字节原因很朴素magic 必须有它能在流里快速识别“这看起来像不像我们的协议”也能在接错端口、收了一堆垃圾数据时立刻发现异常version 必须留否则协议后续加字段、改语义旧的二进制包直接全乱type 是业务路由的基础登录、心跳、数据上报都靠它区分length 用 4 字节最大能表示 4GB 的包。实际上我们肯定不会允许这么大的包但留足空间比将来再扩展头要省事。在 C 语言里我可以这样定义const size_t HEADER_LEN 12; const char MAGIC[4] {L, S, N, F}; const uint16_t PROTO_VERSION 1; const uint16_t TYPE_LOGIN_REQUEST 1; const uint16_t TYPE_LOGIN_RESPONSE 2;很多教程喜欢用struct__attribute__((packed))来定义协议头比如struct Header { uint32_t magic; uint16_t version; uint16_t type; uint32_t length; } __attribute__((packed));但我在正式代码里更倾向于避免直接把 struct 在内存和网络之间互转。因为就算 packed也需要自己处理字节序而memcpy逐字段解析其实并不比结构体复杂还能避免踩对齐和编译器差异的坑。2.2 网络字节序不是你想当然的本机整数序应用层协议只要考虑跨主机通信就必须约定字节序问题。网络协议通常统一使用大端序Linux 下提供了四个现成函数htonl(uint32_t)/htons(uint16_t)把本机整数转换为网络字节序ntohl(uint32_t)/ntohs(uint16_t)把网络字节序转回本机整数。写协议头时所有多字节字段在“上线”前都转成网络序收到数据后立刻转回主机序再参与业务解析。例如构造头部uint16_t ver htons(PROTO_VERSION); uint16_t type htons(TYPE_LOGIN_REQUEST); uint32_t len htonl(payload.size()); memcpy(header 0, MAGIC, 4); memcpy(header 4, ver, 2); memcpy(header 6, type, 2); memcpy(header 8, len, 4);magic 我用 4 个 ASCII 字符而不是一个整数因为L,S,N,F无论在哪台机器上都是完全一样的字节流不需要做字节序转换也便于抓包观察。解析头部时反过来bool parseHeader(const char* data, MsgHeader hdr) { if (memcmp(data, MAGIC, 4) ! 0) return false; memcpy(hdr.version, data 4, 2); memcpy(hdr.type, data 6, 2); memcpy(hdr.payloadLen, data 8, 4); hdr.version ntohs(hdr.version); hdr.type ntohs(hdr.type); hdr.payloadLen ntohl(hdr.payloadLen); return true; }注意我用的是memcpy而不是把data4强转成uint16_t*。虽然 x86 上非对齐访问一般不会出错但在 ARM 等平台上非对齐访问可能引发 SIGBUS而且强转本身也不符合 C 的别名规则。用memcpy是安全、可移植的写法。2.3 用 readFull 解决“半包”recv 不一定一次给全协议头里有了 length接收方就知道“我要先读 12 字节头再读 payload 的固定长度”。但问题来了recv()在一次调用里可能只返回了其中一部分尤其是网络拥塞或者包比较大的时候。所以必须写一个循环读取的函数直到凑够目标长度才返回。这就是我常说的readFullbool readFull(int fd, void* buf, size_t len) { char* p (char*)buf; size_t got 0; while (got len) { ssize_t n recv(fd, p got, len - got, 0); if (n 0) return false; got (size_t)n; } return true; }只要有这个函数粘包问题就自然化解了即使一次recv收到了“包1的完整内容 包2的头几个字节”你也会先把 12 字节的头消费掉再按头里的 length 继续消费 payload。内核缓冲区里剩下的那些字节不会消失会留到下一次recv继续取。所谓“粘包”并不是一个需要特殊解决的事件而是“没有按长度切分字节流”造成的表象。3. 序列化方案取舍手工拼接、JSON 与 Protobuf 的实战对比3.1 什么是序列化与反序列化序列化的目标是把内存中的结构化数据变成字节流反序列化则是把字节流还原成内存中的对象。很多人一说序列化就立刻想到 JSON、XML、fastjson、Protobuf其实上一章我们写“payload 里有 username 和 password”的时候已经在设计自己的序列化方案了。如果业务简单序列化方案完全可以是“两个字节的字段长度 原始字符串”。这种方式占空间小、解析快、几乎没有学习成本。但如果业务复杂嵌套结构多跨语言调用频繁手工拼字节就会变得极其痛苦。所以选型要看场景。3.2 手工序列化什么时候值得用手工序列化的核心思路是自己定义 payload 内部的字段布局。比如登录请求 payload我这样设计username_len uint16 2字节 username 字节 username_len password_len uint16 2字节 password 字节 password_len对应的写入代码string makeLoginRequest(const string user, const string pass) { string body; uint16_t ulen htons((uint16_t)user.size()); uint16_t plen htons((uint16_t)pass.size()); body.append((const char*)ulen, 2); body.append(user); body.append((const char*)plen, 2); body.append(pass); return body; }解析代码则要时刻注意边界bool parseLoginRequest(const string body, string user, string pass) { if (body.size() 4) return false; uint16_t ulen, plen; memcpy(ulen, body.data(), 2); ulen ntohs(ulen); if (body.size() (size_t)4 ulen) return false; user.assign(body.data() 2, ulen); memcpy(plen, body.data() 2 ulen, 2); plen ntohs(plen); if (body.size() ! (size_t)4 ulen plen) return false; pass.assign(body.data() 4 ulen, plen); return true; }这类方案的好处是没有第三方依赖性能高payload 紧凑完全掌控字节。坏处也明显字段一多每个字段都要手写偏移和长度计算加一个字段所有端的解析逻辑都要同步改如果不小心少校验了一个边界轻则解析错乱重则越界读取。我自己的经验是如果一个协议只有三五个字段、两端都是 C/C、没有跨语言需求手工序列化完全够用。但如果业务会长大还是趁早换结构化方案。3.3 JSON可读性优先的选择用 JSON 作为 payload协议头不变只是 payload 不再是二进制字段而是一段 JSON 文本。比如{username: admin, password: 123456}用nlohmann/json这类库序列化和反序列化几行就能搞定调试时可以直接打印 payload这一点实在是太方便了。不管是客户端 log还是写自动化测试JSON 都比二进制可读得多。代价是体积和性能。JSON 文本通常比二进制大一倍以上解析也需要消耗额外 CPU。对于登录这种低频小包完全无所谓但如果是高频状态上报每秒发几百上千条JSON 的解析耗时和带宽消耗就会被放大。3.4 Protobuf给协议一点“演进空间”再往上走就是 Protobuf、FlatBuffers、MessagePack 这类成熟的序列化框架了。以 Protobuf 为例先写一个.proto文件syntax proto3; package demo; message LoginRequest { string username 1; string password 2; } message LoginResponse { int32 code 1; string message 2; }然后由protoc生成 C、Go、Java、Python 等任意语言的代码。业务侧只需要demo::LoginRequest req; req.set_username(admin); req.set_password(123456); std::string body req.SerializeAsString();对端拿到body之后ParseFromString()就能拿到结构化对象。Protobuf 最核心的竞争力不是“性能好”而是版本兼容。它是基于字段编号的编码方式老客户端不认识的字段可以直接跳过新客户端可以给旧数据补默认值。这正好解决了协议演进最头疼的问题——不同版本的服务端和客户端共存。3.5 三种方案怎么选我在这里直接给一张对比表方便你按情况决策方案payload 体积解析性能可读性跨语言版本演进依赖复杂度手工二进制最小最高差需自己实现多语言编解码差无JSON较大中好好差轻量Protobuf小高差好好需要工具链如果是小项目建议从手工二进制或 JSON 起步别一上来就上 Protobuf学习成本和工程成本都偏高。如果一开始就知道会有多个端、要长期演进Protobuf 值得投资。4. 完整演示一个基于 TCP 的登录认证自定义协议4.1 协议定义与代码组织下面给出一个可以直接编译运行的示例。客户端发送登录请求服务端校验用户名密码返回成功或失败。这是我在“协议头 payload”上最常用的一套骨架核心代码你直接抄就能用。整体协议如下头部固定 12 字节LSNF version(2) type(2) length(4)。登录请求 type1payload 按username_len username password_len password组织。登录响应 type2payload 按code(1字节) msg_len(2字节) message组织。4.2 服务端实现#include arpa/inet.h #include netinet/in.h #include sys/socket.h #include unistd.h #include cstdint #include cstring #include iostream #include string #include vector using namespace std; const size_t HEADER_LEN 12; const char MAGIC[4] {L, S, N, F}; const uint16_t PROTO_VERSION 1; const uint16_t TYPE_LOGIN_REQUEST 1; const uint16_t TYPE_LOGIN_RESPONSE 2; struct MsgHeader { uint16_t version; uint16_t type; uint32_t payloadLen; }; bool readFull(int fd, void* buf, size_t len) { char* p (char*)buf; size_t got 0; while (got len) { ssize_t n recv(fd, p got, len - got, 0); if (n 0) return false; got (size_t)n; } return true; } bool sendAll(int fd, const void* data, size_t len) { const char* p (const char*)data; size_t sent 0; while (sent len) { ssize_t n send(fd, p sent, len - sent, 0); if (n 0) return false; sent (size_t)n; } return true; } bool recvHeader(int fd, MsgHeader hdr) { char buf[HEADER_LEN]; if (!readFull(fd, buf, HEADER_LEN)) return false; if (memcmp(buf, MAGIC, 4) ! 0) return false; uint16_t v, t; uint32_t l; memcpy(v, buf 4, 2); memcpy(t, buf 6, 2); memcpy(l, buf 8, 4); hdr.version ntohs(v); hdr.type ntohs(t); hdr.payloadLen ntohl(l); return true; } bool sendPacket(int fd, uint16_t type, const string payload) { char hdr[HEADER_LEN]; uint16_t ver htons(PROTO_VERSION); uint16_t t htons(type); uint32_t len htonl((uint32_t)payload.size()); memcpy(hdr, MAGIC, 4); memcpy(hdr 4, ver, 2); memcpy(hdr 6, t, 2); memcpy(hdr 8, len, 4); if (!sendAll(fd, hdr, HEADER_LEN)) return false; if (!payload.empty() !sendAll(fd, payload.data(), payload.size())) return false; return true; } bool parseLoginRequest(const string body, string user, string pass) { if (body.size() 4) return false; uint16_t ulen, plen; memcpy(ulen, body.data(), 2); ulen ntohs(ulen); if (body.size() (size_t)4 ulen) return false; user.assign(body.data() 2, ulen); memcpy(plen, body.data() 2 ulen, 2); plen ntohs(plen); if (body.size() ! (size_t)4 ulen plen) return false; pass.assign(body.data() 4 ulen, plen); return true; } string makeLoginResponse(int code, const string msg) { string body; body.push_back((char)code); uint16_t mlen htons((uint16_t)msg.size()); body.append((const char*)mlen, 2); body.append(msg); return body; } void handleClient(int fd) { MsgHeader hdr; if (!recvHeader(fd, hdr)) { close(fd); return; } if (hdr.version ! PROTO_VERSION) { close(fd); return; } string body(hdr.payloadLen, \0); if (!readFull(fd, body[0], hdr.payloadLen)) { close(fd); return; } if (hdr.type TYPE_LOGIN_REQUEST) { string user, pass; if (!parseLoginRequest(body, user, pass)) { close(fd); return; } bool ok (user admin pass 123456); string respBody ok ? makeLoginResponse(0, login ok) : makeLoginResponse(1, bad username or password); sendPacket(fd, TYPE_LOGIN_RESPONSE, respBody); } close(fd); } int main() { int listenFd socket(AF_INET, SOCK_STREAM, 0); if (listenFd 0) { perror(socket); return 1; } int reuse 1; setsockopt(listenFd, SOL_SOCKET, SO_REUSEADDR, reuse, sizeof(reuse)); sockaddr_in addr; memset(addr, 0, sizeof(addr)); addr.sin_family AF_INET; addr.sin_port htons(9090); addr.sin_addr.s_addr htonl(INADDR_ANY); if (bind(listenFd, (sockaddr*)addr, sizeof(addr)) 0) { perror(bind); return 1; } if (listen(listenFd, 16) 0) { perror(listen); return 1; } cout server listening on 9090 endl; while (true) { int clientFd accept(listenFd, nullptr, nullptr); if (clientFd 0) { perror(accept); continue; } handleClient(clientFd); } close(listenFd); return 0; }4.3 客户端实现客户端与服务端的readFull、sendAll、recvHeader是同一套逻辑这里只列出需要额外补的部分string makeLoginRequest(const string user, const string pass) { string body; uint16_t ulen htons((uint16_t)user.size()); uint16_t plen htons((uint16_t)pass.size()); body.append((const char*)ulen, 2); body.append(user); body.append((const char*)plen, 2); body.append(pass); return body; } bool parseLoginResponse(const string body, int code, string msg) { if (body.size() 3) return false; code (unsigned char)body[0]; uint16_t mlen; memcpy(mlen, body.data() 1, 2); mlen ntohs(mlen); if (body.size() ! (size_t)3 mlen) return false; msg.assign(body.data() 3, mlen); return true; } int main() { int fd socket(AF_INET, SOCK_STREAM, 0); sockaddr_in addr; memset(addr, 0, sizeof(addr)); addr.sin_family AF_INET; addr.sin_port htons(9090); inet_pton(AF_INET, 127.0.0.1, addr.sin_addr); if (connect(fd, (sockaddr*)addr, sizeof(addr)) 0) { perror(connect); return 1; } string reqBody makeLoginRequest(admin, 123456); sendPacket(fd, TYPE_LOGIN_REQUEST, reqBody); MsgHeader hdr; if (!recvHeader(fd, hdr)) { cerr recv header failed endl; close(fd); return 1; } string respBody(hdr.payloadLen, \0); if (!readFull(fd, respBody[0], hdr.payloadLen)) { cerr recv body failed endl; close(fd); return 1; } int code; string msg; if (!parseLoginResponse(respBody, code, msg)) { cerr parse response failed endl; close(fd); return 1; } cout code code , msg msg endl; close(fd); return 0; }4.4 编译与运行验证把服务端存成server.cpp客户端存成client.cpp在 Linux 下执行g -stdc11 -O2 -o server server.cpp g -stdc11 -O2 -o client client.cpp先开一个终端运行服务端./server再开另一个终端运行客户端./client正常输出code0, msglogin ok如果把密码改错输出就会变成code1, msgbad username or password这个例子虽然简单但它把协议头设计、字节序处理、粘包半包处理、payload 手工序列化这些关键点全部串起来了。我建议你亲手改几个地方试一下比如把服务端改成先收 header 再故意只读一半 body看看readFull是怎么等待剩余数据的比如把客户端改成连发两个请求看看服务端能不能正确逐个解析。5. 协议上线后的那些坑半包、恶意 length 与版本兼容5.1 不是所有收到的东西都可信先做合理上限校验在杀软、防火墙、各种各样的网络环境里跑过之后你就会明白任何从网络进来的字节都不能默认它是“好人”。最常见的攻击手法是发包时把length字段声明成一个极大值比如0xFFFFFFFF。如果服务端拿到 header 后直接按这个值去new vectorchar(hdr.payloadLen)内存立刻被打满进程 OOM。我见过不少线上事故是这么打出来的。所以业务侧一定要对 payload 长度做上限校验。我的习惯是定义MAX_PAYLOAD_LEN比如 1MBconst uint32_t MAX_PAYLOAD_LEN 1024 * 1024; if (hdr.payloadLen MAX_PAYLOAD_LEN) { close(fd); return; }这样即使客户端发来一个“声称 4GB”的包我们也会直接断开而不是试图分配内存。这个校验必须在分配内存之前完成顺序错了就是漏洞。5.2 反序列化的安全底线白名单类型和主动校验边界反序列化漏洞这几年被反复爆出来从 Java 的 Fastjson 到 PHP 的反序列化攻击原理本质上都绕不开“数据驱动了代码路径”或“类型实例化不可控”。在自定义协议里对应的问题就是收到一个 type 后不校验就直接跳到对应的 handler结果异常处理或者错误解析反而成了问题入口。自定义协议尽管没有 Fastjson 那种“看着字符串自动 new 对象”的反射机制但也存在自己的坑解析 payload 时必须先判断长度是否足够再做memcpy否则越界读。字段里的长度字段与实际剩余字节不一致时直接返回错误不要尝试“智能修复”。对 type 做白名单匹配遇到未知 type 直接断开并记录日志不要把它丢进默认分支继续深度解析。如果业务里用了现成序列化框架要及时升级、关闭不必要的自动类型绑定、对反序列化结果再做业务校验。我习惯把“反序列化”函数设计成“只接受const string返回 bool 或可选值”不做任何日志外的多余操作。这样可以最大程度避免异常路径污染。比如上面的parseLoginRequest每一段读取都先检查剩余长度不满足就直接return false绝不写越界。5.3 版本兼容一个 version 字段能救你很多次生产环境的残酷之处在于服务端升级了客户端不可能一夜之间全部更新客户端先上线服务端还没来得及发版。如果协议不支持版本兼容升级就是一次双方同时停机的大冒险。最简单的兼容手法就是我在头部里预留的version。版本号不要当成摆设我建议主版本号不兼容时直接在头部判断hdr.version ! PROTO_VERSION就拒绝连接次版本兼容时尽量只在 payload 末尾追加新字段旧端解析时采用“至少包含旧字段”的检查而不是强制要求 payload 字节数完全相等新字段要有合理默认值老客户端发来的包里没有这个字段新服务端也应该能正常工作。举个例子如果将来登录请求要增加一个device_id可以在 payload 末尾追加原 payload: ulen username plen password 新 payload: ulen username plen password device_id_len device_id新服务端解析时先按老格式取完 username 和 password然后看剩余字节是否足够读一个 device_id如果不够就认为设备 ID 为空。这样老客户端发的包新服务端照样能处理。等所有客户端升级完之后再逐步收紧校验。这个“向后兼容”的思路也解释了为什么我建议序列化方案从早期就考虑 Protobuf它把“在末尾加字段”和“旧端自动跳过未知字段”都规范化了不需要每次手工维护长度分支。5.4 真实线上的一些额外建议最后补充几条我在实际项目中踩过、也帮别人排查过的问题超时是必须的。没有超时控制的readFull一旦网络断连而进程没收到 RST可能卡在recv上很久。建议给 socket 设置SO_RCVTIMEO或者SO_SNDTIMEO超时后主动断开连接。心跳包可以做空 payload。很多实时服务会把type心跳的包设计成“只有协议头length0”成本极低方便清理死连接。日志里不要直接打印二进制 payload。payload 可能包含不可见字符甚至包含\0打印会导致日志混乱。要用 hex 输出或者 Base64。抓包验证永远比看代码可靠。用tcpdump -i lo port 9090 -X抓一下本机包直接看字节是否符合你设计里的字段偏移。很多时候代码看起来对实际发出去却错位抓包一眼就能定位。协议这东西不亲自上线踩一次坑很难真正理解“序列化”和“解析”为什么值得认真设计。我的个人习惯是无论项目多小都先写清协议头把 magic、version、type、length 这四个字段固定下来payload 能手工就手工要复杂就立刻换 Protobuf。这样后续加接口、换机器、跨端联调都会顺畅很多。