【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){intclientfd=accept(sockfd,NULL,NULL);pthread_ttid;pthread_create(&tid,NULL,client_worker,(void*)(long)clientfd);pthread_detach(tid);}

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

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

intepfd=epoll_create1(0);epoll_ctl(epfd,EPOLL_CTL_ADD,sockfd,&ev);while(1){intn=epoll_wait(epfd,events,maxevents,-1);for(inti=0;i<n;i++){if(events[i].data.fd==sockfd){intclientfd=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