3、网络通信基石：TCP/UDP选型、Socket编程、粘包拆包处理

聊到手游服务器，网络通信这块是绕不开的坎。很多新手觉得选个协议、写个Socket就完事了，其实不然。我在项目里踩过的坑，十有八九都跟网络层有关。今天咱们就把TCP/UDP选型、Socket编程、还有那个让人头疼的粘包拆包，一次性说透。

3.1 TCP vs UDP：别凭感觉选

先问个问题：你的游戏是MOBA、MMO还是卡牌？这个答案直接决定了你该用TCP还是UDP。说白了，没有银弹。

特性 TCP UDP
连接状态 面向连接，可靠 无连接，不可靠
数据顺序 保证有序到达 可能乱序
重传机制 自动重传丢失包 不重传
适用场景 登录、支付、聊天 位置同步、技能释放

我个人习惯是：核心业务用TCP，高频状态同步用UDP。比如玩家登录、充值、背包操作，这些丢一个包就出大事，必须TCP。但像MOBA里英雄的坐标同步，每秒发几十次，丢一两个包无所谓，UDP反而更合适。

避坑指南：我曾经在一个MMO项目里全用TCP做移动同步，结果服务器CPU飙到80%。后来改成UDP + 自定义ACK，CPU直接降到30%。你想想看，TCP的拥塞控制和重传机制在高速同步场景下，反而成了累赘。

3.2 Socket编程：别只调API

很多教程教你怎么调socket()、bind()、listen()，但实战中真正要命的不是这些API，而是非阻塞IO和事件驱动。手游服务器动辄几千并发，你总不能给每个连接开一个线程吧？

我建议用epoll（Linux）或IOCP（Windows）做事件循环。核心思路就一句话：一个线程管所有连接。代码大概长这样：

// 伪代码：事件循环核心
while (true) {
    int n = epoll_wait(epfd, events, MAX_EVENTS, -1);
    for (int i = 0; i < n; i++) {
        if (events[i].events & EPOLLIN) {
            // 可读事件：收数据
            handle_read(events[i].data.fd);
        }
        if (events[i].events & EPOLLOUT) {
            // 可写事件：发数据
            handle_write(events[i].data.fd);
        }
    }
}

嗯，这里要注意：千万别在事件回调里做耗时操作。比如数据库查询、复杂计算，这些要丢到工作线程池里。否则一个慢操作堵住了，所有连接都得等。

我的经验：每个连接分配一个读写缓冲区。读缓冲区用环形队列，写缓冲区用链表。这样能避免频繁的内存分配和拷贝。我曾经见过一个项目，每次收包都new一个byte[]，GC直接炸了。

3.3 粘包拆包：绕不开的坎

TCP是流式协议，没有消息边界。你发两次write("hello")和write("world")，对端可能一次read收到"helloworld"，也可能分三次收到"hel"、"low"、"orld"。这就是粘包和拆包。

为什么会这样？因为TCP底层把数据当成字节流，它不管你的业务逻辑。你想想看，如果不对消息做边界划分，服务器根本不知道哪里是一条完整消息的结尾。

3.3.1 三种主流解决方案

  1. 固定长度：每个消息固定N字节，不足补0。简单粗暴，但浪费带宽。
  2. 分隔符：比如用\n或\r\n做边界。适合文本协议，但二进制数据里可能包含分隔符。
  3. 长度前缀：消息头里写一个int表示消息体长度。最常用，也是我推荐的方式。

我个人习惯用长度前缀法。结构很简单：

// 消息格式：4字节长度 + N字节数据
// 例如：0x0000000C + "Hello World" (12字节)

// 解码逻辑
int len = readInt();  // 先读4字节长度
byte[] data = new byte[len];
readBytes(data);      // 再读len字节数据

注意：长度字段一定要用网络字节序（大端）。我见过有人直接写本地int，结果不同机器之间解析全乱套了。还有，长度值要做合法性校验，防止恶意客户端发个0xFFFFFFFF把你内存撑爆。

3.3.2 实战中的粘包处理

光有协议格式还不够，收数据时得有个拆包器。核心逻辑就三步：

  1. 从Socket读数据，追加到缓冲区尾部
  2. 检查缓冲区头部是否有完整消息（长度字段 + 对应数据）
  3. 有则取出，没有则继续等

代码实现大概这样：

// 拆包器核心逻辑
void onDataReceived(byte[] newData) {
    buffer.append(newData);  // 追加到缓冲区
    
    while (buffer.size() >= 4) {  // 至少能读长度字段
        int msgLen = buffer.readInt();  // 读4字节长度
        if (buffer.size() < 4 + msgLen) {
            break;  // 数据还不够，等下一包
        }
        byte[] msg = buffer.readBytes(msgLen);  // 取出完整消息
        processMessage(msg);  // 交给业务层处理
    }
}

这里有个细节：缓冲区要能自动扩容。我建议用动态数组或链表，别用固定大小。曾经有个项目用1024字节的固定缓冲区，结果一个消息稍微大点就溢出了，排查了半天。

避坑指南：我曾经遇到过一个线上问题——玩家频繁掉线。查了半天发现是拆包器里用了递归调用，消息一多就把栈撑爆了。后来改成while循环，问题解决。记住：网络层代码里绝对不要用递归，你不知道一个连接会连续发多少条消息。

3.4 总结一下

网络通信这块，说白了就是三个选择：

  • 协议选型：核心业务TCP，高频同步UDP，别混用
  • Socket编程：非阻塞 + 事件驱动，一个线程管千连
  • 粘包拆包：长度前缀法最稳，缓冲区要动态扩容

嗯，这些是我在多个项目里反复验证过的经验。下一章咱们聊聊连接管理和心跳机制，那又是另一番天地了。

← 上一章 📖 返回目录 下一章 →