企业官网建设流程全解析

1. 项目概述：为什么我们需要再造一个轮子？

“从零开始写一个高性能C++网络库”，这个标题听起来就充满了挑战和诱惑。在开源世界，libevent、libuv、asio、muduo这些名字如雷贯耳，它们成熟、稳定、功能丰富。那么，为什么还要自己动手呢？这恰恰是问题的核心。对于一名希望深入理解网络编程、操作系统内核交互以及高性能服务端架构本质的开发者来说，仅仅会调用epoll_wait或者使用asio::async_read是远远不够的。亲手实现一个网络库，尤其是包含源码级事件循环设计的网络库，是一个无与伦比的“深度修炼”过程。它能让你彻底搞懂从TCP三次握手到数据包在内核与用户态之间穿梭，再到应用层回调触发的完整链条，理解每一个性能优化点背后的权衡与代价。

这个项目适合谁？首先，它适合那些对C++有一定掌握，熟悉RAII、智能指针、移动语义，但对网络编程底层感到模糊的中高级开发者。其次，它适合那些在面试中被“Reactor模式”、“边缘触发与水平触发”、“惊群效应”等问题难住，希望知其然更知其所以然的求职者。最后，它也适合那些有志于构建底层基础设施，或对现有网络库有定制化需求（比如嵌入特定协议、实现特殊调度策略）的工程师。通过这个项目，你获得的将不仅仅是一个可以运行的代码库，更是一套解决高并发网络IO问题的系统性思维和工具箱。

2. 核心架构设计：Reactor模式的取舍与实现

构建网络库，首先要确定核心架构模式。主流的高性能网络库几乎都绕不开Reactor（反应器）模式，我们的实现也将以此为基础。简单来说，Reactor模式的核心是“事件驱动”：由一个或多个事件循环（Event Loop）线程，持续监听多个文件描述符（如Socket）上的IO事件（可读、可写、错误等）。当事件发生时，事件循环线程并不自己处理业务逻辑，而是将对应的回调函数（Callback）分发给其他工作线程或直接在本线程执行。这种设计将IO等待与业务处理解耦，用少量线程即可管理海量连接，是支撑高并发的基石。

2.1 单Reactor与多Reactor模型选型

在实现Reactor时，我们面临第一个关键选择：单Reactor还是多Reactor？

单Reactor单线程模型最为简单，所有工作（事件监听、IO操作、业务计算）都在一个线程内完成。它的优点是极致简单，没有线程同步的烦恼，但缺点也显而易见：无法利用多核CPU，且一个耗时业务会阻塞整个事件循环。这适合业务逻辑极快、连接数不多的场景，如一些简单的代理服务器。

单Reactor多线程模型在事件循环线程外引入了一个线程池。事件循环线程只负责监听和分发IO事件，具体的读写操作和业务处理被封装成任务投递到线程池中执行。这解决了业务处理阻塞事件循环的问题，但事件循环本身（特别是epoll_wait）和任务队列的访问成了新的共享资源，需要加锁保护，引入了一定的复杂度。

多Reactor（主从Reactor）模型是我们最终选择的方向，也是像Nginx、Netty等高性能框架采用的模式。在这个模型中，有一个主Reactor（Main Reactor）和一个或多个从Reactor（Sub Reactor）。主Reactor通常只有一个，它只负责监听并接受（Accept）新的客户端连接。一旦连接建立，主Reactor会通过某种方式（如Round-Robin）将这个新连接派发给某个从Reactor。此后，该连接的所有读写事件都由这个从Reactor来监听和处理。每个从Reactor都运行在独立的线程中，形成“一个线程对应一个事件循环，管理一组连接”的格局。

为什么选择多Reactor模型？

1. 职责清晰：主Reactor专注连接建立，从Reactor专注连接上的数据流通。
2. 性能与扩展性：从Reactor之间完全无锁，因为连接被固定分配，其上的所有操作都在同一个线程内完成，避免了复杂的线程同步。通过增加从Reactor线程数，可以线性地扩展IO处理能力。
3. 与现代硬件架构匹配：每个线程可以绑定到不同的CPU核心，减少缓存失效，提升整体性能。

我们的网络库将采用多Reactor模型。主Reactor一个线程，从Reactor数量可配置（通常与CPU核心数相等或2倍）。

2.2 核心组件抽象与类设计

基于多Reactor模型，我们可以抽象出几个核心的类：

1. EventLoop（事件循环）：这是整个架构的心脏。每个Reactor线程都拥有一个EventLoop实例。它内部封装了IO多路复用器（如epoll）、活跃事件列表、定时器队列和待执行回调队列。它的loop()函数是一个无限循环，不断执行：查询IO事件 -> 处理活跃事件 -> 执行到期定时器 -> 处理待执行回调。
2. Poller/EpollPoller（事件监听器）：这是EventLoop的依赖组件，是对底层IO多路复用系统调用（epoll_create,epoll_ctl,epoll_wait）的面向对象封装。我们将它设计为抽象基类，以便未来可以扩展支持poll或kqueue（虽然我们的实现以Linux epoll为主）。
3. Channel（通道）：这是最关键的抽象之一。每个需要监听事件的文件描述符（fd）都对应一个Channel对象。Channel并不拥有fd，而是记录了这个fd感兴趣的事件（如EPOLLIN）、实际发生的事件，以及对应的读、写、错误、关闭等回调函数。它是EventLoop、Poller和具体IO对象（如TcpConnection）之间的桥梁。当Poller返回某个fd上有事件发生时，EventLoop会找到对应的Channel，调用其相应的事件处理回调。
4. Acceptor（连接接收器）：属于主Reactor。它封装了一个监听socket，其对应的Channel关注读事件（EPOLLIN）。当有新连接到来时，它的读回调函数被调用，内部执行accept()，并调用用户注册的新连接回调函数，以创建新的客户端连接。
5. TcpConnection（TCP连接）：代表一个已建立的TCP连接。它拥有socket fd、本地和对端地址、输入输出缓冲区等。它内部包含两个Channel（实际上通常复用同一个Channel，但关注不同事件），分别用于处理读和写事件。TcpConnection的生命周期由shared_ptr管理，确保在回调执行期间对象不会被意外销毁。
6. TcpServer（TCP服务器）：给用户使用的、最上层的类。它内部包含一个主EventLoop（用于Acceptor）、一个EventLoopThreadPool（从Reactor线程池）、一个Acceptor实例，以及一个从连接地址到TcpConnection的映射。用户通过配置线程数、设置各类回调（连接建立、消息到达、连接关闭等）来使用它。
7. Buffer（缓冲区）：高性能网络库不可或缺的部分。我们实现一个应用层的输入/输出缓冲区。为什么需要它？因为TCP是字节流协议，读到的数据可能不完整（半包），要发送的数据可能一次发不完（内核发送缓冲区满）。Buffer帮助我们优雅地处理这些情况，内部通常采用vector<char>并实现“腾挪”机制，避免频繁内存分配。

3. 源码级事件循环（EventLoop）核心实现

事件循环是驱动一切的引擎。让我们深入其核心实现细节。

3.1 EventLoop 的生命周期与线程模型

一个基本原则：一个EventLoop对象只属于一个线程，且只在该线程内被调用其关键方法（如loop(),runInLoop()）。我们通过thread_local变量t_loopInThisThread来记录当前线程拥有的EventLoop指针，并在构造函数中检查，确保一个线程只能创建一个EventLoop。

class EventLoop : noncopyable { public: EventLoop(); ~EventLoop(); void loop(); // 核心循环函数 void quit(); // 退出循环 void runInLoop(Functor cb); // 在所属线程执行回调 void queueInLoop(Functor cb); // 将回调排队到待执行队列 bool isInLoopThread() const { return threadId_ == CurrentThread::tid(); } ... private: const pid_t threadId_; // 记录创建该loop的线程ID std::atomic_bool looping_; std::atomic_bool quit_; std::unique_ptr<Poller> poller_; std::vector<Channel*> activeChannels_; // Poller返回的活动通道 int wakeupFd_; // 用于唤醒loop std::unique_ptr<Channel> wakeupChannel_; std::mutex mutex_; std::vector<Functor> pendingFunctors_; // 跨线程传递的待执行函数 };

loop()函数的简化骨架如下：

void EventLoop::loop() { looping_ = true; quit_ = false; while (!quit_) { activeChannels_.clear(); // 1. 等待IO事件，超时时间由定时器决定 pollReturnTime_ = poller_->poll(kPollTimeMs, &activeChannels_); // 2. 处理活跃的Channel事件 for (Channel* channel : activeChannels_) { channel->handleEvent(pollReturnTime_); } // 3. 执行其他线程投递过来的回调（或定时任务） doPendingFunctors(); } looping_ = false; }

3.2 跨线程调用与唤醒机制

这是EventLoop设计的一个精妙之处。假设我们有一个工作线程（非IO线程）完成计算后，需要通知某个连接（其Channel在某个EventLoop线程）发送数据。直接调用TcpConnection::send()是线程不安全的。正确的做法是，让工作线程将发送操作封装成一个函数对象（Functor），通过EventLoop::runInLoop()或queueInLoop()提交给该连接所属的EventLoop线程去执行。

queueInLoop的实现会将Functor放入pendingFunctors_队列。但此时EventLoop线程可能正阻塞在poller_->poll()调用上。如何唤醒它去处理新任务？答案是：使用 eventfd 或 pipe 创建一个唤醒文件描述符（wakeupFd_）。

• 在EventLoop构造函数中，创建eventfd（或pipe），并为其创建一个wakeupChannel，关注可读事件。
• 当其他线程调用queueInLoop，并且当前线程不是EventLoop所属线程时，除了将Functor入队，还会向这个wakeupFd_写入8个字节的数据。
• 由于wakeupFd_被poller监听，写入操作会立即让poller_->poll()返回，wakeupChannel的可读事件被处理。
• 在wakeupChannel的读回调中，读出那8个字节（清空事件），然后顺利进入doPendingFunctors()阶段，执行其他线程投递过来的任务。

这个机制完美解决了“如何安全地跨线程向事件循环提交任务并即时唤醒”的问题。

3.3 定时器功能集成

一个完整的网络库必须支持定时任务，如心跳检测、超时断开、延迟操作等。我们可以在EventLoop中集成一个定时器队列。通常使用最小堆（std::priority_queue）或时间轮来管理定时器，按到期时间排序。

关键点在于，如何让poller_->poll()的阻塞时间与下一个定时器的到期时间关联起来。在每次事件循环中，我们计算定时器队列中最近一个定时器的到期时间与当前时间的差值，将这个差值作为poll()的超时参数。这样，poll要么因IO事件返回，要么在下一个定时器到期时准时返回，实现了高效的定时调度。

4. 核心组件深度剖析与实现

4.1 Channel：事件分发的枢纽

Channel是“小而美”的典范，它职责单一，却是连接底层Poller和上层回调的纽带。

class Channel : noncopyable { public: using EventCallback = std::function<void()>; using ReadEventCallback = std::function<void(Timestamp)>; // Timestamp是事件发生时间 Channel(EventLoop* loop, int fd); ~Channel(); void handleEvent(Timestamp receiveTime); // EventLoop调用，处理事件 void setReadCallback(ReadEventCallback cb) { readCallback_ = std::move(cb); } void setWriteCallback(EventCallback cb) { writeCallback_ = std::move(cb); } void setErrorCallback(EventCallback cb) { errorCallback_ = std::move(cb); } void setCloseCallback(EventCallback cb) { closeCallback_ = std::move(cb); } // 关注/不关注某些事件 void enableReading() { events_ |= kReadEvent; update(); } void disableReading() { events_ &= ~kReadEvent; update(); } void enableWriting() { events_ |= kWriteEvent; update(); } void disableWriting() { events_ &= ~kWriteEvent; update(); } void disableAll() { events_ = kNoneEvent; update(); } int fd() const { return fd_; } int events() const { return events_; } void set_revents(int revt) { revents_ = revt; } // Poller设置返回的事件 private: void update(); // 调用EventLoop->updateChannel(this)，最终调用Poller->updateChannel EventLoop* loop_; // 所属EventLoop const int fd_; // 负责的文件描述符，但不拥有它 int events_; // 关注的事件 int revents_; // Poller返回的当前活跃事件 ReadEventCallback readCallback_; EventCallback writeCallback_; EventCallback errorCallback_; EventCallback closeCallback_; };

handleEvent是核心，它根据revents_判断事件类型，并调用相应的用户回调。这里有一个重要细节：必须先调用closeCallback_（如果设置了且遇到挂起事件），然后再调用其他回调。因为连接关闭后，再处理读写事件是没有意义的，甚至可能导致访问已释放的内存。

4.2 Poller/EpollPoller：对epoll的封装

Poller是抽象基类，EpollPoller是Linux下的实现。封装的目标是向EventLoop隐藏epoll_ctl的细节。

class EpollPoller : public Poller { public: EpollPoller(EventLoop* loop); ~EpollPoller() override; Timestamp poll(int timeoutMs, ChannelList* activeChannels) override; void updateChannel(Channel* channel) override; void removeChannel(Channel* channel) override; private: static const int kInitEventListSize = 16; void fillActiveChannels(int numEvents, ChannelList* activeChannels) const; void update(int operation, Channel* channel); int epollfd_; std::vector<struct epoll_event> events_; // 用于epoll_wait返回 };

updateChannel和removeChannel是对epoll_ctl的封装。这里有一个关键设计：我们使用一个Map<int, Channel*>来维护文件描述符到Channel对象的映射。这样，当epoll_wait返回后，我们可以通过events_[i].data.fd快速找到对应的Channel对象，并设置其revents_。

注意事项：水平触发(LT)与边缘触发(ET)的选择我们选择使用默认的水平触发（LT）。原因如下：

1. 编程更简单：只要socket缓冲区有数据可读，epoll_wait就会持续报告，程序员可以按需读取，不容易遗漏事件。
2. 与传统select/poll行为一致，降低了理解和使用门槛。
3. 性能并非绝对劣势：在合理的编程模型下（如每次读到EAGAIN），LT的性能与ET相差无几。ET模式要求必须使用非阻塞IO，且必须一次循环读完所有数据，否则会丢失事件，编程复杂度高，容易出错。

我们的库为追求极致性能的用户留出了扩展空间，可以通过配置切换到ET模式，但核心实现和默认推荐是LT。

4.3 Buffer的设计与实现

网络编程中，缓冲区管理是性能的关键。一个良好的Buffer设计需要满足：

1. 避免频繁系统调用：一次read尽量多读数据到用户缓冲区。
2. 方便处理粘包/半包：应用层协议需要从字节流中解析出完整消息。
3. 高效的内存管理：减少拷贝和内存分配。

我们采用经典的“vector<char>+ 两个索引”的设计：

/// +-------------------+------------------+------------------+ /// | prependable bytes | readable bytes | writable bytes | /// | | (CONTENT) | | /// +-------------------+------------------+------------------+ /// | | | | /// 0 <= readerIndex <= writerIndex <= size

• readerIndex：指向下一个可读字节。
• writerIndex：指向下一个可写字节。
• prependable空间：位于readerIndex之前，通常很小（如8字节），用于在序列化时预留空间，方便添加协议头。

核心操作：

• readFd(int fd, int* savedErrno)：从fd读取数据到Buffer的可写区域。如果可写空间不足，会自动扩容。如果一次readv没读完（说明我们提供的缓冲区足够大，但内核中数据更多），会继续尝试读取，直到返回EAGAIN。
• retrieve(size_t len)：应用层从Buffer中取走len字节的数据，实质上是移动readerIndex。
• append(const char* data, size_t len)：向Buffer末尾添加数据，移动writerIndex。
• makeSpace(size_t len)：内部函数，当可写空间不足时，如果前面prependable + readable的空间足够大（即已读数据占了空间），则将所有未读数据移动到缓冲区头部（腾挪），否则才重新分配更大内存。

这种设计使得内存利用率高，且readFd一次系统调用能读取尽可能多的数据，非常高效。

5. TcpConnection的生命周期管理与资源安全

TcpConnection代表一个TCP连接，其生命周期管理是网络库中最容易出错的地方之一。连接可能在任何时候被对方关闭，也可能在本端需要主动关闭。我们必须确保在回调函数执行期间，TcpConnection对象是有效的。

5.1 使用shared_ptr进行生命周期控制

我们让TcpServer和EventLoop持有TcpConnection的shared_ptr。当连接建立时，创建一个TcpConnection的shared_ptr。这个指针会被传递给用户设置的各类回调函数（如消息回调）。只要还有回调函数在执行，或者这个指针的副本还存在，连接对象就不会被销毁。

连接关闭的典型路径：

1. 对方发送FIN，本地Channel触发可读事件，但read返回0。
2. Channel::handleEvent调用closeCallback_。
3. TcpConnection的closeCallback_通常被设置为TcpConnection::handleClose。
4. handleClose中，会将自己从TcpServer的连接Map中移除（这通常会减少一个shared_ptr的引用计数），然后通过queueInLoop将一个销毁函数排入EventLoop队列。注意，这里必须用queueInLoop，确保销毁动作发生在EventLoop线程，且在所有待处理的该连接的事件回调之后。
5. 最终，在EventLoop执行待处理函数队列时，销毁函数被调用，如果此时引用计数为0，则TcpConnection对象被析构，其拥有的socket fd在析构函数中自动关闭。

5.2 主动关闭与“写完成”回调

主动关闭连接（如服务器处理完请求后关闭）也需要小心。不能直接在当前上下文调用close(fd)，因为可能还有数据在发送缓冲区没写完。正确的流程是：

1. 调用TcpConnection::shutdown()。如果此时输出缓冲区已空，则立即开始关闭流程（发送FIN）。
2. 如果输出缓冲区还有数据，则设置一个状态标志，等待缓冲区数据全部被内核发送完毕后，由输出缓冲区清空时的回调来触发关闭流程。

这里可以引入一个writeCompleteCallback_，当输出缓冲区从有数据到清空时触发，用于通知应用层“所有数据已发出”，此时可以安全地调用shutdown。

6. 多线程环境下的性能考量与陷阱

6.1 锁的粒度与无锁设计

在我们的多Reactor模型中，理想情况是每个连接的所有操作都在同一个IO线程内完成，这包括读、写、业务回调。因此，TcpConnection的大部分成员变量不需要加锁，因为只会被一个线程访问。

需要加锁的地方主要集中在：

1. EventLoop的pendingFunctors_队列，因为它会被其他线程访问（通过queueInLoop）。
2. TcpServer中的连接Map（std::unordered_map），因为主Reactor在接收新连接时会插入，而从Reactor在连接关闭时会移除。这里可以使用读写锁（std::shared_mutex，C++17）或更细粒度的锁来优化。

一个重要的无锁技巧：对于TcpConnection的跨线程调用（如其他线程想发送数据），我们通过runInLoop将发送操作转移到IO线程执行，从而避免了在TcpConnection::send方法内部加锁。

6.2 避免“惊群”效应

“惊群”是指多个进程/线程同时监听同一个端口，当新连接到来时，所有监听者都被唤醒，但只有一个能accept成功，其他都白忙活一次，造成CPU浪费。这在传统多进程模型中常见。

在我们的多Reactor模型中，只有一个主Reactor线程在监听端口，所以不存在accept惊群。Linux内核从2.6版本开始，对于SO_REUSEPORT选项，也提供了内核级的负载均衡，可以避免惊群。我们的设计默认是单线程accept，简单高效。

6.3 定时器的精度与效率

定时器队列如果使用std::priority_queue，插入和删除是O(log N)，取最小是O(1)。对于每秒数千次定时操作的场景，这足够了。如果定时器数量巨大（十万级以上），可以考虑时间轮或分层时间轮，它们能在O(1)时间内完成大部分操作。

定时器回调函数应尽量短小精悍，避免阻塞事件循环。耗时操作应投递到专门的线程池。

7. 从构建到测试：一个Echo服务器的例子

理论说了这么多，我们来看一个最简单的应用：Echo服务器。客户端发什么，服务器就回什么。

#include "TcpServer.h" #include "EventLoop.h" #include <iostream> void onConnection(const TcpConnectionPtr& conn) { if (conn->connected()) { std::cout << "New connection from " << conn->peerAddress().toIpPort() << std::endl; } else { std::cout << "Connection closed: " << conn->peerAddress().toIpPort() << std::endl; } } void onMessage(const TcpConnectionPtr& conn, Buffer* buf, Timestamp time) { std::string msg = buf->retrieveAllAsString(); // 取出所有可读数据 std::cout << "Received " << msg.size() << " bytes at " << time.toString() << std::endl; conn->send(msg); // 原样发回 } int main() { EventLoop loop; // 主循环，也作为Acceptor的循环 InetAddress listenAddr(8888); TcpServer server(&loop, listenAddr, "EchoServer"); server.setConnectionCallback(onConnection); server.setMessageCallback(onMessage); server.setThreadNum(4); // 设置4个IO线程（从Reactor） server.start(); loop.loop(); // 进入事件循环 return 0; }

这个例子展示了库的易用性。用户只需关注业务回调。TcpServer内部会处理好线程创建、连接分发、事件监听等所有脏活累活。

编译与构建：我们使用CMake管理项目。核心库编译成静态库或动态库，示例程序链接它。确保开启编译器优化（如-O2）并启用C++11/14标准。

压力测试：可以使用wrk、ab或自己编写多线程客户端进行并发连接和吞吐量测试。重点关注在不同连接数、不同消息大小下的CPU使用率、内存占用和QPS。

8. 常见问题排查与性能调优实录

在实际使用和测试中，你肯定会遇到各种问题。以下是一些典型场景和排查思路：

问题1：服务器在高并发下出现大量TIME_WAIT连接。这是TCP协议的正常行为，主动关闭连接的一方会进入TIME_WAIT状态，等待2MSL（通常60秒）。对于服务器，如果它主动关闭连接，就会积累大量TIME_WAIT。

• 解决：让客户端主动关闭连接。或者在服务器端设置socket选项SO_LINGER，设置l_onoff=1,l_linger=0，这样关闭时会发送RST而非FIN，跳过TIME_WAIT，但这不是优雅关闭，可能丢失数据。更好的方法是调整内核参数net.ipv4.tcp_tw_reuse和net.ipv4.tcp_tw_recycle（注意，tcp_tw_recycle在NAT环境下有问题，Linux 4.12后已废弃）。

问题2：内存缓慢增长，疑似内存泄漏。

• 排查：首先检查TcpConnection的析构函数是否被正确调用。确保所有shared_ptr的持有者（如Server的Map、传递给回调的临时对象）在连接关闭后能正确释放引用。
• 使用Valgrind的memcheck或massif工具进行检测。重点关注Buffer的扩容操作，看是否有不必要的拷贝。

问题3：性能达不到预期，CPU利用率不高。

• 检查：是否使用了调试模式（-g）编译？请使用发布模式（-O2或-O3）。
• 检查：业务回调函数是否耗时过长？如果业务处理慢，会阻塞IO线程。确保耗时的业务操作被投递到独立的线程池。
• 检查：是否产生了不必要的内存拷贝？例如，在onMessage中，如果只是转发数据，可以考虑使用Buffer::retrieveAsString的移动语义版本，或者直接操作Buffer的底层指针，避免复制。
• 使用性能分析工具：如perf或gprof，找出热点函数。常见热点可能在epoll_wait、Buffer的移动/拷贝、std::function的调用上。

问题4：客户端报告连接被重置（RST）。

• 可能原因1：服务器在输出缓冲区还有数据未发送时，就关闭了socket。确保关闭流程是：先shutdown(SHUT_WR)发送FIN，等待对方关闭，或者等writeCompleteCallback触发后再完全关闭。
• 可能原因2：对方发送了数据，但本端应用层还没来得及读，连接就被关闭了。确保在Channel的handleEvent中，先处理错误和关闭事件，再处理读事件。

一个重要的调试技巧：日志。在关键路径（如连接建立/关闭、数据收发、错误发生）添加详细的日志输出，并可以设置不同的日志级别（DEBUG, INFO, ERROR）。当问题出现时，日志是还原现场最有力的工具。我们的网络库应该内置一个可配置的日志模块。

9. 进阶思考与扩展方向

一个基础的高性能网络库骨架已经完成。在此基础上，你可以根据需求进行深度扩展：

1. 支持UDP：设计UdpChannel和UdpServer。UDP是无连接的，所以不需要TcpConnection。核心是Channel关注socket的可读事件，在回调中调用recvfrom。
2. 集成应用层协议：在TcpConnection的onMessage回调之上，可以封装出HttpContext、WebSocketHandler等，实现完整的HTTP服务器或WebSocket服务器。
3. SSL/TLS支持：集成OpenSSL或BoringSSL，实现SslTcpConnection。难点在于SSL的握手是异步的，需要将其状态机与事件循环结合起来。
4. 更高级的负载均衡：在主Reactor的Acceptor中，实现更智能的连接分发策略，如基于源IP哈希、基于连接数负载等，而不仅仅是Round-Robin。
5. 监控与统计：为TcpServer和每个TcpConnection添加统计信息，如收发字节数、连接时长、当前状态等，并通过管理接口暴露出来。

亲手实现一遍这个网络库，你会对“高并发”这三个字有刻骨铭心的理解。你会明白，所谓高性能，不仅仅是选择epoll或kqueue，更是对线程模型、资源生命周期、内存管理、异常处理等细节的极致打磨。这个过程充满挑战，但当你看到自己编写的服务器轻松应对数千并发连接时，那种成就感是无与伦比的。