浅谈网络I/O多路复用模型 select & poll & epoll

我们首先需要知道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。

时间: 2024-11-20 19:30:01

浅谈网络I/O多路复用模型 select & poll & epoll的相关文章

I/O多路复用之select,poll,epoll简介

一.select 1.起源 select最早于1983年出现在4.2BSD中(BSD是早期的UNIX版本的分支). 它通过一个select()系统调用来监视多个文件描述符的数组,当select()返回后,该数组中就绪的文件描述符便会被内核修改标志位,使得进程可以获得这些文件描述符从而进行后续的读写操作. 2.select的优点 目前几乎在所有的平台上支持,具有良好的跨平台支持. 3.select的缺点 单个进程能够监视的文件描述符的数量存在最大限制.默认情况下,在Linux上单个进程能够打开的最

python网络编程——socket进阶篇(select/poll/epoll)

原 生socket客户端在与服务端建立连接时,即服务端调用accept方法时是阻塞的,同时服务端和客户端在收数据(调用recv)时也是阻塞的.原生 socket服务端在同一时刻只能处理一个客户端请求,即服务端不能同时与多个客户端进行通信,实现并发,导致服务端资源闲置(此时服务端只占据 I/O,CPU空闲). 现在的需求是:我们要让多个客户端连接至服务器端,而且服务器端需要处理来自多个客户端请求.很明显,原生socket实现不了这种需求,此时我们该采用什么方式来处理呢? 解决方法:采用I/O多路复

多路IO复用模型--select, poll, epoll

select 1.select能监听的文件描述符个数受限于FD_SETSIZE,一般为1024,单纯改变进程打开的文件描述符个数并不能改变select监听文件个数 2.解决1024以下客户端时使用select是很合适的,但如果链接客户端过多,select采用的是轮询模型,会大大降低服务器响应效率,不应在select上投入更多精力 int select(int nfds, fd_set *readfds, fd_set *writefds,fd_set *exceptfds, struct tim

几种典型的服务器网络编程模型归纳(select poll epoll)

1.同步阻塞迭代模型 同步阻塞迭代模型是最简单的一种IO模型. 其核心代码如下: bind(srvfd); listen(srvfd); for(;;) { clifd = accept(srvfd,...); //开始接受客户端来的连接 read(clifd,buf,...); //从客户端读取数据 dosomthingonbuf(buf); write(clifd,buf)//发送数据到客户端 } 上面的程序存在如下一些弊端: 1)如果没有客户端的连接请求,进程会阻塞在accept系统调用处

浅谈UML的概念和模型之UML九种图

文件夹: UML的视图 UML的九种图 UML中类间的关系 上文我们介绍了,UML的视图,在每一种视图中都包括一个或多种图.本文我们重点解说UML每种图的细节问题: 1.用例图(use case diagrams) [概念]描写叙述用户需求,从用户的角度描写叙述系统的功能 [描写叙述方式]椭圆表示某个用例:人形符号表示角色 [目的]帮组开发团队以一种可视化的方式理解系统的功能需求 [用例图] 2.静态图 类图(class  diagrams) [概念]显示系统的静态结构,表示不同的实体是怎样相关

Linux内核中网络数据包的接收-第二部分 select/poll/epoll

和前面文章的第一部分一样,这些文字是为了帮别人或者自己理清思路的,而不是所谓的源码分析,想分析源码的,还是直接debug源码最好,看任何文档以及书都是下策.因此这类帮人理清思路的文章尽可能的记成流水的方式,尽可能的简单明了. Linux 2.6+内核的wakeup callback机制 Linux 内核通过睡眠队列来组织所有等待某个事件的task,而wakeup机制则可以异步唤醒整个睡眠队列上的task,每一个睡眠队列上的节点都拥有一个 callback,wakeup逻辑在唤醒睡眠队列时,会遍历

I/O多路复用之select,poll,epoll的区别

一.关于select,poll,epoll 三种IO模型,都属于多路IO就绪通知,提供了对大量文件描述符就绪检查的高性能方案,只不过实现方式有所不同: select原理概述: 调用select时,会发生以下事情: (1)从用户空间拷贝fd_set到内核空间: (2)注册回调函数__pollwait: (3)遍历所有fd,对全部指定设备做一次poll(这里的poll是一个文件操作,它有两个参数,一个是文件fd本身,一个是当设备尚未就绪时调用的回调函数__pollwait,这个函数把设备自己特有的等

Linux I/O复用中select poll epoll模型的介绍及其优缺点的比较

关于I/O多路复用: I/O多路复用(又被称为"事件驱动"),首先要理解的是,操作系统为你提供了一个功能,当你的某个socket可读或者可写的时候,它可以给你一个通知.这样当配合非阻塞的socket使用时,只有当系统通知我哪个描述符可读了,我才去执行read操作,可以保证每次read都能读到有效数据而不做纯返回-1和EAGAIN的无用功.写操作类似.操作系统的这个功能通过select/poll/epoll之类的系统调用来实现,这些函数都可以同时监视多个描述符的读写就绪状况,这样,**多

Linux I/O复用中select poll epoll模型的介绍及其优缺点的比較

关于I/O多路复用: I/O多路复用(又被称为"事件驱动"),首先要理解的是.操作系统为你提供了一个功能.当你的某个socket可读或者可写的时候.它能够给你一个通知.这样当配合非堵塞的socket使用时,仅仅有当系统通知我哪个描写叙述符可读了,我才去运行read操作.能够保证每次read都能读到有效数据而不做纯返回-1和EAGAIN的无用功.写操作相似.操作系统的这个功能通过select/poll/epoll之类的系统调用来实现.这些函数都能够同一时候监视多个描写叙述符的读写就绪状况