由一个EPOLLET模式accept()问题引起对TCP连接的回顾

  • 问题起因

在生产环境出现一个TCP网络连接的异常,socket accept()时返回错误,错误码errno=24,strerror=”Too many open files”,线程占用CPU接近100%,即死循环。查明直接原因是,进程的open files数量太小,当连接数超时该数目时即会返回上述错误。(这要提醒一句:要注意父子进程的limits参数,也许系统配置参数已修改,但父进程是在修改前启动的,再去fork子进程时,子进程的limits参数也许就不如本意。通过cat /proc//limits 查看进程的limits参数。)

上述问题提供给用户连接服务的是子进程,而其父进程的open files却是1024,即便系统设置了open files为1,000,000,也阻止不了其共享父进程的参数,所以触发了上述的问题。为修复该问题,当然第一步要重启父进程,让其参数与系统配置的一致,再让其fork子进程。

然而还要问,为何进程占用CPU会接近100%?这就是底层网络实现涉及的问题。熟知IO多路复用模型epoll的人知道,其有两种触发模式,水平触发(EPOLLLT)和边缘触发(EPOLLET),默认为EPOLLLT模式。水平触发模式相对容易操作,只要内核socket读写缓冲区仍有数据就会触发epoll。对边缘触发模式,man手册推荐的正确用法:

(i) with non-blocking file descriptors; and

(ii) by waiting for an event only after read(2) or write(2) return EAGAIN.

非阻塞socket一直读/写,直到返回错误码EAGAIN(linux下EWOULDBOCK 宏定义为 EAGAIN)。

正是由于生产环境底层网络实现中利用了epoll的EPOLLET模式,而返回的错误码并非EAGAIN,所以导致线程一直没有退出循环。如此可能就导致了整个网络读写瘫痪,无法正常服务了。如何避免在出现open files达到上限后就不能读写的困境呢?接下来就去回顾下TCP连接的基础。

  • TCP连接的三次握手、四次挥手的回顾及理解

由一个EPOLLET模式accept()问题引起对TCP连接的回顾_第1张图片由一个EPOLLET模式accept()问题引起对TCP连接的回顾_第2张图片

       图1是大家熟知的TCP连接的状态图。图2是TCP连接三次握手状态图与应用层的关系。从图2可见,在应用层调用accept()函数前,在内核TCP连接可以正常握手成功,被放入一个accept队列内。这涉及到一个参数backlog,listen(int sockfd, int backlog),linux 内核2.2版本之后,backlog的设置只与accept queue的大小有关。syns queue = /proc/sys/net/ipv4/tcp_max_syn_backlog。accept queue = min(backlog, /proc/sys/net/core/comaxconn)。可通过ss -l命令查看监听端口的SendQ、RecvQ。

当accept队列满了之后,内核会怎么处理呢?通过命令查看cat /proc/sys/net/ipv4/tcp_abort_on_overflow。 如果是1,则内核将直接忽略最后一个ACK,而给对端发reset,关闭该连接;如果是0,内核会忽略最后一个ACK,而启动SYN+ACK定时重传机制,此时的状态仍是SYN_RECV,由/proc/sys/net/ipv4/tcp_synack_retries指定重传次数,在重传次数满之前accept queue出现空位时,内核会处理最后一次ACK将连接放进accept队列。

回到生产环境的那个问题,EPOLLET模式下,accept queue相当于accpet()的读缓冲区,一个epoll触发事件accept()函数会一直循环读取accept queue里的连接数据,所以accept queue一般情况并不会出现满的情况。而当达到进程的open files上限后,accept()函数将一直处于循环之中,后续的连接必将慢慢填满accept queue,而一旦队列满了,EPOLLET模式还能被触发accept()吗?!这时会提一个问题,如果旧的连接断开后文件描述符被释放,accept()就能成功,将accept queue的连接数据读取出来了?接下来看TCP断连的四次挥手。

TCP/IP详解(卷1)有说明,发送FIN通常是应用层进行关闭的结果。也就是说,旧的连接断开对端发送了FIN包,本地应用层去读取后才能回应FIN包,这样才能释放旧的fd,否则一直处于CLOSE_WAIT状态。如果有空闲线程去读取回应FIN包,释放旧的fd,accept死循环将被终结,服务可短时间恢复连接。所以无论单线程还是多线程,如果所有线程都出现errno=24导致accept()死循环的情况,基本服务不可恢复了,所有读写都会被阻塞住了。

 

  • 尝试解决方案

刚开始简单地想尝试对调用accept()固定在最多循环有限次就退出,这样就不会死循环而可以释放断开连接发来的FIN包,但这样就违背了man手册推荐的用法,读到返回EAGAIN为止。同时也会产生另外一个问题,设有限次数为10,假如并发达到20次,一次循环只能accept 10个连接,剩下的10次连接将一直放在accept queue内直到有新的连接请求触发epoll,这样就可能会导致有些连接长时间没有被accept,当然在客户端本地会设定超时重连。其实,这对生产环境的那个问题,也不完全能解决。假若达到open files上限,即便在循环有限次后能退出去处理其他epoll事件,但若没有旧连接断开,每次accept事件仍将返回错误,最后也会使accept queue填满,这时一旦退出accept的循环,将再也不可能触发accept了,即便能读取回应FIN包,释放fd数量。

其他方案?!暂时没想到。可能用EPOLLLT模式会更直接方便,不用一直循环,由缓冲区数据去驱动循环事件,这样是不是就可以处理accept/read/write事件了呢,而不至于由于accept死循环影响了read/write的事件驱动。

(注:文中图片来自网络其他文章,具体路径已无法查明,特说明表致意。)

你可能感兴趣的:(网络编程,epoll,tcp,网络编程)