网络编程基础：Socket API封装、Reactor模式、epoll与io_uring、高性能网络框架设计
网络编程这块，说实话，是C++后端开发里最绕不开的硬骨头。我早年刚入行时，总觉得能调通socket就算会了，结果线上服务一上量，各种惊群、阻塞、内存乱飞，搞得焦头烂额。今天咱们就把这块彻底捋清楚。
Socket API封装——别裸写系统调用
很多人喜欢直接调 socket()、bind()、listen()，写完就扔。我个人习惯是，必须封装一层。为什么？因为系统调用太原始了，错误处理、资源管理、跨平台兼容，全得自己操心。
我建议至少封装成三个层次：
- 底层封装：把
socket、bind、listen、accept、connect包成 RAII 类，构造函数里创建，析构函数里 close。避免忘记关 fd。 - 中间层封装：提供
read、write、send、recv的带超时、带缓冲版本。我遇到过线上服务因为 recv 返回 0 没处理好，直接死循环的惨案。 - 高层封装：直接提供
SendMessage、ReceiveMessage这种业务语义接口，内部处理粘包、拆包。
核心原则：不要让业务代码里出现裸的 read() 或 write()。封装之后，单元测试也好写，出问题也好定位。
举个例子，我常用的 Socket 类骨架：
class TcpSocket {
public:
explicit TcpSocket(int fd) : fd_(fd) {}
~TcpSocket() { if (fd_ >= 0) close(fd_); }
// 禁止拷贝，允许移动
TcpSocket(const TcpSocket&) = delete;
TcpSocket& operator=(const TcpSocket&) = delete;
TcpSocket(TcpSocket&& other) noexcept : fd_(other.fd_) {
other.fd_ = -1;
}
ssize_t Read(void* buf, size_t len, int timeout_ms = -1);
ssize_t Write(const void* buf, size_t len, int timeout_ms = -1);
private:
int fd_;
};你看，RAII 加移动语义，基本杜绝了资源泄漏。我曾经在一个项目里发现，老代码里 30% 的 bug 都跟 fd 没关干净有关。
Reactor模式——事件驱动的灵魂
Reactor 模式，说白了就是「来了事再干活」。传统多线程模型，每个连接一个线程，连接数一上去，线程切换开销就爆炸。Reactor 的核心思路是：一个（或几个）线程循环等待事件，事件来了分发给对应的处理器。
我画了一张图，帮你理解 Reactor 的核心流程：
你想想看，Reactor 把「等待事件」和「处理事件」拆开了。事件循环只负责等，处理器只负责干。这样每个部分都简单，也容易测试。
我的经验：Reactor 里的事件处理器，最好设计成无状态的，或者状态极其简单。这样方便水平扩展。我曾经见过一个 Reactor 处理器里塞了 2000 行代码，改都不敢改。
epoll 与 io_uring——Linux 下的两把利器
epoll 是 Linux 下高性能网络编程的标配。它解决了 select/poll 的 O(n) 遍历问题，用红黑树 + 就绪链表，能做到 O(1) 的事件通知。
但 epoll 有个痛点：每次操作都要系统调用。你想想看，收一个包，要调 epoll_wait，然后 read，再 write 回去，至少三次系统调用。在高吞吐场景下，这个开销不可忽视。
io_uring 就是来解决这个问题的。它用共享内存的环形队列，把系统调用变成了用户态和内核态之间的内存交互。说白了，就是「批处理」加「零拷贝」。
| 特性 | epoll | io_uring |
|---|---|---|
| 系统调用次数 | 每次事件循环至少 1 次 | 可批量提交，大幅减少 |
| 数据拷贝 | 需要用户态内核态之间拷贝 | 支持共享内存，零拷贝 |
| 适用场景 | 通用网络服务 | 超高吞吐、存储、RPC |
| 内核版本要求 | Linux 2.6+ | Linux 5.1+（推荐 5.10+） |
| 编程复杂度 | 中等 | 较高（需要管理 SQ/CQ） |
注意：io_uring 虽然性能好，但并不是银弹。如果你的服务连接数不多、吞吐要求一般，epoll 完全够用。我见过有人为了炫技硬上 io_uring，结果代码复杂度翻倍，收益却微乎其微。
我个人建议：新项目如果内核版本允许，可以优先考虑 io_uring。但如果是维护老系统，别轻易动，epoll 已经很成熟了。
高性能网络框架设计——从零到一
有了上面的基础，我们来聊聊怎么搭一个高性能网络框架。我这些年总结下来，核心就四点：
- 事件驱动 + 非阻塞 I/O：这是地基。Reactor 模式 + epoll/io_uring，缺一不可。
- 内存池：网络编程里，内存分配是性能杀手。每次收发包都 new/delete，服务跑不了几分钟就开始碎片化。我习惯用 slab 分配器，按包大小分桶。
- 无锁队列：多线程之间传递事件或数据，用锁会严重拖慢性能。用 DPDK 里那种 ring buffer 或者 disruptor 模式，能大幅提升吞吐。
- 连接管理：连接池、心跳、重连、优雅关闭，这些都得框架层面支持。我早期一个项目就是因为没处理好连接泄漏，导致线上 fd 耗尽，服务挂了半小时。
给你看一个简单的框架分层设计：
// 伪代码，展示框架分层
class NetworkFramework {
public:
void Init();
void Start();
void Stop();
private:
EventLoop loop_; // 事件循环（封装 epoll/io_uring）
ConnectionManager conns_; // 连接管理器
MemoryPool pool_; // 内存池
TaskQueue tasks_; // 无锁任务队列
};避坑指南：我曾经在框架里直接用了 std::queue 加 mutex 做任务队列，结果压测时锁竞争导致 CPU 飙到 90%。后来换成无锁队列，CPU 直接降到 30%。你想想看，这差距有多大。
最后说一句，网络框架的设计，没有银弹。你得根据业务场景来取舍。比如游戏服务器，要求低延迟，那就得用 io_uring 加 busy polling。如果是 Web 服务器，高并发但延迟容忍度高，epoll 加线程池就很好。
嗯，这一章的内容就到这。记住，网络编程的核心不是 API，而是模型和架构。API 可以查文档，但模型选错了，后面改起来就痛苦了。