我们首先需要知道select,poll,epoll都是IO多路复用的机制。I/O多路复用就通过一种机制,可以监视多个描述符,一旦某个描述符就绪(一般是读就绪或者写就绪),能够通知程序进行相应的读写操作。但select,poll,epoll本质上都是同步I/O,因为他们都需要在读写事件就绪后自己负责进行读写,也就是说这个读写过程是阻塞的。
select的基本用法:http://blog.csdn.net/nk_test/article/details/49256129
poll的基本用法:http://blog.csdn.net/nk_test/article/details/49283325
epoll的基本用法:http://blog.csdn.net/nk_test/article/details/49331717
接下来我们探讨如何正确使用non-blocking I/O Multiplexing + poll/epoll。
先来说几个常见的问题:
1.SIGPIPE信号的产生和处理
如果客户端使用close关闭套接字,而服务器端调用了一次write,服务器会接收一个RST segment(TCP传输层); 如果服务器再次调用write,这个时候就会产生SIGPIPE信号,如果不忽略,就会默认退出程序,显然是不满足服务器的高可用性。可以在程序中直接忽略掉,如 signal(SIGPIPE,
SIG_IGN)。
2.TIME_WAIT 状态对 服务器的影响
应尽可能避免在服务端出现TIME_WAIT状态。如果服务器主动断开连接(先于client调用close),服务端就会进入TIME_WAIT状态,内核会hold住一些资源,大大降低服务器的并发能力。解决方法:协议设计上,应该让客户端主动断开连接,这样就可以把TIME_WAIT状态分散到大量的客户端。如果客户端不活跃了,一些恶意的客户端不断开连接,这样就会占用服务器端的连接资源。所以服务端也要有机制来踢掉不活跃的连接。
3.新的accept4系统调用
多了flags参数,可以设置以下两个标志:
int accept4(int sockfd, struct sockaddr *addr, socklen_t *addrlen, int flags); SOCK_NONBLOCK Set the O_NONBLOCK file status flag on the new open file description. Using this flag saves extra calls to fcntl(2) to achieve the same result. SOCK_CLOEXEC Set the close-on-exec (FD_CLOEXEC) flag on the new file descriptor. See the description of the O_CLOEXEC flag in open(2) for reasons why this may be useful.
进程被替换时,文件描述符是关闭的状态,用来设置返回的已连接套接字,也可以使用fcntl设置,但是效率稍微低一些。
4.accept(2)返回EMFILE的处理(文件描述符已经用完)
(1)调高进程文件描述符数目
(2)死等
(3)退出程序
(4)关闭监听套接字。那什么时候重新打开呢?
(5)如果是epoll模型,可以改用edge trigger。问题是如果漏掉了一次accept(2),程序再也不会收到新连接(没有状态变化)
(6)准备一个空闲的文件描述符。遇到这种情况,先关闭这个空闲文件,获得一个文件描述符名额;再accept(2)拿到socket连接的文件描述符;随后立刻close(2),这样就优雅地断开了与客户端的连接;最后重新打开空闲文件,把“坑”填上,以备再次出现这种情况时使用。
int idlefd = open("/dev/null", O_RDONLY | O_CLOEXEC); connfd = accept4(listenfd, (struct sockaddr *)&peeraddr, &peerlen, SOCK_NONBLOCK | SOCK_CLOEXEC); /* if (connfd == -1) ERR_EXIT("accept4"); */ if (connfd == -1) { if (errno == EMFILE) { close(idlefd); idlefd = accept(listenfd, NULL, NULL); close(idlefd); idlefd = open("/dev/null", O_RDONLY | O_CLOEXEC); continue; } else ERR_EXIT("accept4"); }
(一)poll的处理流程和需要注意的问题
需要注意的问题及其处理方法:
(1) 粘包问题:read 可能一次并没有把connfd 所对应的接收缓冲区(内核)的数据都读完,那么connfd下次仍然是活跃的。我们应该将读到的数据保存在connfd的应用层缓冲区(char
buf[1024]),并处理好消息的边界。
(2)write应答的数据量较大的情况下,可能一次并不能把所有的数据发送到内核的缓冲区,所以应该有一个应用层的缓冲区,将未发送完的数据添加到应用层发送缓冲区。
(3)关注connfd 的POLLOUT 事件的时机。POLLOUT事件到来,则取出应用层发送缓冲区数据发送write,如果应用层发送缓冲区数据发送完毕,则取消关注POLLOUT事件。POLLOUT 事件触发条件:connfd的发送缓冲区(内核)不满(可以容纳数据)。
注:connfd 的接收缓冲区(内核)数据被接收后会被清空,当发出数据段后接收到对方的ACK段后,发送缓冲区(内核)数据段会被清空。write只是将应用层发送缓冲区数据拷贝到connfd 对应的内核发送缓冲区就返回;read 只是从connfd对应的内核接收缓冲区数据拷贝到应用层接收缓冲区就返回。
(二)epoll的处理流程和需要注意的问题
电平触发模式:
基本处理流程和poll十分相似。注意epoll_wait返回的都是活跃的,不用遍历,直接处理即可。write返回成功只是说明将数据拷贝至内核缓冲区。
EPOLLIN 事件
内核中的某个socket接收缓冲区 为空 低电平
内核中的某个socket接收缓冲区 不为空 高电平
EPOLLOUT 事件
内核中的某个socket发送缓冲区 不满 高电平
内核中的某个socket发送缓冲区 满 低电平
注:只要第一次write没写完整,则下次调用write直接把数据添加到应用层缓冲区OutBuffer,等待EPOLLOUT事件。
边沿触发模式:
缺点:
可能产生漏连接accept的bug,很难处理;
文件描述符达到上限后,一直处于高电平,不会再触发了。处理起来也比较麻烦。
推荐epoll使用LT模式的原因:
其中一个是与poll兼容;
LT(水平)模式不会发生漏掉事件的BUG,但POLLOUT事件不能一开始就关注,否则会出现busy loop(即暂时还没有数据需要写入,但一旦连接建立,内核发送缓冲区为空会一直触发POLLOUT事件),而应该在write无法完全写入内核缓冲区的时候才关注,将未写入内核缓冲区的数据添加到应用层output buffer,直到应用层output buffer写完,停止关注POLLOUT事件。
读写的时候不必等候EAGAIN,可以节省系统调用次数,降低延迟。(注:如果用ET模式,读的时候读到EAGAIN,写的时候直到output buffer写完或者写到EAGAIN)
注:在使用 ET 模式时,可以写得更严谨,即将 listenfd 设置为非阻塞,如果accpet 调用有返回,除了建立当前这个连接外,不能马上就回到 epoll_wait ,还需要继续循环accpet,直到返回-1 且errno == EAGAIN 才退出。代码示例如下:
if(ev.events & EPOLLIN) { do { struct sockaddr_in stSockAddr; socklen_t iSockAddrSize = sizeof(sockaddr_in); int iRetCode = accept(listenfd, (struct sockaddr *) &stSockAddr, iSockAddrSize); if (iRetCode > 0) { // ...建立连接 // 添加事件关注 } else { //直到发生EAGAIN才不继续accept if(errno == EAGAIN) { break; } } } while(true); // ... 其他 EPOLLIN 事件 }
(三)三者各方面的比较
select:fd_set有文件描述符个数的限制;另外每次都要复制到内核空间,扫描O(N)的复杂度。要遍历所有的文件描述符去判断是否发生了事件。
poll:也是拷贝和轮询。拷贝至内核中的链表,没有最大连接数的限制。
epoll:使用共享内存(mmap)减少复制开销,存放感兴趣的套接字,都是在内核态操作的,采用事件通知的回调机制。
注意:并不是在任何条件下epoll的效率都是最高的,要根据实际的应用情况来判断使用哪种I/O。
如果已连接套接字数目不太大并且这些套接字一直处于活跃的状态,那么不停地调用callback函数可能会造成低效率,也就是说低于一次性遍历,此时epoll的效率就可能低于select和poll。