C语言自研Web服务器遇客户端连接后不发数据的处理与socket配置问题

你遇到的两种recv返回值的本质含义 #

• 接收超时设为1秒时recv返回-1、errno为EAGAIN：你给客户端套接字配置的接收超时到期，内核没有收到任何客户端发来的应用层数据，主动中断了等待
• 接收超时设为5秒时recv返回0、无错误码：这不是“收不到数据”，是客户端主动发送了TCP FIN包，代表客户端已经关闭了自身的发送方向，这个连接已经没有任何后续数据会发过来了——这也是Firefox和Chrome表现不一致的根源：Firefox做连接预探测时，三次握手完成后如果确认不需要发送请求，会直接发FIN断开连接；Chrome的预连接逻辑会保留连接等待实际请求触发，所以在Chrome场景下不会碰到这类空连接。

核心问题1：客户端完成TCP连接但不发送数据时的处理逻辑 #

首先要明确：TCP三次握手完成仅代表网络通路打通，不代表客户端一定会发送有效应用层数据。浏览器预连接、探测连接可用性、主动取消连接等场景，都会出现“握手完成但不发HTTP请求”的情况，这类连接的处理逻辑要严格按照recv的返回值分支判断，不要直接让服务端异常退出：

• recv返回值r > 0：拿到了实际的应用层数据，走正常HTTP请求解析流程
• recv返回值r == 0：对端已通过FIN包关闭发送通道，直接调用close(fd)回收连接资源即可，不需要做额外处理
• recv返回值r == -1：通过errno判断，若是EAGAIN/EWOULDBLOCK（超时无数据）、ECONNRESET（连接被重置）等常规错误，同样直接close(fd)回收即可，不要让这类无有效请求的空连接长期占用文件描述符

核心问题2：能不能让accept()仅在客户端有实际数据可读取时才返回 #

从Linux内核socket的设计逻辑上，完全满足这个需求的机制是不存在的：

• accept()的触发条件是内核收到了三次握手的最后一个ACK包，代表TCP连接建立完成，此时客户端的应用层数据可能还在网络传输中，也可能根本不会发送，内核没有能力预判连接建立后会不会有应用层数据
• 你之前用poll()监听监听套接字sfd时拿到POLLIN事件，触发的是“内核已经收到了完整的TCP连接，可以被accept提取”，和客户端有没有发应用层数据没有任何关联，自然会出现accept完等不到数据的问题。

补充说明：Linux内核提供了TCP_DEFER_ACCEPT套接字选项，可以实现近似效果——开启后内核会等收到客户端的实际应用层数据时，才把这个连接放入accept的可获取队列，没收到数据的空连接会一直在内核队列里等待。但这个只是内核层面的优化，不能替代完整的事件驱动逻辑。

你之前实现的poll存在的问题 #

你写的poll调用存在两处典型错误：

1. 参数传递错误：poll()的第一个参数是struct pollfd类型的数组首地址，你代码里定义了数组p，但调用时却直接把sfd（监听套接字的文件描述符数值）作为第一个参数传进去了——哪怕凑巧返回值是1，事件检测的结果也是完全不可靠的
2. 监听范围缺失：你只把监听套接字加入了poll的监听列表，没有把后续accept出来的客户端套接字纳入监听，自然无法检测客户端有没有实际数据。

正确的事件驱动实现流程 #

你想要的“只有客户端有实际数据时才处理”的效果，需要把新连接监听、已连接数据就绪两类事件拆分处理，标准流程为：

1. 将所有socket（包括监听套接字sfd、后续所有accept拿到的客户端套接字）统一设置为非阻塞模式
2. 用poll/epoll这类多路复用接口，统一维护所有需要监听的socket集合：
   • 当监听套接字sfd触发POLLIN事件时，循环调用accept()把内核队列里所有已完成的连接全部取出，将拿到的客户端fd加入多路复用的监听集合，为其注册POLLIN事件
   • 当某个客户端fd触发POLLIN事件时，才代表这个客户端套接字的内核接收缓冲区里已经有实际数据可以读取，此时调用recv()是完全可靠的，不会出现空连接等待的问题
3. 给所有客户端连接设置合理的空闲超时阈值（比如10秒内没有任何数据交互就主动回收），避免无请求的空连接持续占用系统资源。

内容的提问来源于stack exchange，提问作者Cosinus