【C/C++】TCP 服务器演进：从阻塞 accept 到 epoll 事件驱动

TCP 服务器演进：从阻塞 accept 到 epoll 事件驱动

学习代码：tcp/tcp_server.c、tcp/mul_tcp_server.c、tcp/mul_port_client_epoll.c

TCP 服务器是 Linux 网络编程里绕不开的一关。最基础的流程很固定：socket() 创建套接字，bind() 绑定端口，listen() 开始监听，accept() 接收连接，然后对客户端 read/write。这条线跑通之后，问题马上出现：如果单线程阻塞处理，一个客户端卡住，后面的客户端就都要等。

最直接的升级是多线程服务器。每来一个连接，就创建一个线程单独处理：

while (1)
{
    int clientfd = accept(sockfd, NULL, NULL);
    pthread_t tid;
    pthread_create(&tid, NULL, client_worker, (void *)(long)clientfd);
    pthread_detach(tid);
}

这种写法容易理解，也能解决“一个客户端占住所有处理流程”的问题。但它的代价是线程数量会跟着连接数量增长。连接少时没问题，连接很多时，每个线程都要栈空间和调度成本，系统资源会被迅速吃掉。

于是引入 epoll。它的核心思路不是“每个连接一个线程”，而是“一个线程监听很多 fd 的事件”。典型流程是：

int epfd = epoll_create1(0);
epoll_ctl(epfd, EPOLL_CTL_ADD, sockfd, &ev);

while (1)
{
    int n = epoll_wait(epfd, events, maxevents, -1);
    for (int i = 0; i < n; i++)
    {
        if (events[i].data.fd == sockfd)
        {
            int clientfd = accept(sockfd, NULL, NULL);
            epoll_ctl(epfd, EPOLL_CTL_ADD, clientfd, &client_ev);
        }
        else
        {
            recv(events[i].data.fd, buf, sizeof(buf), 0);
        }
    }
}

这里的关键变化是：程序不再主动挨个问每个连接有没有数据，而是把 fd 注册给内核，由 epoll_wait 返回已经就绪的事件。这样连接数量很大但活跃连接不多时，效率会明显更高。

学习中还要区分水平触发和边沿触发。水平触发比较像“只要缓冲区还有数据，就一直提醒你”；边沿触发则是“状态从无到有时提醒一次”。边沿触发性能潜力更高，但必须配合非阻塞 IO，并且读到 EAGAIN，否则没读完的数据可能再也不会提醒。

我的体会是，服务器模型的升级本质上是在控制资源：单线程省资源但并发弱，多线程并发直观但线程成本高，epoll 把并发压力转移到事件驱动模型上。真正写高并发程序时，代码结构、触发模式、非阻塞处理、文件描述符限制、内核参数都要一起考虑。
学习链接: https://github.com/0voice