34、自定义应用层协议：设计一个简单的应用层协议，包含消息头和消息体。
说实话，做网络编程这么多年，我最大的感触就是——协议设计决定了系统的生死。你想想看，TCP/IP 只负责把字节流从 A 搬到 B，但搬过去的是什么？对方怎么理解？这些都得靠应用层协议来约定。
我记得刚入行那会儿，接手一个老项目，通信双方各写各的解析逻辑，文档早就丢了。结果呢？线上时不时出乱码、丢包、解析失败。后来我花了一周时间，把协议重新梳理了一遍，才把问题彻底解决。从那以后，我养成了一个习惯：写网络程序之前，先把协议定义清楚。
这一讲，我们就来设计一个简单但实用的应用层协议。它包含消息头（Header）和消息体（Body），说白了就是给数据包加个「信封」，让接收方知道怎么拆、怎么读。
协议结构总览
先看整体设计。我习惯把协议分成两部分：
- 消息头：固定长度，描述消息的元信息（比如长度、类型、版本）。
- 消息体：变长，存放实际数据（可以是文本、二进制、JSON 等）。
为什么消息头要固定长度？因为接收方可以先收固定字节的头，解析出消息体长度，再收剩下的数据。这样就不会出现「粘包」问题。嗯，这里要注意：粘包是 TCP 流式传输的天然特性，不是 bug，但你必须处理它。
核心原则：消息头必须包含「消息体长度」字段，这是所有自定义协议的基石。
下面是我常用的一个协议格式：
| 字段 | 长度（字节） | 说明 |
|---|---|---|
| Magic Number | 2 | 魔数，用于快速校验协议版本（比如 0xAB 0xCD） |
| Version | 1 | 协议版本号，方便后续升级 |
| Message Type | 1 | 消息类型（0x01 请求，0x02 响应，0x03 心跳等） |
| Body Length | 4 | 消息体长度（无符号整数，网络字节序） |
| Reserved | 4 | 保留字段，用于扩展（比如序列号、校验和） |
| Header 总长 | 12 | 固定 12 字节 |
| Body | 变长 | 实际数据，长度由 Body Length 决定 |
你看，消息头一共 12 字节，不多不少。接收方先收 12 字节，解析出 Body Length，再收对应长度的 Body。完美解决粘包问题。
协议设计的几个坑
我在项目中遇到过不少协议设计上的问题，挑几个典型的说说：
- 字节序问题：不同机器的字节序可能不同。我建议所有多字节字段都用网络字节序（大端）。C 语言里用
htonl()、ntohl()转换。 - 魔数校验：我曾经见过一个系统，因为内存错乱导致收到垃圾数据，结果解析时直接崩溃。加上魔数后，接收方可以先校验，不对就直接丢弃，安全很多。
- 保留字段：别把保留字段填死。我习惯留 4 字节，以后想加序列号、时间戳、校验和，直接往里塞，不用改协议结构。
注意：消息体长度字段如果被篡改或解析错误，可能导致接收方申请超大内存或读越界。一定要做合法性校验，比如限制最大长度。
代码实现
下面我用 C 语言实现一个简单的协议封装和解析。代码不长，但包含了核心逻辑。
#include <stdio.h>
#include <stdint.h>
#include <string.h>
#include <arpa/inet.h> // for htonl, ntohl
#define HEADER_MAGIC_0 0xAB
#define HEADER_MAGIC_1 0xCD
#define HEADER_SIZE 12
#define MAX_BODY_SIZE 4096
// 消息头结构（注意：这只是内存中的表示，发送时需按网络字节序打包）
typedef struct {
uint8_t magic[2];
uint8_t version;
uint8_t msg_type;
uint32_t body_len; // 网络字节序
uint32_t reserved;
} msg_header_t;
// 打包消息头：将结构体转为网络字节序的字节流
void pack_header(msg_header_t *hdr, uint8_t *buf) {
buf[0] = hdr->magic[0];
buf[1] = hdr->magic[1];
buf[2] = hdr->version;
buf[3] = hdr->msg_type;
uint32_t net_len = htonl(hdr->body_len);
memcpy(buf + 4, &net_len, 4);
uint32_t net_res = htonl(hdr->reserved);
memcpy(buf + 8, &net_res, 4);
}
// 解析消息头：从字节流中恢复结构体（主机字节序）
int parse_header(const uint8_t *buf, msg_header_t *hdr) {
if (buf[0] != HEADER_MAGIC_0 || buf[1] != HEADER_MAGIC_1) {
return -1; // 魔数错误
}
hdr->magic[0] = buf[0];
hdr->magic[1] = buf[1];
hdr->version = buf[2];
hdr->msg_type = buf[3];
uint32_t net_len;
memcpy(&net_len, buf + 4, 4);
hdr->body_len = ntohl(net_len);
uint32_t net_res;
memcpy(&net_res, buf + 8, 4);
hdr->reserved = ntohl(net_res);
if (hdr->body_len > MAX_BODY_SIZE) {
return -2; // 消息体过长，可能是恶意数据
}
return 0;
}
// 示例：构造一条消息并发送（伪代码）
void send_message(int sockfd, uint8_t msg_type, const uint8_t *body, uint32_t body_len) {
msg_header_t hdr;
hdr.magic[0] = HEADER_MAGIC_0;
hdr.magic[1] = HEADER_MAGIC_1;
hdr.version = 1;
hdr.msg_type = msg_type;
hdr.body_len = body_len;
hdr.reserved = 0;
uint8_t header_buf[HEADER_SIZE];
pack_header(&hdr, header_buf);
// 先发 header，再发 body
send(sockfd, header_buf, HEADER_SIZE, 0);
if (body_len > 0) {
send(sockfd, body, body_len, 0);
}
}
// 示例：接收并解析一条消息（伪代码）
int recv_message(int sockfd, msg_header_t *hdr, uint8_t *body_buf) {
uint8_t header_buf[HEADER_SIZE];
int n = recv(sockfd, header_buf, HEADER_SIZE, MSG_WAITALL);
if (n != HEADER_SIZE) return -1;
if (parse_header(header_buf, hdr) != 0) return -2;
if (hdr->body_len > 0) {
n = recv(sockfd, body_buf, hdr->body_len, MSG_WAITALL);
if (n != (int)hdr->body_len) return -3;
}
return 0;
}
小技巧：MSG_WAITALL 标志可以保证 recv 收满指定字节数，避免分多次接收。但要注意，非阻塞模式下这个标志可能不生效。
协议交互流程
光有代码还不够，你得理解数据是怎么在网络上流动的。下面这张图展示了客户端和服务端之间的一次完整消息交互：
你看，整个流程其实很清晰：客户端打包发送，服务端先收头再收体，处理完后同样方式回复。只要协议约定好，双方就能正确通信。
扩展思考
这个协议虽然简单，但已经能应对大部分场景了。如果你需要更复杂的功能，可以考虑：
- 增加校验和字段：在保留字段里放 CRC32 或 MD5，防止数据在传输中被篡改。
- 支持分片：如果消息体超过 4KB，可以拆成多个包，每个包带序号和总包数。
- 压缩：对 Body 做 gzip 压缩，减少网络传输量。我做过一个项目，压缩后流量减少了 60%。
一句话总结：自定义协议的核心就是「固定长度的头 + 变长的体」，头里必须告诉对方体有多长。剩下的，都是锦上添花。
好了，这一讲就到这里。代码你可以直接拿去用，魔数、版本号、消息类型这些根据自己的业务改一改就行。记住，协议设计越简单，后期维护越省心。