单线程 select 事件循环：Flash 联机小游戏长连接服务端骨架

简介：这份压缩包面向想理解Flash小游戏与后台服务器通信机制的开发者，围绕TCP连接与select I/O模型，给出一个可运行的赛车游戏服务端案例。包内共15个文件，以C++源码、VC6工程配置、控制台可执行程序及说明文档为主，并含obj、pdb、pch等编译调试中间文件，整体约649KB，便于直接打开工程梳理服务端结构。内容重点展示服务器如何用select同时监控多个套接字、处理客户端请求并同步游戏状态，也涉及Flash客户端与服务端之间数据包头、标识符与数据体的格式设计思路。已有237人学习，适合具备C++与网络编程基础、希望从可执行案例切入理解并发连接处理与协议约定的读者参考。目录中的工程配置、源码与调试文件可对照阅读服务端主流程、网络事件分发及编译运行环节。

1. 一台小机器扛住几千个 Flash 连接，靠的不是框架

去年有朋友把一个 Flash 小游戏的后端甩给我，说“就几十行 socket，跑起来老掉线”。打开一看，服务端用的正是 TCP select 模型，没有 epoll、没有线程池、没有网络库，一个 while 循环把几百个客户端全接住了。当时我第一反应是这玩意能撑多久，第二反应是——对于 Flash 时代的联机小游戏，这套结构其实相当合理。

这个项目是一套完整的联机小游戏前后端骨架：Flash 端负责渲染、输入和插值，服务端用 C++ 写单线程 select 事件循环，跑房间、对局、广播和心跳，中间夹着自定义二进制协议。谁适合看：手里有老 Flash 小游戏想补联机能力的人、想搞明白长连接服务端底层怎么转的人，还有拿它当 select 模型教科书式的可编译样例的人。

2. 分层与目录：客户端只画，服务端只算

先立一条规矩，后面所有代码都围绕它展开：Flash 客户端不信任任何本地计算结果。SWF 反编译之后 AS3 的逻辑几乎是明文，伤害公式、掉落表、坐标校验全放客户端等于把外挂源码一起发出去。所以这套骨架里，客户端只干三件事——把玩家输入打成协议包发上去、按服务端下发的状态渲染、在两个状态包之间做插值让画面不卡顿。剩下的全部在服务端 tick 里算。

2.1 为什么单线程 + select 反而是对的选择

Flash 游戏的联机压力模型和现在的手游不一样。它的房间通常很小，一个房间 4 到 8 人，单个包几十字节，对局节奏 10～20 Hz，绝大部分时间服务端在做“收包 → 改状态 → 广播”这种纯内存操作，没有数据库、没有 RPC、没有磁盘 IO。这种情况下多线程带来的收益很低，反而要处理锁、连接跨线程迁移、广播时的迭代器失效，全是血泪经验。

select 的限制也很清楚：Linux 下 fd_set 默认上限 1024，一次 select 要线性扫一遍所有 fd，O(n) 复杂度。但对着“单进程几千连接、每连接每秒几十个包”这个量级，它完全够用，而且代码量小到一个人一下午能读完。我一般的建议是：先用 select 把业务逻辑和协议跑通，等到连接数真的顶到 800 以上、或者单次 select 返回耗时超过 5ms，再考虑换 epoll，那时候你的协议层和连接层已经稳定，迁移只是换一个事件循环的事。

这套骨架里，游戏逻辑被拆成一个纯函数式的 tick：game_room.cpp暴露TickRoom(now_ms)，主循环每 50ms 触发一次，把所有房间跑一遍。它不碰 socket，只读写内存里的实体状态，产出“要发给谁什么包”的列表，由连接层负责投递。这个边界切干净之后，换网络模型不需要动一行玩法逻辑。

2.2 目录结构与每个文件该改什么

工程分三块：客户端 Flash 工程、服务端 C++ 工程、压测工具。

flash-arena/ ├── client/ Flash 客户端（AS3） │ └── src/ │ ├── NetClient.as 连接、收发、半包缓存 │ ├── Proto.as 命令字常量，必须与服务端一致 │ └── GameScene.as 渲染与插值，不参与任何数值计算 ├── server/ │ ├── src/ │ │ ├── main.cpp 启动参数、监听、select 主循环 │ │ ├── conn_mgr.cpp 连接表、读缓冲、写缓冲 │ │ ├── protocol.cpp 包头编解码、字节序转换 │ │ └── game_room.cpp 房间状态与 tick │ ├── conf/server.ini 端口、tick 间隔、心跳超时 │ └── Makefile └── tools/ └── stress/ 用 C 写的裸 socket 压测客户端

对应到实际改动，大概是这样：

编译和启动就三步，Makefile 里只有-O2 -std=c++11 -pthread，没有第三方依赖：

cd server make -j4 ./bin/flash-arena-server -p 9000 -t 20 -m 4096

三个参数分别是监听端口、tick 间隔毫秒数、最大连接数上限。-t 20表示每秒 50 次逻辑 tick，对 Flash 小游戏的对局同步足够；-m 4096是连接表预留容量，超过就直接拒绝 accept，避免 fd 被耗尽之后整个进程 listen 失败——这个坑后面还会提。

3. select 主循环：一个 fd_set 撑起全部连接

这一章是整套骨架的心脏。理解它只需要记住一句话：select 是“把你想关注的 fd 抄一份给内核，内核改完再还给你”，所以每次调用前那份 fd_set 都得重新抄。所有 select 相关的事故，八成源于忘了这句话。

3.1 fd_set 的三个使用约束

第一个约束是容量。Linux 下FD_SETSIZE默认 1024，意味着 fd 编号超过 1023 的连接根本没法塞进 fd_set，FD_SET会直接越界写内存，表现是随机崩溃或者数据错乱，非常玄学。所以服务端启动时会先检查监听 fd 和连接数上限，超过就打印警告退出。Windows 下 fd_set 是个数组结构，容量由FD_SETSIZE决定但语义不同，跨平台代码里这块要单独包一层。

第二个约束是第一个参数。select(nfds, ...)的nfds必须是“最大 fd 值加一”，不是连接数，也不是FD_SETSIZE。传错了 Linux 直接返回EINVAL，你就看到 select 一直失败、连接一个都处理不了。

第三个约束是超时参数会被内核改写。struct timeval传进去是超时上限，select 返回时会被改成剩余时间。如果把它定义在循环外面复用，第二次调用的超时就变成 0 了，循环直接空转把 CPU 打满。每次循环都要重新初始化。

3.2 连接表与 accept 的写法

连接表用std::map<int, Conn>，key 是 fd。用 map 不是为了性能，是为了遍历时能和 fd_set 的重建一次走完，而且 fd 回收复用的时候不容易出错。每个连接对象里放三样东西：读缓冲、写缓冲、最后活跃时间。

// conn_mgr.h struct Conn { int fd; std::string inbuf; // 半包缓存，recv 到的原始字节 std::string outbuf; // 待发送队列，非阻塞写不出去先攒着 int64_t lastActive; // 最后收到数据的时间戳，心跳超时判定用 uint32_t playerId; // 0 表示还没登录 }; std::map<int, Conn> g_conns;

accept必须放在循环里反复调用，因为一次 select 可能同时就绪多个连接。新 fd 要立刻设成非阻塞，否则后续recv在没有数据时会卡住整个线程——单线程模型里卡一次就是全员掉线。

void AcceptLoop(int listenFd) { while (true) { sockaddr_in addr; socklen_t len = sizeof(addr); int fd = accept(listenFd, (sockaddr*)&addr, &len); if (fd < 0) { // EAGAIN 表示这次没有更多新连接了，正常退出 if (errno == EAGAIN || errno == EWOULDBLOCK) break; // EINTR 是被信号打断，重试即可 if (errno == EINTR) continue; perror("accept"); break; } if ((int)g_conns.size() >= g_maxConn) { close(fd); // 超上限直接关，保护 fd 资源 continue; } SetNonBlocking(fd); SetTcpNoDelay(fd); // 小包游戏必须关 Nagle，否则延迟飙升 Conn c; c.fd = fd; c.lastActive = NowMs(); c.playerId = 0; g_conns[fd] = c; } }

SetTcpNoDelay那行别省。Nagle 算法会把小包攒着一起发，你的对局同步包本来就几十字节，被攒一下就是 40ms 的额外延迟，玩家体感就是“操作粘手”。这个和 select 无关，但排查延迟问题的时候经常被误算到 select 头上。

3.3 一次完整的事件循环

主循环的结构固定：重建 fd_set → 调 select → 处理监听 fd → 处理可读 fd → 处理可写 fd → 跑 tick → 清理超时连接。

void EventLoop(int listenFd) { int64_t lastTick = NowMs(); while (g_running) { fd_set rfds, wfds; FD_ZERO(&rfds); FD_ZERO(&wfds); FD_SET(listenFd, &rfds); int maxFd = listenFd; // 每轮重建：select 返回后这两个集合已经被内核改写了 for (auto& kv : g_conns) { int fd = kv.first; FD_SET(fd, &rfds); // 所有连接都关心可读 if (!kv.second.outbuf.empty()) { FD_SET(fd, &wfds); // 只有积压数据才关心可写 } if (fd > maxFd) maxFd = fd; } struct timeval tv; tv.tv_sec = 0; tv.tv_usec = 20000; // 20ms 上限，保证 tick 准时 int n = select(maxFd + 1, &rfds, &wfds, nullptr, &tv); if (n < 0) { if (errno == EINTR) continue; // 被信号打断不算错误 perror("select"); break; } int64_t now = NowMs(); if (n > 0) { if (FD_ISSET(listenFd, &rfds)) AcceptLoop(listenFd); // 先收集再处理，避免处理过程中 map 被 erase 打乱遍历 std::vector<int> readable, writable; for (auto& kv : g_conns) { if (FD_ISSET(kv.first, &rfds)) readable.push_back(kv.first); if (FD_ISSET(kv.first, &wfds)) writable.push_back(kv.first); } for (int fd : readable) OnReadable(fd, now); for (int fd : writable) OnWritable(fd); } if (now - lastTick >= g_tickMs) { TickAllRooms(now); // 逻辑层，跟 socket 完全解耦 lastTick = now; } CheckHeartbeat(now); // 超时踢人 } }

几个关键点值得单独说。tv_usec = 20000不是随便写的，它同时充当 tick 的节拍器：select 最多睡 20ms 就醒一次，即使没有任何网络事件，逻辑也能按 50Hz 推进。如果你的 tick 是 100ms，这个超时值可以放到 50ms，留一半余量，防止网络事件密集时 tick 被饿死。

“先收集再处理”这段是踩过坑之后的写法。早期版本直接在for (auto& kv : g_conns)里调OnReadable，如果那个函数里因为协议错误把连接 erase 掉，迭代器立刻失效，进程要么崩要么进入死循环。改成先扫一遍收集 fd 列表，再逐个处理，OnReadable里就可以放心地关连接了。

OnReadable和OnWritable的实现放在下一章，因为它们和协议绑得很紧。

4. 协议与收发：粘包、半包和写不出去的那部分

TCP 是字节流，不是消息流。这一句话决定了服务端收发层的全部设计。客户端send两次、服务端可能一次recv全收到；客户端send一次大包，服务端可能要recv三四次才凑齐。任何“一次 recv 就是一条消息”的写法，上线必翻车。

4.1 包头设计与字节序

骨架里用的是定长包头加变长包体，总共 8 字节：

字节序是这里最容易翻车的地方。服务端跑在 x86 上，本机是小端；Flash 的ByteArray默认是大端。所以服务端写入时必须用htonl/htons转成网络序，读出时用ntohl/ntohs转回来，而客户端什么都不用做，readUnsignedInt和readUnsignedShort默认就按大端读。反过来，如果服务端图省事直接memcpy结构体，客户端读出来的len会是个天文数字，然后你就看着它一直等一个永远凑不齐的包。

// protocol.cpp const size_t kHeaderLen = 8; bool DecodeHeader(const char* buf, uint32_t& bodyLen, uint16_t& cmd, uint16_t& seq) { uint32_t netLen; uint16_t netCmd, netSeq; memcpy(&netLen, buf, 4); memcpy(&netCmd, buf + 4, 2); memcpy(&netSeq, buf + 6, 2); bodyLen = ntohl(netLen); cmd = ntohs(netCmd); seq = ntohs(netSeq); return bodyLen <= kMaxBodyLen; // 防畸形包把内存撑爆 } void EncodeHeader(std::string& out, uint32_t bodyLen, uint16_t cmd, uint16_t seq) { uint32_t netLen = htonl(bodyLen); uint16_t netCmd = htons(cmd); uint16_t netSeq = htons(seq); out.append((const char*)&netLen, 4); out.append((const char*)&netCmd, 2); out.append((const char*)&netSeq, 2); }

kMaxBodyLen建议设成 64KB 以内。超过这个长度的包在游戏协议里基本不存在，一旦出现大概率是客户端被改了或者字节流错位了，这时候直接断连比继续解析安全得多——这也是黑匣子日志里最该记的一条。

4.2 收包状态机：一次 recv 可能读出三条命令

OnReadable的职责是把 fd 上的字节全吸进inbuf，然后循环尝试从inbuf头部切出完整包，切一个处理一个，直到剩下的字节不够一个完整包为止。

void OnReadable(int fd, int64_t now) { auto it = g_conns.find(fd); if (it == g_conns.end()) return; Conn& c = it->second; char buf[8192]; while (true) { ssize_t n = recv(fd, buf, sizeof(buf), 0); if (n > 0) { c.inbuf.append(buf, n); c.lastActive = now; continue; // 继续吸，直到 EAGAIN } if (n == 0) { CloseConn(fd); return; } // 对端正常关闭 if (errno == EINTR) continue; if (errno == EAGAIN || errno == EWOULDBLOCK) break; // 吸干了 CloseConn(fd); return; } // 循环切包：半包留在 inbuf 里等下一次 while (c.inbuf.size() >= kHeaderLen) { uint32_t bodyLen; uint16_t cmd, seq; if (!DecodeHeader(c.inbuf.data(), bodyLen, cmd, seq)) { CloseConn(fd); // 畸形包头，直接断 return; } size_t total = kHeaderLen + bodyLen; if (c.inbuf.size() < total) break; // 半包，等下次 std::string body = c.inbuf.substr(kHeaderLen, bodyLen); c.inbuf.erase(0, total); Dispatch(fd, cmd, seq, body); // 业务分发 if (g_conns.find(fd) == g_conns.end()) return; // 已被业务关掉 } }

注意Dispatch之后立刻检查连接是否还存在。业务层可能因为协议违规、重复登录、房间满就把连接踢了，这时候c已经是悬空引用，继续erase就是未定义行为。这是单线程模型里唯一需要小心的地方，比多线程的锁问题好处理得多，但也不能当成没有。

4.3 发送缓冲：客户端不读，服务端不能陪它卡死

send在阻塞 fd 上会一直等到数据进内核缓冲区，客户端要是网卡了不读，整个 select 循环就停在那里，几千个连接一起陪葬。所以 fd 全部非阻塞，send返回EAGAIN就把剩余数据留在outbuf里，等下一轮 select 告诉自己“这个 fd 可写了”再继续发。

void SendTo(int fd, const std::string& pkt) { auto it = g_conns.find(fd); if (it == g_conns.end()) return; Conn& c = it->second; if (c.outbuf.empty()) { // 队列空，先试一次直接发，省掉一次内存拷贝 ssize_t n = send(fd, pkt.data(), pkt.size(), MSG_NOSIGNAL); if (n < 0 && (errno == EAGAIN || errno == EWOULDBLOCK)) n = 0; if (n < 0) { CloseConn(fd); return; } c.outbuf.append(pkt.data() + n, pkt.size() - n); } else { c.outbuf.append(pkt); // 已经积压，乖乖排队保持顺序 } if (c.outbuf.size() > kMaxOutBuf) { // 30 秒还没发完的低速连接 CloseConn(fd); } } void OnWritable(int fd) { auto it = g_conns.find(fd); if (it == g_conns.end()) return; Conn& c = it->second; while (!c.outbuf.empty()) { ssize_t n = send(fd, c.outbuf.data(), c.outbuf.size(), MSG_NOSIGNAL); if (n > 0) { c.outbuf.erase(0, n); continue; } if (n < 0 && errno == EINTR) continue; if (n < 0 && (errno == EAGAIN || errno == EWOULDBLOCK)) return; CloseConn(fd); // EPIPE 之类，对端已经没了 return; } }

MSG_NOSIGNAL这个标志必须加。对端断开之后再send，默认行为是给进程发SIGPIPE，默认处理是直接杀进程。你会在日志里看到进程莫名其妙没了，没有崩溃栈、没有 core，非常像玄学问题。加了这个标志之后，send改成返回EPIPE，走正常的断连逻辑。

kMaxOutBuf是防慢客户端的最后一道闸。广播一局状态给 8 个人，只要有一个人卡在 2G 网络上，他的outbuf就会一直涨。设个 256KB 上限，超了就踢，房间里其他人无感，这是保护整体的必要代价。

5. 排查笔记：select 服务端最容易翻的五个坑

这套骨架我在两台机器上分别跑过压测，前前后后修了七八个问题，挑五个最有代表性的写下来。每一个都是“现象看着像另一个问题”的类型。

5.1 连接层相关

现象：压测跑到 200 多个连接之后，新连上的客户端收不到任何数据，服务端 CPU 反而更高了。

原因：fd_set 在主循环外面只FD_ZERO了一次，后面没重建。select 返回时会修改集合内容，第二轮开始拷给内核的就是上一轮剩下的“就绪 fd”，新连接根本没被监听上。

解决：每一轮循环开头无条件FD_ZERO然后重新FD_SET所有连接。这条没有例外，写得再丑也要重建。

现象：select 一直返回 -1，日志刷EINVAL，一个连接都不处理。

原因：select第一个参数传了g_conns.size()或者FD_SETSIZE，而内核要求最大 fd 值加一。当最大 fd 是 1000 时传 1024 是合法的，传 200 就是非法的，行为随内核版本变化。

解决：遍历时维护maxFd，调用时传maxFd + 1。

现象：Flash 客户端connect之后立刻触发close事件，服务端日志显示连接建立又马上断开。

原因：Flash 的 Socket 在连接后可能先发一段跨域策略请求，服务端把它当成游戏协议解析，长度字段读出来是个非法值，直接判为畸形包断开。

解决：在OnReadable开头做一次嗅探，前若干字节匹配到策略请求就直接回一段允许策略再关闭，不进入游戏协议解析。这个逻辑只影响新连接的第一个包，成本可以忽略。

5.2 数据层与客户端侧

现象：玩家操作有“走两步停一下”的顿挫感，抓包看每个包都到了，但服务端像是漏处理了一部分。

原因：服务端一次recv里读到了两条命令，代码只解析了头部第一条就return，第二条留在inbuf里，等到下个包到了才被顺带处理，于是逻辑上出现延迟。

解决：收包必须是while循环切包，切到不够一个完整包才退出，不能if。

现象：压测里只要有一个客户端故意不读数据，几十秒后其他所有客户端集体掉线。

原因：发送用的是阻塞send，慢客户端把内核发送缓冲区塞满之后，send阻塞，整个单线程事件循环停住，心跳检查也跑不了，全部连接被判超时。

解决：fd 全部非阻塞，发送走outbuf队列，EAGAIN就等下一轮可写事件；再加outbuf上限，超了直接踢人。心跳和 tick 在这个结构下就不会被任何一个连接卡住。

6. 二次开发：加一条命令只动三个地方，别动事件循环

拿到这套骨架之后，绝大多数改动都是“加一条命令”。我把流程固化成三步，做完这三步基本不会漏。第一步在Proto.as和protocol.cpp里同步加命令字常量，两边必须一字不差，漏一边的结果是客户端发包服务端Dispatch里落到 default 分支，静默丢弃，你会排查很久。第二步在Dispatch里加 case，把包体反序列化成结构体，转给game_room对应的方法。第三步在game_room里改状态，并把要广播的结果塞进返回列表，由连接层统一发出去——不要在game_room里直接调SendTo，那样这个模块就和网络层绑死了。

// game_room.cpp 里加一种“使用道具”的玩法，只改这里 std::vector<OutPacket> Room::UseItem(uint32_t playerId, uint32_t itemId) { std::vector<OutPacket> out; if (!IsAlive(playerId)) return out; // 死亡状态拒绝 if (cooldown_[playerId] > now_) return out; // 冷却中，静默丢弃 if (!ConsumeItem(playerId, itemId)) return out; // 道具不足 cooldown_[playerId] = now_ + kItemCooldownMs; OutPacket broadcast; broadcast.cmd = CMD_ITEM_USED; broadcast.body = PackItemUsed(playerId, itemId); for (uint32_t pid : players_) out.push_back({pid, broadcast}); return out; }

返回值是“要发给谁什么包”的列表，主循环拿到之后统一走SendTo。这个约定的好处是玩法逻辑可测——不启 socket，直接构造一个Room，调UseItem，断言返回列表的长度和内容，单测几十行就写完。我一般会把这个模式贯彻到底，凡是需要广播的操作都返回列表，不允许在玩法层出现任何send调用。

从 select 迁到 epoll 的判断标准我也写下来，免得你过早优化：连接数稳定超过 800、或压测中select单次返回耗时超过 5ms、或者你开始需要“只关心可写”的连接做批量下载。不到这三条，select 的代码简单性带来的维护收益远大于性能损失。真要迁的时候，只需要重写EventLoop和OnReadable/OnWritable的触发方式，protocol.cpp、game_room.cpp一行都不用动，这正是当初把边界切干净的价值。

压测我固定用三个指标看，别只盯着连接数：

第三个数一旦常年高于几十 KB，说明有慢客户端在拖，先查网络而不是查代码。从那以后我每次改完收发层，都会先跑一轮“一个客户端故意不读”的压测，专门验证事件循环不会被卡住。这套动作看着笨，但比上线后半夜被叫起来强。希望帮到你。

本文还有配套的精品资源，点击获取