Linux下的网络socket编程---------------多路复用（epoll）

1.epoll的诞生

1.1 select的缺点

1. 单个进程能够监视的文件描述符的数量存在最大限制，通常是1024，当然可以更改数量，但由于select采用轮询的方式扫 描文件描述符，文件描述符数量越多，性能越差；
2. 内核 / 用户空间内存拷贝问题，select需要复制大量的句柄数据结构，产生巨大的开销；
3. select返回的是含有整个句柄的数组，应用程序需要遍历整个数组才能发现哪些句柄发生了事件；
4. select的触发方式是水平触发，应用程序如果没有完成对一个已经就绪的文件描述符进行IO操作，那么之后每次select调 用还是会将这些文件描述符通知进程。

1.2 epoll出现

在linux 没有实现epoll事件驱动机制之前，我们一般选择用select或者poll等IO多路复用的方法来实现并发服务程序。自 Linux 2.6内核正式引入epoll以来，epoll已经成为了目前实现高性能网络服务器的必备技术，在大数据、高并发、集群等一些名 词唱得火热之年代，select和poll的用武之地越来越有限，风头已经被epoll占尽。
相比select模型，poll使用链表保存文件描述符，因此没有了监视文件数量的限制，但其他三个缺点依然存在。拿select模型 为例，假设我们的服务器需要支持100万的并发连接，则在__FD_SETSIZE 为1024的情况下，则我们至少需要开辟1k个进程才能 实现100万的并发连接。除了进程间上下文切换的时间消耗外，从内核/用户空间大量的无脑内存拷贝、数组轮询等，是系统难以 承受的。因此，基于select模型的服务器程序，要达到10万级别的并发访问，是一个很难完成的任务。
epoll是Linux内核为处理大批量文件描述符而作了改进的poll，是Linux下多路复用IO接口select/poll的增强版本，它能显著 提高程序在大量并发连接中只有少量活跃的情况下的系统CPU利用率。另一点原因就是获取事件的时候，它无须遍历整个被侦听 的描述符集，只要遍历那些被内核IO事件异步唤醒而加入Ready队列的描述符集合就行了。epoll除了提供select/poll那种IO事 件的水平触发（Level Triggered）外，还提供了边缘触发（Edge Triggered），这就使得用户空间程序有可能缓存IO状态，减 少epoll_wait/epoll_pwait的调用，提高应用程序效率。

LT（level triggered）是缺省的工作方式，并且同时支持block和no-block socket.在这种做法中，内核告诉你一个文件描述 符是否就绪了，然后你可以对这个就绪的fd进行IO操作。如果你不作任何操作，内核还是会继续通知你的，所以，这种模式编程 出错误可能性要小一点。传统的select/poll都是这种模型的代表。

ET （edge-triggered）是高速工作方式，只支持non-block socket。在这种模式下，当描述符从未就绪变为就绪时，内核通 过epoll告诉你。然后它会假设你知道文件描述符已经就绪，并且不会再为那个文件描述符发送更多的就绪通知，直到你做了某些 操作导致那个文件描述符不再为就绪状态了（比如，你在发送，接收或者接收请求，或者发送接收的数据少于一定量时导致了一 个EWOULDBLOCK 错误）。但是请注意，如果一直不对这个fd作IO操作（从而导致它再次变成未就绪），内核不会发送更多的 通知（only once），不过在TCP协议中，ET模式的加速效用仍需要更多的benchmark确认。

ET和LT的区别就在这里体现，LT事件不会丢弃，而是只要读buffer里面有数据可以让用户读，则不断的通知你。而ET则只在事 件发生之时通知。可以简单理解为LT是水平触发，而ET则为边缘触发。LT模式只要有事件未处理就会触发，而ET则只在高低电 平变换时（即状态从1到0或者0到1）触发。
由于epoll的实现机制与select/poll机制完全不同，上面所说的 select的缺点在epoll上不复存在。设想一下如下场景：有100 万个客户端同时与一个服务器进程保持着TCP连接。而每一时刻，通常只有几百上千个TCP连接是活跃的(事实上大部分场景都是 这种情况)。如何实现这样的高并发？在select/poll时代，服务器进程每次都把这100万个连接告诉操作系统(从用户态复制句柄 数据结构到内核态)，让操作系统内核去查询这些套接字上是否有事件发生，轮询完后，再将句柄数据复制到用户态，让服务器应 用程序轮询处理已发生的网络事件，这一过程资源消耗较大，因此，select/poll一般只能处理几千的并发连接。
epoll的设计和实现与select完全不同。epoll通过在Linux内核中申请一个简易的文件系统，把原先的select/poll调用分成了3 个部分：

1. 调用epoll_create()建立一个epoll对象(在epoll文件系统中为这个句柄对象分配资源)
2. 调用epoll_ctl向epoll对象中添加这100万个连接的套接字
3. 调用epoll_wait收集发生的事件的连接

如此一来，要实现上面说是的场景，只需要在进程启动时建立一个epoll对象，然后在需要的时候向这个epoll对象中添加或者 删除连接。同时，epoll_wait的效率也非常高，因为调用epoll_wait时，并没有一股脑的向操作系统复制这100万个连接的句柄数 据，内核也不需要去遍历全部的连接。

2.函数参数解析

创建epoll实例：epoll_create()
函数原型：

#include <sys/epoll.h> 
int epoll_create(int size);

系统调用epoll_create()创建了一个新的epoll实例，其对应的兴趣列表初始化为空。若成功返回文件描述符，若出错返回-1。 参数size指定了我们想要通过epoll实例来检查的文件描述符个数。该参数并不是一个上限，而是告诉内核应该如何为内部数据结 构划分初始大小。从Linux2.6.8版以来，size参数被忽略不用。
作为函数返回值，epoll_create()返回了代表新创建的epoll实例的文件描述符。这个文件描述符在其他几个epoll系统调用中用 来表示epoll实例。当这个文件描述符不再需要时，应该通过close（）来关闭。当所有与epoll实例相关的文件描述符都被关闭 时，实例被销毁，相关的资源都返还给系统。从2.6.27版内核以来，Linux支持了一个新的系统调用epoll_create1()。该系统调用 执行的任务同epoll_create()一样，但是去掉了无用的参数size，并增加了一个可用来修改系统调用行为的flags参数。目前只支 持一个flag标志：EPOLL_CLOEXEC，它使得内核在新的文件描述符上启动了执行即关闭标志。

修改epoll的兴趣列表：epoll_ctl()
函数原型：

#include <sys/epoll.h> 
int epoll_ctl(int epfd, int op, int fd, struct epoll_event *ev);

系统调用epoll_ctl()能够修改由文件描述符epfd所代表的epoll实例中的兴趣列表。若成功返回0，若出错返回-1。

第一个参数epfd是epoll_create()的返回值；
第二个参数op用来指定需要执行的操作，它可以是如下几种值：

• EPOLL_CTL_ADD：将描述符fd添加到epoll实例中的兴趣列表中去。对于fd上我们感兴趣的事件，都指定在ev所指向的 结构体中。如果我们试图向兴趣列表中添加一个已存在的文件描述符，epoll_ctl()将出现EEXIST错误；
• EPOLL_CTL_MOD：修改描述符上设定的事件，需要用到由ev所指向的结构体中的信息。如果我们试图修改不在兴趣列表 中的文件描述符，epoll_ctl()将出现ENOENT错误；
• EPOLL_CTL_DEL：将文件描述符fd从epfd的兴趣列表中移除，该操作忽略参数ev。如果我们试图移除一个不在epfd的兴 趣列表中的文件描述符，epoll_ctl()将出现ENOENT错误。关闭一个文件描述符会自动将其从所有的epoll实例的兴趣列表 移除；

第三个参数fd指明了要修改兴趣列表中的哪一个文件描述符的设定。该参数可以是代表管道、FIFO、套接字、POSIX消息队 列、inotify实例、终端、设备，甚至是另一个epoll实例的文件描述符。但是，这里fd不能作为普通文件或目录的文件描述符；

第四个参数ev是指向结构体epoll_event的指针，结构体的定义如下：

typedef union epoll_data 
{
       
      void        *ptr;    /* Pointer to user-defind data */    
      int        fd;    /* File descriptor */    
      uint32_t    u32;    /* 32-bit integer */    
      uint64_t    u64;    /* 64-bit integer */ 
}epoll_data_t;

struct epoll_event 
{
       
      uint32_t events; /* epoll events(bit mask) */    
      epoll_data_t data; /* User data */ 
};

参数ev为文件描述符fd所做的设置（epoll_event）如下：

• events字段是一个位掩码，它指定了我们为待检查的描述符fd上所感兴趣的事件集合；
• data字段是一个联合体，当描述符fd稍后称为就绪态时，联合的成员可用来指定传回给调用进程的信息；

事件等待：epoll_wait()
函数原型：

#include <sys/epoll.h> 
int epoll_wait(int epfd, struct epoll_event *evlist, int maxevents, int timeout);

系统调用epoll_wait()返回epoll实例中处于就绪态的文件描述符信息，单个epoll_wait()调用能够返回多个就绪态文件描述符的 信息。调用成功后epoll_wait()返回数组evlist中的元素个数，如果在timeout超时间隔内没有任何文件描述符处于就绪态的话就 返回0，出错时返回-1并在errno中设定错误码以表示错误原因。

第一个参数epfd是epoll_create()的返回值；
第二个参数evlist所指向的结构体数组中返回的是有关就绪态文件描述符的信息，数组evlist的空间由调用者负责申请；
第三个参数maxevents指定所evlist数组里包含的元素个数； 第四个参数timeout用来确定epoll_wait()的阻塞行为，有如下几种：

• 如果timeout等于-1，调用将一直阻塞，直到兴趣列表中的文件描述符上有事件产生或者直到捕获到一个信号为止。
• 如果timeout等于0，执行一次非阻塞式地检查，看兴趣列表中的描述符上产生了哪个事件。
• 如果timeout大于0，调用将阻塞至多timeout毫秒，直到文件描述符上有事件发生，或者直到捕获到一个信号为止。

数组evlist中，每个元素返回的都是单个就绪态文件描述符的信息。events字段返回了在该描述符上已经发生的事件掩码。 data字段返回的是我们在描述符上使用epoll_ctl()注册感兴趣的事件时在ev.data中所指定的值。注意，data字段是唯一可获知同 这个事件相关的文件描述符的途径。因此，当我们调用epoll_ctl()将文件描述符添加到感兴趣列表中时，应该要么将ev.date.fd设 为文件描述符号，要么将ev.date.ptr设为指向包含文件描述符号的结构体

当我们调用epoll_ctl()时可以在ev.events中指定的位掩码以及由epoll_wait()返回的evlist[].events中的值如下所示：

默认情况下，一旦通过epoll_ctl()的EPOLL_CTL_ADD操作将文件描述符添加到epoll实例的兴趣列表中后，它会保持激活状态 （即，之后对epoll_wait()的调用会在描述符处于就绪态时通知我们）直到我们显示地通过epoll_ctl()的EPOLL_CTL_DEL操作将 其从列表中移除。如果我们希望在某个特定的文件描述符上只得到一次通知，那么可以在传给epoll_ctl()的ev.events中指定 EPOLLONESHOT标志。如果指定了这个标志，那么在下一个epoll_wait()调用通知我们对应的文件描述符处于就绪态之后，这 个描述符就会在兴趣列表中被标记为非激活态，之后的epoll_wait()调用都不会再通知我们有关这个描述符的状态了。如果需 要，我们可以稍后用过调用epoll_ctl()的EPOLL_CTL_MOD操作重新激活对这个文件描述符的检查。

3.代码示例

下面是使用epoll()多路复用实现的服务器端示例代码：

  1 #include<stdio.h>
  2 #include<stdlib.h>
  3 #include<unistd.h>
  4 #include<string.h>
  5 #include<errno.h>
  6 #include<ctype.h>
  7 #include<time.h>
  8 #include<pthread.h>
  9 #include<getopt.h>
 10 #include<libgen.h>
 11 #include<sys/types.h>
 12 #include<sys/socket.h>
 13 #include<arpa/