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);
- ...
- }
