linux-epoll研究 - Geek_Ma - 博客园

linux-epoll研究

做linux网络编程的同学都清楚，2.6版本以前的linux内核大多都是用select作为非阻塞的事件触发模型，但是效率低，使用受限已经很明显的暴露了select（包括poll）的缺陷了，为了解决这些缺陷，epoll作为linux新的事件触发模型被创造出来。

一、epoll相对于select的优点：

1.支持一个进程socket描述符(FD)的最大数目

select支持的单进程socket描述符最大数目只有几千，而epoll支持的数目很大，等于系统最大打开的文件描述符数，这个文件描述符数跟内存有一定关系

2.IO效率不随FD数目增加而线性下降

select对事件的扫描是针对于所有创建的socket描述符进行的，也就是说，有多少个socket描述符，就需要遍历多少个句柄，所以IO效率是随描述符增加线性下降的；而epoll只遍历活跃的socket描述符，这是因为在内核实现中epoll是根据每个fd上面的callback函数实现的。那么，只有"活跃"的socket才会主动的去调用 callback函数，其他idle状态socket则不会。比如一个高速LAN环境，epoll并不比select/poll有什么效率，相 反，如果过多使用epoll_ctl,效率相比还有稍微的下降。但是一旦使用idle connections模拟WAN环境,epoll的效率就远在select/poll之上了。

3.使用mmap加速内核与用户空间的消息传递

select事件触发后会将信息从内核拷贝到用户空间，这种拷贝就影响了效率。而mmap将内核与用户空间的内存映射到一块内存上，内核将消息捕获后放入该内存空间，用户无需拷贝直接可以访问，减少了拷贝次数，提高了效率。

二、epoll工作模型

epoll事件有两种模型：
Edge Triggered (ET)，边缘触发是高速工作方式，只支持no-block socket。在这种模式下，当描述符从未就绪变为就绪时，内核通过epoll告诉你。然后它会假设你知道文件描述符已经就绪，并且不会再为那个文件描述符发送更多的就绪通知，直到你做了某些操作导致那个文件描述符不再为就绪状态了(比如，你在发送，接收或者接收请求，或者发送接收的数据少于一定量时导致了一个EWOULDBLOCK错误）。但是请注意，如果一直不对这个fd作IO操作(从而导致它再次变成未就绪)，内核不会发送更多的通知(only once),不过在TCP协议中，ET模式的加速效用仍需要更多的benchmark确认。效率非常高，在并发，大流量的情况下，会比LT少很多epoll的系统调用，因此效率高。但是对编程要求高，需要细致的处理每个请求，否则容易发生丢失事件的情况。
Level Triggered (LT)，水平触发是缺省的工作方式，并且同时支持block和no-block socket.在这种做法中，内核告诉你一个文件描述符是否就绪了，然后你可以对这个就绪的fd进行IO操作。如果你不作任何操作，内核还是会继续通知你的，所以，这种模式编程出错误可能性要小一点。传统的select/poll都是这种模型的代表。效率会低于ET触发，尤其在大并发，大流量的情况下。但是LT对代码编写要求比较低，不容易出现问题。LT模式服务编写上的表现是：只要有数据没有被获取，内核就不断通知你，因此不用担心事件丢失的情况。

三、值得注意的情况:

1.当使用epoll的ET模型来工作时，当产生了一个EPOLLIN事件后，读数据的时候需要考虑的是当recv()返回的大小如果等于请求的大小，那么很有可能是缓冲区还有数据未读完，也意味着该次事件还没有处理完，所以还需要再次读取：

while(rs)
{buflen = recv(events[i].data.fd, buf, sizeof(buf), 0);if(buflen < 0){// 由于是非阻塞的模式,所以当errno为EAGAIN时,表示当前缓冲区已无数据可读// 在这里就当作是该次事件已处理处.if(errno == EAGAIN)break;elsereturn;}else if(buflen == 0){// 这里表示对端的socket已正常关闭.
    }if(buflen == sizeof(buf)rs = 1;   // 需要再次读取elsers = 0;
}

2.如果发送端流量大于接收端的流量，也就是说，epoll所在的程序读比转发的socket要慢，由于是非阻塞的socket，那么send()函数虽然返回，但实际缓冲区的数据并未真正发给接收端，这样不断的读和发，当缓冲区满后会产生EAGAIN错误(参考mansend)，同时，不理会这次请求发送的数据。所以，需要封装socket_send()的函数用来处理这种情况，该函数会尽量将数据写完再返回，返回-1表示出错。在socket_send()内部，当写缓冲已满(send()返回-1，且errno为EAGAIN)，那么会等待后再重试。这种方式并不很完美,在理论上可能会长时间的阻塞在socket_send()内部，但暂没有更好的办法。

ssize_t socket_send(int sockfd, const char* buffer, size_t buflen)
{ssize_t tmp;size_t total = buflen;const char *p = buffer;while(1){tmp = send(sockfd, p, total, 0);if(tmp < 0){// 当send收到信号时,可以继续写,但这里返回-1.if(errno == EINTR)return -1;// 当socket是非阻塞时,如返回此错误,表示写缓冲队列已满,// 在这里做延时后再重试.if(errno == EAGAIN){usleep(1000);continue;}return -1;}if((size_t)tmp == total)return buflen;total -= tmp;p += tmp;}return tmp;
}

四、实例

#include <iostream>
#include <sys/socket.h>
#include <sys/epoll.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <fcntl.h>
#include <unistd.h>
#include <stdio.h>
#include <errno.h>using namespace std;#define MAXLINE 5
#define OPEN_MAX 100
#define LISTENQ 20
#define SERV_PORT 5000
#define INFTIM 1000 //设置非阻塞
void setnonblocking(int sock)
{int opts;opts = fcntl(sock, F_GETFL);if(opts<0){perror("fcntl(sock,GETFL)");exit(1);}opts = opts|O_NONBLOCK;if(fcntl(sock,F_SETFL,opts)<0){perror("fcntl(sock,SETFL,opts)");exit(1);}
}int main()
{int i, maxi, listenfd,connfd, sockfd,epfd,nfds;ssize_t n;char line[MAXLINE];socklen_t clilen;//声明epoll_event结构体的变量,ev用于注册事件,数组用于回传要处理的事件struct epoll_event ev, events[20];//生成用于处理accept的epoll专用的文件描述符epfd = epoll_create(256);struct sockaddr_in clientaddr;struct sockaddr_in serveraddr;listenfd = socket(AF_INET, SOCK_STREAM, 0);//把socket设置为非阻塞方式//setnonblocking(listenfd);//设置与要处理的事件相关的文件描述符ev.data.fd = listenfd;//设置要处理的事件类型ETev.events = EPOLLIN|EPOLLET;//ev.events=EPOLLIN;//注册epoll事件epoll_ctl(epfd, EPOLL_CTL_ADD, listenfd, &ev);bzero(&serveraddr, sizeof(serveraddr));serveraddr.sin_family = AF_INET;char *local_addr="127.0.0.1";inet_aton(local_addr,&(serveraddr.sin_addr));//htons(SERV_PORT);serveraddr.sin_port=htons(SERV_PORT);bind(listenfd,(sockaddr *)&serveraddr, sizeof(serveraddr));listen(listenfd, LISTENQ);maxi = 0;for ( ; ; ) {//等待epoll事件的发生nfds = epoll_wait(epfd, events, 20, 500);//处理所发生的所有事件    for(i = 0; i < nfds;++i){if(events[i].data.fd == listenfd){connfd = accept(listenfd, (sockaddr *)&clientaddr, &clilen);if(connfd < 0){perror("connfd<0");exit(1);}//setnonblocking(connfd);char *str = inet_ntoa(clientaddr.sin_addr);cout << "accapt a connection from " << str << endl;//设置用于读操作的文件描述符ev.data.fd = connfd;//设置用于注测的读操作事件ev.events = EPOLLIN|EPOLLET;//ev.events=EPOLLIN;//注册evepoll_ctl(epfd, EPOLL_CTL_ADD, connfd, &ev);}else if(events[i].events&EPOLLIN){cout << "EPOLLIN" << endl;if ( (sockfd = events[i].data.fd) < 0)continue;if ( (n = read(sockfd, line, MAXLINE)) < 0){if (errno == ECONNRESET) {close(sockfd);events[i].data.fd = -1;} elsestd::cout<<"readline error"<<std::endl;} else if (n == 0) {close(sockfd);events[i].data.fd = -1;}line[n] = '\0';cout << "read " << line << endl;//设置用于写操作的文件描述符ev.data.fd = sockfd;//设置用于注册的写操作事件ev.events = EPOLLOUT|EPOLLET;//修改sockfd上要处理的事件为EPOLLOUT//epoll_ctl(epfd, EPOLL_CTL_MOD, sockfd, &ev);
            }else if(events[i].events&EPOLLOUT){  sockfd = events[i].data.fd;write(sockfd, line, n);//设置用于读操作的文件描述符ev.data.fd = sockfd;//设置用于注测的读操作事件ev.events = EPOLLIN|EPOLLET;//修改sockfd上要处理的事件为EPOLINepoll_ctl(epfd, EPOLL_CTL_MOD, sockfd, &ev);}}}return 0;
}

上面的代码是ET模式

测试脚本1：

#!/usr/bin/python
import socket
import timesock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
sock.connect(('127.0.0.1', 5000))sock.send('1234567890')
time.sleep(5)while(1):time.sleep(1)

输出1：

accapt a connection from 0.0.0.0
EPOLLIN
read 12345

说明1：

运行server和client发现，server仅仅读取了5字节的数据，而client其实发送了10字节的数据，也就是说，server仅当第一次监听到了EPOLLIN事件，由于没有读取完数据，而且采用的是ET模式，状态在此之后不发生变化，因此server再也接收不到EPOLLIN事件了。当关闭客户端时，会另外触发一个事件，这个事件又触发了一次读操作，也就将后面的5个字节读取出来。

测试脚本2：

#!/usr/bin/python
import socket
import timesock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
sock.connect(('127.0.0.1', 5000))sock.send('1234567890')
time.sleep(5)
sock.send('1234567890')while(1):time.sleep(1)

输出2：

accapt a connection from 0.0.0.0
EPOLLIN
read 12345
(5 sec...)
EPOLLIN
read 67890

说明2：

可以发现，在server接收完5字节的数据之后一直监听不到client的事件，而当client休眠5秒之后重新发送数据，server再次监听到了变化，只不过因为只是读取了5个字节，仍然有10个字节的数据(client第二次发送的数据)没有接收完。

如果上面的实验中，对accept的socket都采用的是LT模式，那么只要还有数据留在buffer中，server就会继续得到通知，可以将上面标黄的选项去掉则变为LT模式。

五、总结

ET模式仅当状态发生变化的时候才获得通知，这里所谓的状态的变化并不包括缓冲区中还有未处理的数据，也就是说，如果要采用ET模式，需要一直read/write直到出错为止，很多人反映为什么采用ET模式只接收了一部分数据就再也得不到通知了，大多是这个原因造成的；而LT模式是只要有数据没有处理就会一直通知下去的。

补充说明一下这里一直强调的"状态变化"是什么:

1)对于监听可读事件时，如果是socket是监听socket，那么当有新的主动连接到来为状态发生变化；对一般的socket而言，协议栈中相应的缓冲区有新的数据为状态发生变化。但是，如果在一个时间同时接收了N个连接(N>1)，但是监听socket只accept了一个连接，那么其它未 accept的连接将不会在ET模式下给监听socket发出通知，此时状态不发生变化；对于一般的socket，就如例子中而言，如果对应的缓冲区本身已经有了N字节的数据，而只取出了小于N字节的数据，那么残存的数据不会造成状态发生变化。

2)对于监听可写事件时，同理可推，不再详述。

不论是监听可读还是可写，对方关闭socket连接都将造成状态发生变化，比如在例子中，如果强行中断client脚本，也就是主动中断了socket连接，那么都将造成server端发生状态的变化，从而server得到通知，将已经在本方缓冲区中的数据读出。

把前面的描述可以总结如下：仅当对方的动作(发出数据,关闭连接等)造成的事件才能导致状态发生变化，而本方协议栈中已经处理的事件(包括接收了对方的数据，接收了对方的主动连接请求)并不是造成状态发生变化的必要条件，状态变化一定是对方造成的。所以在ET模式下的，必须一直处理到出错或者完全处理完毕，才能进行下一个动作，否则可能会发生错误。

部分转自他处-没有找到最终来源