TCP 服务器演进从阻塞 accept 到 epoll 事件驱动学习代码tcp/tcp_server.c、tcp/mul_tcp_server.c、tcp/mul_port_client_epoll.cTCP 服务器是 Linux 网络编程里绕不开的一关。最基础的流程很固定socket()创建套接字bind()绑定端口listen()开始监听accept()接收连接然后对客户端read/write。这条线跑通之后问题马上出现如果单线程阻塞处理一个客户端卡住后面的客户端就都要等。最直接的升级是多线程服务器。每来一个连接就创建一个线程单独处理while(1){intclientfdaccept(sockfd,NULL,NULL);pthread_ttid;pthread_create(tid,NULL,client_worker,(void*)(long)clientfd);pthread_detach(tid);}这种写法容易理解也能解决“一个客户端占住所有处理流程”的问题。但它的代价是线程数量会跟着连接数量增长。连接少时没问题连接很多时每个线程都要栈空间和调度成本系统资源会被迅速吃掉。于是引入epoll。它的核心思路不是“每个连接一个线程”而是“一个线程监听很多 fd 的事件”。典型流程是intepfdepoll_create1(0);epoll_ctl(epfd,EPOLL_CTL_ADD,sockfd,ev);while(1){intnepoll_wait(epfd,events,maxevents,-1);for(inti0;in;i){if(events[i].data.fdsockfd){intclientfdaccept(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
)