一个出现异常CLOSE_WAIT连接的问题
项目测试过程中出现大量CLOSE_WAIT状态的连接，后来发现是给进程设置的open files数目太少导致。下面还原这个问题。
复现
从网上找了个使用了epoll的 web server，拉取下来后，执行以下命令进行编译：
cd MiniHttpd
cmake .
make
项目用到了zlib和libconfig，如果编译报错，Ubuntu下可以尝试执行以下命令安装：
sudo apt-get install zlib1g-dev
sudo apt-get install libconfig libconfig++-dev libconfig-dev
修改HttpServer.cpp文件：
--- a/src/HttpServer.cpp
+++ b/src/HttpServer.cpp
@@ -77,7 +77,7 @@ void HttpServer::load_config(string path){
}
catch(FileIOException io_exception){
cout<<"Config not found, use default settings"<<endl;
- port = 0;
+ port = 9999;
baseURL = "/home/wuyuixn/Webroot";
request_queue_length = 5;
}
@@ -138,7 +138,9 @@ void HttpServer::start_listen(){
while(1){
int number = epoll_wait(epollfd, events, MAX_EVENT_NUMBER, -1);
for (int i = 0; i < number; i++){
int sockfd = events[i].data.fd;
//处理新到的客户连接
if (sockfd == server_sock){
int client_sock = -1;
struct sockaddr_in client_name;
socklen_t client_name_len = sizeof(client_name);
client_sock = accept(server_sock,
(struct sockaddr *)&client_name,
&client_name_len);
+ printf("accept %d\n", client_sock);
if (client_sock == -1){
+ fprintf(stderr, "errno is %d (%s)\n", errno, strerror(errno));
Log::log("accept failed",ERROR);
continue;
}
重新make，执行./Minihttpd，用ls -p pid看一下一共打开了6个文件描述符：
Minihttpd 242544 vbox 0u CHR 136,4 0t0 7 /dev/pts/4
Minihttpd 242544 vbox 1u CHR 136,4 0t0 7 /dev/pts/4
Minihttpd 242544 vbox 2u CHR 136,4 0t0 7 /dev/pts/4
Minihttpd 242544 vbox 3u IPv4 656642 0t0 TCP *:9999 (LISTEN)
Minihttpd 242544 vbox 4u a_inode 0,14 0 10277 [eventpoll]
Minihttpd 242544 vbox 5w REG 253,0 464 1048929 2023-12-03.log
新建一个脚本，内容是ulimit -n 6;./Minihttpd（如果直接在shell里执行，会把当前shell的最大open files设为6），执行该脚本，另起一个终端执行nc 127.0.0.1 9999，就会发现脚本输出：
accept -1
errno is 24 (Too many open files)
但用ss -tp | grep 9999发现已经建立了连接：
ESTAB 0 0 127.0.0.1:9999 127.0.0.1:39320
ESTAB 0 0 127.0.0.1:39320 127.0.0.1:9999 users:(("nc",pid=249546,fd=3))
调用accept时，协议栈已经完成了握手建立了连接，accept只是创建一个文件描述符并和这个连接关联起来。
关掉nc再看：
CLOSE-WAIT 1 0 127.0.0.1:9999 127.0.0.1:39320
FIN-WAIT-2 0 0 127.0.0.1:39320 127.0.0.1:9999
nc进程退出时关闭了socket，发送了FIN并收到了ACK，等待对端发送FIN，所以处于FIN-WAIT-2状态。
Minihttpd进程没有文件描述符关联这个连接，所以没办法调用close，就不会发送FIN，所以会一直处于CLOSE-WAIT状态，直到进程退出。
过了一会，FIN-WAIT-2超时后就只剩下了CLOSE-WAIT了：
CLOSE-WAIT 1 0 127.0.0.1:9999 127.0.0.1:39320
实际上拿来测试的这个Minihttpd本身就有bug，对端主动关闭时，它不会调用close，所以慢慢会出现很多CLOSE-WAIT的连接。
延伸阅读：【tcp】关于 TCP FIN_WAIT2状态的一个细节问题
更进一步
accept因文件描述符不足失败（以下简称accept失败）后，连接难道就“资源泄露”了吗？其实不是，此时连接并没有从completely established sockets waiting to be accepted队列（以下简称为队列）中拿掉。如果accept失败后，释放了一些文件描述符，再次调用accept时就能取出之前取失败的连接了。
epoll分别在水平触发和边沿触发时情况有点不同：
水平触发时，accept失败后，如果不做额外处理，下次epoll_wait会立即触发读事件，accept继续失败……，然后会陷入死循环。这个比较难处理。
边沿触发时，accept失败后，又有新连接建立时，才会触发读事件。如果此时文件描述符足够，accept成功后只处理了1个连接，队列里还有别的连接没处理呢，所以应该循环调用accept，直到返回EAGAIN或EWOULDLOCK错误；如果此时文件描述符仍不足，队列中的连接会越来越多，队列满了之后就会拒绝新连接的建立，再之后就没机会触发读事件了（测试在后面），相当于死锁了。
测试：边沿触发，将listen的第2个参数设为0（测试发现队列大小实际是backlog+1），客户端发起两个连接，第2次的客户端请求，epoll_wait并不会返回，观察发现：
ESTAB 0 0 127.0.0.1:9999 127.0.0.1:36294
SYN-SENT 0 1 127.0.0.1:33070 127.0.0.1:9999 users:(("telnet",pid=6361,fd=3))
ESTAB 0 0 127.0.0.1:36294 127.0.0.1:9999 users:(("nc",pid=6150,fd=3))
第2个连接的握手都无法完成了，一定时间后telnet提示telnet: Unable to connect to remote host: Connection timed out。