这次我们来看一个C++ Web服务器的性能优化案例。标题里提到的“从9千到5.8万请求/秒”这个数字非常吸引人，它直接点出了性能提升的核心：非阻塞架构。这不仅仅是代码层面的小修小补，而是从传统的多线程阻塞模型，转向了基于事件驱动和I/O多路复用的现代高并发架构。对于正在学习网络编程、准备面试，或者希望优化现有服务性能的开发者来说，理解这个转变背后的技术选型和实现细节，远比单纯看一个数字更有价值。

这个项目由Tomas Diblik分享，它清晰地展示了两种架构（多线程阻塞 vs. 单线程非阻塞/事件驱动）在相同硬件和负载下的性能天壤之别。9千QPS可能是一个典型但效率不高的多线程服务器的表现，而5.8万QPS则代表了经过精心设计的非阻塞架构所能达到的水平。本文不会只停留在概念上，我们会拆解这两种架构的核心差异，探讨如何从零开始构建或改造一个高性能的C++ Web服务器，并分析在实现过程中需要关注的关键点，如连接管理、事件循环、资源调度等。

如果你关心如何让自己的服务扛住高并发、如何降低服务器资源消耗、或者想深入理解Nginx、Redis这类高性能服务器背后的原理，那么这篇文章会提供一条清晰的实践路径。我们将从架构对比入手，然后深入到环境准备、代码示例、性能测试方法以及常见的问题排查。

1. 核心能力速览：阻塞 vs. 非阻塞

在深入细节之前，我们先通过一个表格快速了解传统多线程阻塞架构与现代非阻塞事件驱动架构的核心区别，这能帮你快速判断哪种方案更适合你的场景。

从表格可以看出，非阻塞架构的核心优势在于用更少的系统资源（尤其是线程）支撑更高的并发连接数。性能“杀疯了”的根源，就在于将宝贵的CPU时间从无谓的线程等待（阻塞）中解放出来，只用于处理真正有数据可读/可写的连接。

2. 适用场景与使用边界

非阻塞架构的Web服务器并非银弹，理解其适用边界至关重要。

它非常适合以下场景：

• 高并发短连接服务：例如API网关、微服务入口、实时消息推送、在线游戏服务器。这些场景下连接建立和断开频繁，非阻塞模型可以快速处理大量连接的生命周期。
• I/O密集型应用：服务的大部分时间在等待网络I/O、磁盘I/O或数据库响应。事件循环可以在此期间处理其他连接的请求，极大提升CPU利用率。
• 资源受限环境：在云服务器或容器中，内存和CPU核数有限，你需要用最小的资源支撑尽可能多的用户。
• 学习高性能网络编程：如果你想深入理解Nginx、Redis等软件的底层机制，亲手实现一个简易的非阻塞服务器是最好的途径。

它可能不是最佳选择，或需要额外设计的场景：

• 长时间阻塞的计算任务：如果一个请求需要进行复杂的CPU计算（如图像处理、大规模数据排序），它会阻塞整个事件循环，导致其他所有连接被“饿死”。解决方案是将计算任务卸载到独立的线程池，计算完成后通过事件循环机制通知主线程返回结果。
• 强事务性、复杂状态的业务逻辑：异步回调风格的代码可能比线性阻塞代码更难编写和维护，尤其是在业务逻辑复杂时。需要精心设计状态机。
• 已有基于线程池的复杂系统：如果现有系统业务逻辑与线程模型深度耦合，重构为事件驱动的成本可能很高。

安全与合规边界：

• 网络监听：确保服务器只监听必要的端口和IP地址（如127.0.0.1或内网IP），避免暴露在公网带来安全风险。
• 资源限制：实现连接数限制、请求频率限制，防止恶意连接耗尽服务器资源（DDoS攻击的一种形式）。
• 输入验证：对所有接收到的HTTP请求头、请求体进行严格的验证和过滤，防止缓冲区溢出、路径遍历等注入攻击。
• 依赖管理：使用现代C++（如C++11/17）的标准库和公认稳定的第三方网络库（如Boost.Asio），可以减少底层安全漏洞的风险。

3. 环境准备与前置条件

在开始编码之前，你需要准备好开发和测试环境。以下清单基于Linux系统（这是非阻塞服务器开发和生产部署的主要平台），但原理同样适用于macOS（使用kqueue）和Windows（使用IOCP）。

操作系统与编译器：

• Linux发行版：Ubuntu 20.04/22.04 LTS, CentOS 7/8, 或其他主流发行版。内核版本影响epoll的某些特性，但主流版本均支持。
• C++编译器：GCC 7+或Clang 5+。强烈建议使用支持C++11及以上标准的编译器，以便使用智能指针、lambda表达式、移动语义等现代特性，让异步代码更安全、简洁。
• 构建系统：CMake（推荐，便于跨平台）或直接使用Makefile。

开发工具与库：

• 调试工具：gdb(GNU Debugger),valgrind(内存检查)，strace/ltrace(系统调用跟踪)。
• 性能分析工具：perf(Linux性能分析器),htop/top(查看资源占用)。
• 网络调试工具：curl(发送HTTP请求),ab(ApacheBench, 压力测试),wrk(更现代的压力测试工具)，netcat(nc, 原始TCP测试)。
• 第三方库（可选但推荐）：
  • Boost.Asio：一个跨平台的C++网络库，封装了epoll/kqueue/IOCP，可以大幅降低直接使用系统调用的复杂度。对于初学者或追求快速开发的项目是极佳选择。
  • libevent / libuv：成熟的事件通知库。如果你不想从零开始写事件循环，可以使用它们。

测试环境：

• 服务器：一台用于运行待测试的Web服务器。可以是本地虚拟机、云服务器或物理机。
• 压力测试机：最好是一台独立的机器，用于运行wrk或ab，避免测试工具与服务器竞争资源。如果资源有限，在同一台机器上测试时，需注意解释结果（网络环回接口lo的速度极快，可能掩盖真实网络延迟问题）。
• 系统参数调整（用于极限压测）：可能需要临时提高系统的文件描述符限制和临时端口范围。

  # 查看当前限制 ulimit -n # 临时提高当前会话的限制（例如到100000） ulimit -n 100000 # 查看临时端口范围 sysctl net.ipv4.ip_local_port_range # 临时扩大端口范围（用于压力测试客户端） sudo sysctl -w net.ipv4.ip_local_port_range="1024 65535"

4. 从阻塞到非阻塞：架构与代码对比

让我们通过一个最简单的“回声服务器”（Echo Server）例子，直观感受两种架构的代码差异。这个服务器接收客户端发来的任何数据，并原样发回。

4.1 多线程阻塞式服务器（简版）

// blocking_echo_server.cpp #include <iostream> #include <thread> #include <sys/socket.h> #include <netinet/in.h> #include <unistd.h> #include <cstring> void handle_client(int client_sock) { char buffer[1024]; while (true) { // 阻塞点：read会一直等待，直到客户端发来数据或关闭连接 ssize_t bytes_read = read(client_sock, buffer, sizeof(buffer)); if (bytes_read <= 0) { break; // 连接关闭或出错 } // 阻塞点：write也可能阻塞，直到内核缓冲区有空间 write(client_sock, buffer, bytes_read); } close(client_sock); } int main() { int server_fd = socket(AF_INET, SOCK_STREAM, 0); sockaddr_in addr{}; addr.sin_family = AF_INET; addr.sin_addr.s_addr = INADDR_ANY; addr.sin_port = htons(8080); bind(server_fd, (sockaddr*)&addr, sizeof(addr)); listen(server_fd, 128); // 设置监听队列 std::cout << "Blocking echo server listening on port 8080...\n"; while (true) { sockaddr_in client_addr{}; socklen_t client_len = sizeof(client_addr); // 阻塞点：accept等待新连接 int client_sock = accept(server_fd, (sockaddr*)&client_addr, &client_len); // 为每个新连接创建一个线程 std::thread(handle_client, client_sock).detach(); } close(server_fd); return 0; }

问题分析：

1. 线程爆炸：每来一个连接就创建一个线程。连接数上万时，系统将创建上万个线程，内存和调度开销巨大。
2. 资源浪费：即使连接上没有数据可读（客户端只是在保持连接），线程也会阻塞在read调用上，白白占用系统资源。
3. 性能瓶颈：大量线程间的上下文切换（Context Switch）会消耗大量CPU时间，导致实际处理业务的CPU时间减少。

4.2 单线程非阻塞式服务器（使用epoll）

// nonblocking_echo_server.cpp #include <iostream> #include <sys/socket.h> #include <netinet/in.h> #include <unistd.h> #include <cstring> #include <fcntl.h> #include <sys/epoll.h> #include <vector> #include <cerrno> int set_nonblocking(int fd) { int flags = fcntl(fd, F_GETFL, 0); if (flags == -1) return -1; return fcntl(fd, F_SETFL, flags | O_NONBLOCK); } int main() { int server_fd = socket(AF_INET, SOCK_STREAM, 0); // 设置SO_REUSEADDR，避免TIME_WAIT状态导致端口无法立即重用 int opt = 1; setsockopt(server_fd, SOL_SOCKET, SO_REUSEADDR, &opt, sizeof(opt)); sockaddr_in addr{}; addr.sin_family = AF_INET; addr.sin_addr.s_addr = INADDR_ANY; addr.sin_port = htons(8080); bind(server_fd, (sockaddr*)&addr, sizeof(addr)); listen(server_fd, 128); // 将监听socket设置为非阻塞 set_nonblocking(server_fd); // 创建epoll实例 int epoll_fd = epoll_create1(0); epoll_event ev{}; ev.events = EPOLLIN; // 监听可读事件 ev.data.fd = server_fd; epoll_ctl(epoll_fd, EPOLL_CTL_ADD, server_fd, &ev); std::vector<epoll_event> events(1024); // 用于接收就绪事件 std::cout << "Non-blocking echo server listening on port 8080...\n"; while (true) { // 阻塞点：等待事件发生。超时时间设为-1表示一直等待。 int nfds = epoll_wait(epoll_fd, events.data(), events.size(), -1); for (int i = 0; i < nfds; ++i) { int fd = events[i].data.fd; if (fd == server_fd) { // 有新连接到来 sockaddr_in client_addr{}; socklen_t client_len = sizeof(client_addr); int client_sock = accept(server_fd, (sockaddr*)&client_addr, &client_len); if (client_sock >= 0) { set_nonblocking(client_sock); epoll_event client_ev{}; client_ev.events = EPOLLIN | EPOLLET; // 边缘触发(Edge Trigger)模式 client_ev.data.fd = client_sock; epoll_ctl(epoll_fd, EPOLL_CTL_ADD, client_sock, &client_ev); std::cout << "New client connected: " << client_sock << std::endl; } } else { // 已连接套接字有事件（数据可读） if (events[i].events & EPOLLIN) { char buffer[1024]; while (true) { // 边缘触发模式下需要循环读取，直到读完 ssize_t bytes_read = read(fd, buffer, sizeof(buffer)); if (bytes_read > 0) { // 简单回声，实际应处理写缓冲区满的情况 write(fd, buffer, bytes_read); } else if (bytes_read == 0) { // 客户端关闭连接 std::cout << "Client disconnected: " << fd << std::endl; epoll_ctl(epoll_fd, EPOLL_CTL_DEL, fd, nullptr); close(fd); break; } else { if (errno == EAGAIN || errno == EWOULDBLOCK) { // 非阻塞socket，数据已读完 break; } else { // 发生错误 perror("read error"); epoll_ctl(epoll_fd, EPOLL_CTL_DEL, fd, nullptr); close(fd); break; } } } } // 可以在这里处理EPOLLOUT事件（当写缓冲区可写时） } } } close(server_fd); close(epoll_fd); return 0; }

核心改进：

1. 单线程事件循环：只有一个主线程在epoll_wait处等待。所有连接的I/O事件（新连接、数据可读、可写）都通过epoll通知到这个线程。
2. 非阻塞I/O：所有socket都被设置为O_NONBLOCK。read和write在无法立即完成时会立即返回错误（EAGAIN），而不是阻塞线程。
3. 高效事件通知：epoll只返回已经就绪（有数据可读、可写等）的文件描述符，避免了遍历所有连接的开销（这是与select/poll的主要区别）。
4. 边缘触发(ET)模式：EPOLLET标志指示epoll使用边缘触发。在这种模式下，一个事件（例如socket可读）只会被通知一次，直到下一次有新的数据到来。这要求应用程序必须一次性将缓冲区中的数据全部读完（使用循环），否则剩余数据将不会再次触发事件。ET模式通常性能更高，但编程更需小心。

5. 构建一个简单的HTTP/1.1服务器

回声服务器展示了I/O模型，但一个真正的Web服务器需要解析HTTP协议。下面我们扩展非阻塞服务器，使其能够处理简单的HTTP GET请求并返回一个静态响应。

我们将设计一个简单的状态机来处理每个HTTP连接。为了简化，我们假设请求不大，可以一次性读入缓冲区。

// simple_http_server.cpp (关键部分) #include <string> #include <unordered_map> // ... 其他头文件和set_nonblocking, epoll设置等与上文类似 ... struct HttpConnection { int fd; std::string read_buffer; // 读取客户端请求的缓冲区 std::string write_buffer; // 准备发送给客户端的响应缓冲区 // 可以添加更多状态，如解析状态、请求头等 }; std::unordered_map<int, HttpConnection> connections; // 管理所有连接状态 void handle_read_event(int fd) { auto it = connections.find(fd); if (it == connections.end()) return; auto& conn = it->second; char buf[4096]; while (true) { ssize_t n = read(fd, buf, sizeof(buf)); if (n > 0) { conn.read_buffer.append(buf, n); // 尝试解析请求（这里简化处理，寻找\r\n\r\n） size_t pos = conn.read_buffer.find("\r\n\r\n"); if (pos != std::string::npos) { // 收到完整的请求头 std::string request = conn.read_buffer.substr(0, pos+4); std::cout << "Request from " << fd << ":\n" << request << std::endl; // 构建一个简单的HTTP响应 std::string response = "HTTP/1.1 200 OK\r\n"; response += "Content-Type: text/plain\r\n"; response += "Connection: close\r\n"; response += "\r\n"; response += "Hello from non-blocking C++ server!\n"; response += "Your request header was:\n" + request; conn.write_buffer = std::move(response); // 修改epoll监听事件，加入可写事件 epoll_event ev{}; ev.events = EPOLLOUT | EPOLLET; ev.data.fd = fd; epoll_ctl(epoll_fd, EPOLL_CTL_MOD, fd, &ev); break; // 请求处理完毕，跳出读循环 } } else if (n == 0) { // 连接关闭 close_connection(fd); break; } else { if (errno == EAGAIN || errno == EWOULDBLOCK) break; perror("read"); close_connection(fd); break; } } } void handle_write_event(int fd) { auto it = connections.find(fd); if (it == connections.end()) return; auto& conn = it->second; if (!conn.write_buffer.empty()) { ssize_t n = write(fd, conn.write_buffer.data(), conn.write_buffer.size()); if (n > 0) { conn.write_buffer.erase(0, n); // 移除已发送的数据 } else { if (errno != EAGAIN && errno != EWOULDBLOCK) { perror("write"); close_connection(fd); } } } // 如果响应已全部发送完毕，可以关闭连接（短连接）或重新监听读事件（长连接） if (conn.write_buffer.empty()) { // 这里我们选择关闭连接（HTTP/1.0 风格） close_connection(fd); } } void close_connection(int fd) { epoll_ctl(epoll_fd, EPOLL_CTL_DEL, fd, nullptr); close(fd); connections.erase(fd); std::cout << "Connection closed: " << fd << std::endl; } // 在主循环中 while (true) { int nfds = epoll_wait(epoll_fd, events.data(), events.size(), -1); for (int i = 0; i < nfds; ++i) { int fd = events[i].data.fd; if (fd == server_fd) { // 接受新连接，创建HttpConnection对象，加入connections map，并添加到epoll监听读事件 // ... (代码略，参考上文accept部分) ... HttpConnection conn{client_sock}; connections[client_sock] = std::move(conn); } else { if (events[i].events & EPOLLIN) { handle_read_event(fd); } if (events[i].events & EPOLLOUT) { handle_write_event(fd); } // 处理错误事件 EPOLLERR, EPOLLHUP if (events[i].events & (EPOLLERR | EPOLLHUP)) { close_connection(fd); } } } }

这个简单的HTTP服务器展示了非阻塞架构下如何处理协议：

1. 状态管理：每个连接用一个HttpConnection对象维护其状态（读缓冲区、写缓冲区等）。
2. 异步读写：读事件触发时，将数据累积到读缓冲区，并尝试解析HTTP请求头。一旦收到完整的请求，就生成响应放入写缓冲区，并将该连接的epoll监听事件改为EPOLLOUT。
3. 写事件处理：当内核写缓冲区可用时（EPOLLOUT触发），将写缓冲区中的数据发送出去。发送完毕后，根据策略（短连接/长连接）决定关闭连接还是切换回监听读事件。
4. 边缘触发处理：在handle_read_event和handle_write_event中，我们都使用了循环，以确保在边缘触发模式下，一次性读完或写完所有可用数据。

6. 性能测试与效果验证

理论再好，也需要用数据说话。我们将使用wrk这个现代HTTP压测工具来对比阻塞和非阻塞服务器的性能。

测试环境假设：

• 服务器：4核CPU， 8GB内存， Linux。
• 客户端：另一台同配置机器，或本机（需注意资源竞争）。
• 网络：千兆局域网或本地环回（127.0.0.1）。

测试步骤：

1. 编译服务器程序：

   # 编译阻塞版本 g++ -std=c++11 -pthread blocking_echo_server.cpp -o blocking_server # 编译非阻塞版本 g++ -std=c++11 nonblocking_echo_server.cpp -o nonblocking_server # 编译简单HTTP服务器 g++ -std=c++11 simple_http_server.cpp -o http_server

2. 启动服务器：

   ./http_server # 监听8080端口

3. 使用wrk进行压力测试：

   # 基本用法：wrk -t <线程数> -c <连接数> -d <持续时间> <URL> # 测试短连接（每个请求新建连接） wrk -t12 -c100 -d30s http://127.0.0.1:8080/ # 测试长连接（HTTP Keep-Alive） wrk -t12 -c100 -d30s -H "Connection: keep-alive" http://127.0.0.1:8080/

4. 解读wrk输出：

   Running 30s test @ http://127.0.0.1:8080/ 12 threads and 100 connections Thread Stats Avg Stdev Max +/- Stdev Latency 1.23ms 192.05us 10.88ms 90.34% Req/Sec 6.77k 575.48 8.88k 71.17% Latency Distribution 50% 1.21ms 75% 1.28ms 90% 1.38ms 99% 1.79ms 2428090 requests in 30.10s, 2.16GB read Requests/sec: 80658.05 # 这是最重要的QPS指标 Transfer/sec: 73.49MB

   • Requests/sec (QPS)：每秒处理的请求数。这是衡量吞吐量的核心指标。非阻塞服务器在应对大量并发连接时，此数值会远高于多线程阻塞服务器。
   • Latency：延迟。平均延迟、延迟分布（P50, P99）。非阻塞架构通常能提供更稳定、更低的延迟，因为避免了线程调度带来的抖动。
   • Transfer/sec：每秒数据传输量。

预期结果对比（模拟数据，实际以测试为准）：

为什么非阻塞能实现数倍提升？

1. 消除线程开销：没有成千上万的线程，节省了大量内存（每个线程的栈）和CPU上下文切换时间。
2. 减少系统调用：epoll_wait一次可以返回多个就绪事件，比为每个连接调用read（可能阻塞）效率高得多。
3. 更好的CPU缓存利用率：单线程事件循环的数据局部性更好，代码和数据更可能留在CPU缓存中。

7. 进阶优化与生产级考量

要实现一个接近“5.8万QPS”甚至更高的生产级服务器，还需要考虑以下关键点：

7.1 多线程/多进程扩展

单线程事件循环无法利用多核CPU。主流方案是：

• 多Reactor模式：启动多个事件循环线程（每个绑定一个独立的epoll实例），每个线程独立accept新连接（需要SO_REUSEPORT支持）或由一个主Acceptor线程分配连接给工作线程。这是Nginx采用的模式。
• 领导者/追随者模式：线程池中的线程轮流担任“领导者”来监听事件，当事件发生时，该线程将其处理权交给另一个“追随者”线程，自己则去处理事件。这避免了锁竞争。

7.2 高效的缓冲区管理

• 避免为每个连接的小数据包频繁分配/释放内存。可以使用内存池或缓冲区链。
• 实现写缓冲区队列。当write返回EAGAIN时，应将剩余数据放入该连接的写队列，并监听EPOLLOUT事件，待可写时继续发送。

7.3 定时器管理

用于处理超时，如连接超时、请求超时。可以使用时间轮、最小堆等数据结构来高效管理大量定时器。

7.4 协议解析优化

• HTTP/1.1解析状态机应高效，避免不必要的拷贝。
• 考虑支持HTTP/2，其多路复用特性与非阻塞架构是天作之合，能进一步提升性能。
• 实现静态文件发送时，应使用sendfile系统调用实现零拷贝（Zero-Copy），避免数据在内核和用户态之间来回拷贝。

7.5 使用成熟库：Boost.Asio示例

从零实现所有细节非常复杂。使用Boost.Asio可以大幅提升开发效率：

#include <boost/asio.hpp> #include <iostream> using boost::asio::ip::tcp; class session : public std::enable_shared_from_this<session> { public: session(tcp::socket socket) : socket_(std::move(socket)) {} void start() { do_read(); } private: void do_read() { auto self(shared_from_this()); socket_.async_read_some(boost::asio::buffer(data_, max_length), [this, self](boost::system::error_code ec, std::size_t length) { if (!ec) { do_write(length); } }); } void do_write(std::size_t length) { auto self(shared_from_this()); boost::asio::async_write(socket_, boost::asio::buffer(data_, length), [this, self](boost::system::error_code ec, std::size_t /*length*/) { if (!ec) { do_read(); } }); } tcp::socket socket_; enum { max_length = 1024 }; char data_[max_length]; }; class server { public: server(boost::asio::io_context& io_context, short port) : acceptor_(io_context, tcp::endpoint(tcp::v4(), port)) { do_accept(); } private: void do_accept() { acceptor_.async_accept( [this](boost::system::error_code ec, tcp::socket socket) { if (!ec) { std::make_shared<session>(std::move(socket))->start(); } do_accept(); }); } tcp::acceptor acceptor_; }; int main() { try { boost::asio::io_context io_context; server s(io_context, 8080); io_context.run(); // 启动事件循环 } catch (std::exception& e) { std::cerr << "Exception: " << e.what() << "\n"; } return 0; }

Boost.Asio帮你处理了非阻塞I/O、事件循环、缓冲区管理等复杂细节，让你更专注于业务逻辑。

8. 常见问题与排查方法

在开发和使用非阻塞服务器时，你可能会遇到以下问题：

9. 最佳实践与使用建议

1. 从简单开始，逐步迭代：不要一开始就追求完美的多Reactor、内存池。先实现一个正确的单线程非阻塞服务器，验证功能，再用wrk测试性能。然后逐步引入多线程、优化缓冲区。
2. 善用现有工具和库：如果不是为了深入学习和研究，在生产环境中，直接使用Nginx、Envoy等成熟的反向代理/Web服务器，或者使用Boost.Asio、libevent等库来构建业务逻辑，是更稳妥、高效的选择。
3. 监控与度量：在生产环境中，为服务器添加详细的度量指标（Metrics），如：当前连接数、QPS、不同百分位的延迟、错误率。这有助于你了解系统状态和性能瓶颈。
4. 防御性编程：
   • 设置资源限制：最大连接数、单个请求大小、请求超时时间。
   • 验证所有输入：防止缓冲区溢出和注入攻击。
   • 优雅关闭：收到SIGTERM信号时，应停止接受新连接，完成已建立连接的请求处理后再退出。
5. 测试，测试，再测试：
   • 单元测试：测试协议解析、状态机等逻辑单元。
   • 集成测试：模拟客户端进行端到端测试。
   • 压力测试：使用wrk,ab,jmeter等进行长时间、高并发压测，观察内存、CPU、网络指标是否稳定。
   • 混沌测试：模拟网络延迟、断开、包重排等异常情况，确保服务器健壮性。

从“9千到5.8万请求/秒”的飞跃，本质上是将编程思维从“一个连接一个线程”的同步阻塞模式，切换到“一个线程处理所有连接”的异步事件驱动模式。这种转变解锁了C++在构建高性能网络服务方面的巨大潜力。虽然自己动手实现一个完整的生产级服务器挑战巨大，但通过理解epoll/kqueue、非阻塞I/O、状态机、缓冲区管理等核心概念，你不仅能更好地使用Nginx等现有工具，也能在需要深度定制高性能中间件时拥有坚实的技术基础。建议从本文的代码示例开始，亲手编译、运行、修改、压测，感受性能数字变化带来的最直接的反馈，这是理解高并发网络编程最有效的方式。