我对网络IO的理解

Unix/Linux系统下IO主要分为磁盘IO，网络IO，我今天主要说一下对网络IO的理解，网络IO主要是socket套接字的读(read)、写(write)，socket在Linux系统被抽象为流(stream)。

网络IO模型

在Unix/Linux系统下，IO分为两个不同阶段：

• 等待数据准备好
• 从内核向进程复制数据

阻塞式I/O

阻塞式I/O(blocking I/O)是最简单的一种，默认情况下，socket 套接字的系统调用都是阻塞的，我以recv/recvfrom 理解一下网络IO的模型。当应用层的系统调用recv/recvfrom时，开启Linux的系统调用，开始准备数据，然后将数据从内核态复制到用户态，然后通知应用程序获取数据，整个过程都是阻塞的。两个阶段都会被阻塞。

阻塞I/O模型

图片来源于《Unix网络编程卷1》

阻塞I/O下开发的后台服务，一般都是通过多进程或者线程取出来请求，但是开辟进程或者线程是非常消耗系统资源的，当大量请求时，因为需要开辟更多的进程或者线程有可能将系统资源耗尽，因此这种模式不适合高并发的系统。

非阻塞式I/O

非阻塞IO(non-blocking I/O)在调用后，内核马上返回给进程，如果数据没有准备好，就返回一个error ，进程可以先去干其他事情，一会再次调用，直到数据准备好为止，循环往返的系统调用的过程称为轮询(pool)，然后在从内核态将数据拷贝到用户态，但是这个拷贝的过程还是阻塞的。

我还是以recv/recvfrom为例说一下，首选需要将socket套接字设置成为非阻塞，进程开始调用recv/recvfrom，如果内核没有准备好数据时，立即返回给进程一个error码（在Linux下是EAGINE的错误码），进程接到error返回后，先去干其他的事情，进入了轮询，只等到数据准备好，然后将数据拷贝到用户态。

需要通过ioctl 函数将socket套接字设置成为非阻塞

ioctl(fd, FIONBIO, &nb);

非阻塞I/O模型

图片来源于《Unix网络编程卷1》

非阻塞I/O的第一阶段不会阻塞，但是第二个阶段将数据从内核态拷贝到用户态时会有阻塞。在开发后台服务，由于非阻塞I/O需要通过轮询的方式去知道是否数据准备好，轮询的方式特别耗CPU的资源。

I/O多路复用

在Linux下提供一种I/O多路复用(I/O multiplexing)的机制，这个机制允许同时监听多个socket套接字描述符fd，一旦某个fd就绪(就绪一般是有数据可读或者可写)时，能够通知进程进行相应的读写操作。

在Linux下有三个I/O多路复用的函数Select、Poll、Epoll，但是它们都是同步IO，因为它们都需要在数据准备好后，读写数据是阻塞的。

I/O多路复用模型

图片来源于《Unix网络编程卷1》

I/O多路复用是Linux处理高并发的技术，Epoll比Select、Poll性能更优越，后面会讲到它们的区别。优秀的高并发服务例如Nginx、Redis都是采用Epoll+Non-Blocking I/O的模式。

信号驱动式I/O

信号驱动式I/O是通过信号的方式通知数据准备好，然后再讲数据拷贝到应用层，拷贝阶段也是阻塞的。

信号驱动式I/O

图片来源于《Unix网络编程卷1》

异步I/O

异步I/O(asynchronous I/O或者AIO)，数据准备通知和数据拷贝两个阶段都在内核态完成，两个阶段都不会阻塞，真正的异步I/O。

进程调用read/readfrom时，内核立刻返回，进程不会阻塞，进程可以去干其他的事情，当内核通知进程数据已经完成后，进程直接可以处理数据，不需要再拷贝数据，因为内核已经将数据从内核态拷贝到用户态，进程可以直接处理数据。

异步I/O模型

图片来源于《Unix网络编程卷1》

Linux对AIO支持不好，因此使用的不是太广泛。

同步和异步区别、阻塞和非阻塞的区别

同步和异步区别

对于这两个东西，POSIX其实是有官方定义的。A synchronous I/O operation causes the requesting process to be blocked until that I/O operation completes;An asynchronous I/O operation does not cause the requesting process to be blocked;

一个同步I/O操作会引起请求进程阻塞，只到这个I/O请求结束。

一个异步I/O操作不会引起请求进程阻塞。

从这个官方定义中，不管是Blocking I/O还是Non-Blocking I/O，其实都是synchronous I/O。因为它们一定都会阻塞在第二阶段拷贝数据那里。只有异步IO才是异步的。

同步异步对比

图片来源于知乎

阻塞和非阻塞的区别

阻塞和非阻塞主要区别其实是在第一阶段等待数据的时候。但是在第二阶段，阻塞和非阻塞其实是没有区别的。程序必须等待内核把收到的数据复制到进程缓冲区来。换句话说，非阻塞也不是真的一点都不”阻塞”，只是在不能立刻得到结果的时候不会傻乎乎地等在那里而已。

IO多路复用

Select、Poll、Epoll的区别

Select、poll、epoll都是I/O多路复用的机制，I/O多路复用就是通过一种机制，一个进程可以监视多个文件描述符fd，一旦某个描述符就绪（一般是读就绪或者写就绪），能够通知程序进行相应的读写操作。但select，poll，epoll本质上都是同步I/O，因为他们都需要在读写事件就绪后自己负责进行读写，也就是说这个读写过程是阻塞的，而异步I/O则无需自己负责进行读写，异步I/O的实现会负责把数据从内核拷贝到用户空间。

select

int select (int n, fd_set *readfds, fd_set *writefds, fd_set *exceptfds, struct timeval *timeout);

select 函数监视的文件描述符分3类，分别是writefds、readfds、和exceptfds。调用后select函数会阻塞，直到有描述符就绪（有数据 可读、可写、或者有except），或者超时（timeout指定等待时间，如果立即返回设为null即可），函数返回。当select函数返回后，可以 通过遍历fdset，来找到就绪的描述符。

select支持几乎所有的平台，跨平台是它的优点。

select缺点是：1）单个进程支持监控的文件描述符数量有限，Linux下一般是1024，可以修改提升限制，但是会造成效率低下。2）select通过轮询方式通知消息，效率比较低。

poll

int poll (struct pollfd *fds, unsigned int nfds, int timeout);

不同于select使用三个位图来表示三个fdset的方式，poll使用一个pollfd的指针实现。

struct pollfd {
 int fd; /* file descriptor */
 short events; /* requested events to watch */
 short revents; /* returned events witnessed */
};

pollfd结构包含了要监视的event和发生的event，不再使用select“参数-值”传递的方式。同时，pollfd并没有最大数量限制（但是数量过大后性能也是会下降）。和select函数一样，poll返回后，需要轮询pollfd来获取就绪的描述符。

从上面看，select和poll都需要在返回后，通过遍历文件描述符来获取已经就绪的socket。事实上，同时连接的大量客户端在一时刻可能只有很少的处于就绪状态，因此随着监视的描述符数量的增长，其效率也会线性下降。

epoll

epoll是在2.6内核中提出的，是之前的select和poll的增强版本，是Linux特有的。相对于select和poll来说，epoll更加灵活，没有描述符限制。epoll使用一个文件描述符管理多个描述符，将用户关系的文件描述符的事件存放到内核的一个事件表中，这样在用户空间和内核空间的copy只需一次。

int epoll_create(int size)；//创建一个epoll的句柄，size用来告诉内核这个监听的数目一共有多大
int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event)；
int epoll_wait(int epfd, struct epoll_event * events, int maxevents, int timeout);

执行epoll_create时，创建了红黑树和就绪list链表；执行epoll_ctl时，如果增加fd，则检查在红黑树中是否存在，存在则立即返回，不存在则添加到红黑树中，然后向内核注册回调函数，用于当中断事件到来时向准备就绪的list链表中插入数据。执行epoll_wait时立即返回准备就绪链表里的数据即可。

工作模式

1. LT模式

LT(level triggered)是缺省的工作方式，并且同时支持block和no-block socket，在这种做法中，内核告诉你一个文件描述符是否就绪了，然后你可以对这个就绪的fd进行IO操作。如果你不做任何操作，内核还是会继续通知你的。

2. ET模式

ET(edge-triggered)是高速工作方式，只支持no-block socket。在这种模式下，当描述符从未就绪变为就绪时，内核通过epoll告诉你。然后它会假设你知道文件描述符已经就绪，并且不会再为那个文件描述符发送更多的就绪通知，直到你做了某些操作导致那个文件描述符不再为就绪状态了(比如，你在发送，接收或者接收请求，或者发送接收的数据少于一定量时导致了一个EWOULDBLOCK/EAGAIN 错误）。但是请注意，如果一直不对这个fd作IO操作(从而导致它再次变成未就绪)，内核不会发送更多的通知(only once)，因此必须把缓存区buff数据读取完毕，不然就可能会丢数据。

ET模式在很大程度上减少了epoll事件被重复触发的次数，因此效率要比LT模式高。epoll工作在ET模式的时候，必须使用非阻塞套接口，以避免由于一个文件句柄的阻塞读/阻塞写操作把处理多个文件描述符的任务饿死。

详细对比

三种I/O多路复用对比

Nginx中Epoll+非阻塞IO

Nginx高并发主要是通过Epoll模式+非阻塞I/O

Nginx对I/O多路复用进行封装，封装在结构体struct ngx_event_s，同时将事件封装在ngx_event_actions_t结构中。

typedef struct {
 ngx_int_t (*add)(ngx_event_t *ev, ngx_int_t event, ngx_uint_t flags);
 ngx_int_t (*del)(ngx_event_t *ev, ngx_int_t event, ngx_uint_t flags);

 ngx_int_t (*enable)(ngx_event_t *ev, ngx_int_t event, ngx_uint_t flags);
 ngx_int_t (*disable)(ngx_event_t *ev, ngx_int_t event, ngx_uint_t flags);

 ngx_int_t (*add_conn)(ngx_connection_t *c);
 ngx_int_t (*del_conn)(ngx_connection_t *c, ngx_uint_t flags);

 ngx_int_t (*notify)(ngx_event_handler_pt handler);

 ngx_int_t (*process_events)(ngx_cycle_t *cycle, ngx_msec_t timer,
 ngx_uint_t flags);

 ngx_int_t (*init)(ngx_cycle_t *cycle, ngx_msec_t timer);
 void (*done)(ngx_cycle_t *cycle);
} ngx_event_actions_t;

初始化epoll句柄

static ngx_int_t
ngx_epoll_init(ngx_cycle_t *cycle, ngx_msec_t timer)
{
 ngx_epoll_conf_t *epcf;

 epcf = ngx_event_get_conf(cycle->conf_ctx, ngx_epoll_module);

 if (ep == -1) {
 ep = epoll_create(cycle->connection_n / 2);

 if (ep == -1) {
 ngx_log_error(NGX_LOG_EMERG, cycle->log, ngx_errno,
 "epoll_create() failed");
 return NGX_ERROR;
 }
 ...
 }
}

将fd设置为非阻塞

(ngx_nonblocking(s) == -1) #nginx将fd设置非阻塞

设置事件触发

static ngx_int_t
ngx_epoll_add_event(ngx_event_t *ev, ngx_int_t event, ngx_uint_t flags)
{
 int op;
 uint32_t events, prev;
 ngx_event_t *e;
 ngx_connection_t *c;
 struct epoll_event ee;

 c = ev->data;

 events = (uint32_t) event;

 if (event == NGX_READ_EVENT) {
 e = c->write;
 prev = EPOLLOUT;
#if (NGX_READ_EVENT != EPOLLIN|EPOLLRDHUP)
 events = EPOLLIN|EPOLLRDHUP;
#endif

 } else {
 e = c->read;
 prev = EPOLLIN|EPOLLRDHUP;
#if (NGX_WRITE_EVENT != EPOLLOUT)
 events = EPOLLOUT;
#endif
 }

 if (e->active) {
 op = EPOLL_CTL_MOD;
 events |= prev;

 } else {
 op = EPOLL_CTL_ADD;
 }

#if (NGX_HAVE_EPOLLEXCLUSIVE && NGX_HAVE_EPOLLRDHUP)
 if (flags & NGX_EXCLUSIVE_EVENT) {
 events &= ~EPOLLRDHUP;
 }
#endif

 ee.events = events | (uint32_t) flags;
 ee.data.ptr = (void *) ((uintptr_t) c | ev->instance);

 ngx_log_debug3(NGX_LOG_DEBUG_EVENT, ev->log, 0,
 "epoll add event: fd:%d op:%d ev:%08XD",
 c->fd, op, ee.events);

 if (epoll_ctl(ep, op, c->fd, &ee) == -1) {
 ngx_log_error(NGX_LOG_ALERT, ev->log, ngx_errno,
 "epoll_ctl(%d, %d) failed", op, c->fd);
 return NGX_ERROR;
 }

 ev->active = 1;
#if 0
 ev->oneshot = (flags & NGX_ONESHOT_EVENT) ? 1 : 0;
#endif

 return NGX_OK;
}

处理就绪的事件

static ngx_int_t
ngx_epoll_process_events(ngx_cycle_t *cycle, ngx_msec_t timer, ngx_uint_t flags)
{
 int events;
 uint32_t revents;
 ngx_int_t instance, i;
 ngx_uint_t level;
 ngx_err_t err;
 ngx_event_t *rev, *wev;
 ngx_queue_t *queue;
 ngx_connection_t *c;

 /* NGX_TIMER_INFINITE == INFTIM */

 ngx_log_debug1(NGX_LOG_DEBUG_EVENT, cycle->log, 0,
 "epoll timer: %M", timer);

 events = epoll_wait(ep, event_list, (int) nevents, timer);
 ...
}