Linux下套接字详解（三）----几种套接字I/O模型

原文链接：https://kernel.blog.csdn.net/article/details/46334337

参考：
网络编程–IO模型示例

几种服务器端IO模型的简单介绍及实现

背景知识

---

阻塞和非阻塞

---

对于一个套接字的 I/O通信，它会涉及到两个系统对象，一个是调用这个IO的进程或者线程，另一个就是系统内核。比如当一个读操作发生时，它会经历两个阶段：
①等待数据准备 (Waiting for the data to be ready)
②将数据从内核拷贝到进程中 (Copying the data from the kernel to the process)

阻塞，在linux中，默认情况下所有的socket都是blocking，当用户进程调用了recvfrom/recv这个系统调用，啮合就开始了IO的第一个阶段：准备数据。但是很多时候数据在一开始还没有到达（比如，还没有收到一个完整的UDP/TCP包），这个时候内核就要等待足够的数据到来。而在用户进程这边，整个进程会被阻塞。当内核一直等到数据准备好了，它就会将数据从内核中拷贝到用户内存，然后直到返回结果，用户进程才解除阻塞的状态，重新运行起来。

所以，阻塞IO的特点就是在IO执行的两个阶段都被阻塞了。
调用阻塞IO会一直阻塞对应的进程直到操作完成，而非阻塞IO在内核还准备数据的情况下会立刻返回。

阻塞

因此我们给出阻塞的简单定义，阻塞调用是指调用结果返回之前，当前线程会被挂起（线程进入非可执行状态，在这个状态下，cpu不会给线程分配时间片，即线程暂停运行）。函数只有在得到结果之后才会返回。

有人也许会把阻塞调用和同步调用等同起来，实际上他是不同的。对于同步调用来说，很多时候当前线程还是激活的，只是从逻辑上当前函数没有返回而已。 例如，我们在socket中调用recv函数，如果缓冲区中没有数据，这个函数就会一直等待，直到有数据才返回。而此时，当前线程还会继续处理各种各样的消息，所以我们应该说我们的线程现在是阻塞的。

快递的例子：比如到你某个时候到A楼一层（假如是内核缓冲区）取快递，但是你不知道快递什么时候过来，你又不能干别的事，只能死等着。但你可以睡觉（进程处于休眠状态），因为你知道快递把货送来时一定会给你打个电话（假定一定能叫醒你）。

非阻塞

非阻塞和阻塞的概念相对应，指在不能立刻得到结果之前，该函数不会阻塞当前线程，而会立刻返回。
还是等快递的例子：如果用忙轮询的方法，每隔5分钟到A楼一层(内核缓冲区）去看快递来了没有。如果没来，立即返回。而快递来了，就放在A楼一层，等你去取。

对象的阻塞模式和阻塞函数调用
对象是否处于阻塞模式和函数是不是阻塞调用有很强的相关性，但是并不是一一对应的。阻塞对象上可以有非阻塞的调用方式，我们可以通过一定的API去轮询状 态，在适当的时候调用阻塞函数，就可以避免阻塞。而对于非阻塞对象，调用特殊的函数也可以进入阻塞调用。我们经常使用的函数select就是这样的一个例子。

同步与异步

---

首先我们给出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; 

同步

用我们的话说，所谓同步，就是在发出一个功能调用时，在没有得到结果之前，该调用就不返回。也就是必须一件一件事做,等前一件做完了才能做下一件事，而只有当所有的工作按照顺序执行完之后，才会返回调用的位置，继续往下执行。
这个很好理解，我们一般做的函数调用，都是同步的，我们的程序按照我们既定的顺序一步一步执行，在前一个操作返回后，我们根据操作的结果，进行下一个阶段的处理，这就是一个同步的过程。

异步

异步，异步的概念和同步相对。当一个异步过程调用发出后，调用者不能立刻得到结果。实际处理这个调用的部件在完成后，通过状态、通知和回调来通知调用者。
简单来说
一个同步接收的方式，在这个端口下如果同是来了两个客户端请求，第一个连接得到响应，与服务端建立通讯，而第二个请求就会被一直阻塞直到第一个请求完成操作，各个请求之间就好像排个队，顺序执行，这就是同步。

而一个异步接收方式，就是同时来两个或者多个请求，服务端就同时响应多个客户端，同时给他们连接。各个客户端与服务器的通讯是并行的，一个客户端不必等另一个客户端完成操作。

两者的区别就在于同步IO做IO操作的时候会将process阻塞

其实阻塞IO，非阻塞IO，以及我们后面会提到IO复用都属于同步 IO。有人可能会说，非阻塞IO并没有被阻塞啊。这里有个非常“狡猾”的地方，定义中所指的”IO operation”是指真实的IO操作，比如非阻塞IO在执行recvfrom这个系统调用的时候，如果内核的数据没有准备好，这时候不会阻塞进程。但是，当内核中数据准备好的时候，recvfrom会将数据从内核拷贝到用户内存中，在这段时间内，进程是被阻塞的。而异步IO则不一样，当进程发起IO 操作之后，就直接返回再也不理睬了，直到内核发送一个信号，告诉进程说IO完成。在这整个过程中，进程完全没有被阻塞。

我们可以总结为一下几点
同步 就是我调用一个功能，该功能没有结束前，我死等结果。只能顺序执行。
异步 就是我调用一个功能，不需要知道该功能结果，该功能有结果后通知我（回调通知），往往用回调函数或者其他类方式实现。
阻塞 就是调用我（函数），我（函数）没有接收完数据或者没有得到结果之前，我不会返回。
非阻塞 就是调用我（函数），我（函数）立即返回，而当我准备完毕时，通过select通知调用者。

同步IO和异步IO的区别就在于：数据拷贝的时候进程是否可以被阻塞
阻塞IO和非阻塞IO的区别就在于：应用程序的调用是否能立即返回

并发与迭代

---

套接字编程经常使用在客户/服务器编程模型（简称C/S模型）中，C/S模型根据复杂度分为简单的客户/服务器模型和复杂的客户/服务器模型。
C/S简单客户/服务器模型是一对一关系，一个服务器端某一时间段内只对应处理一个客户端的请求，迭代服务器模型属于此模型。

C/S复杂服务器模型是一对多关系，一个服务器端某一时间段内对应处理多个客户端的请求，并发服务器模型属于此模型。

迭代服务器模型和并发服务器模型是socket编程中最常见使用的两种编程模型。

通常来说大多数TCP服务器是并发的，大多数UDP服务器是迭代的
比如我们通常在做聊天室的时候，使用UDP协议来发送消息，但是在用户需要上传下载数据的时候，我们通常在服务器和客户端之间建立一个TCP连接来传送文件。。。
但是如果服务一个客户请求的时间不长，使用迭代服务器没有太大问题，一旦客户请求的时间需要花费很长，不希望整个服务器被单个客户长期占用，而希望同时服务多个客户，就需要选择并发服务器了。

迭代服务器逻辑

创建套接字listenfd = socket( ... );
命名套接字bind(listenfd, ... );
开始监听客户端的连接listen(listenfd, LISTEN_QUENE);
while( 1 )   /*  循环处理每个客户端的处理请求  */
{
    connfd = 服务器accept客户端的连接accept(listenfd, ***)
    逻辑处理DealLogic(connfd);
    在这个connfd上给客户端发送消息SEND/RECV
    关闭close(connfd)
}

这个进程是一个一个处理各个客户端发来的连接的，比如一个客户端发来一个连接，那么只要它还没有完成自己的任务，那么它就一直会占用服务器的进程直到处理完毕后服务器关闭掉这个socket。

单进程模式下，如果没有客户端到来，进程一直阻塞在 accept调用上。阻塞在accept()不可怕，如果阻塞在read()系统调用，将导致整个服务器不能对其他的客户端提供服务。

[血的教训]
以前我在编写一个TCP实现文件上传和下载功能的套接字程序时，希望在一次连接中，直接上传和下载文件，最终子上传完成后，服务器阻塞在recv函数中，导致下载一直没有完成，调试怎么也没有发现问题，后来Ctrl+C直接终止了客户端程序后，服务器才从瘫痪中苏醒。

或者我们也可以假设这样一个情景：
accept()得到一个客户端的连接，此时的fd唯一标示该连接。现在服务器进入read()系统调用，但是此时的客户端并没有发送数据，那么服务端一直阻塞在read系统调用。此时来了一个新的连接，但是服务端不能予以相应，就是accept()函数不能被服务器调用。那么这个连接是失败的。可想而知，迭代类型的服务器模型是有多么的低效。

这点问题在UDP程序中也和明显，例如不过，UDP恰恰常用这种方式，因为UDP 是非面向连接的，整个过程就是两个函数

recvfrom( );`
DEAL( );
sendto( );

因为UDP 的非面向连接性，而且采用的是非可靠传输，传输速率较TCP快。如果在传输过程中数据丢失，会导致客户端阻塞在recvfrom()调用上。
因此最好需要设置客户端的recvfrom()超时。。。。

并发服务器则是类似下面的逻辑

listenfd = socket( ... );    /*  创建套接字  */
bind(listenfd, ... );        /*  命名套接字  */      
listen(listenfd,LISTENQ);    /*  开始监听套机字  */
while( 1 )                   /*  为每个客户端请求创建线程或者进程处理  */
{
    connfd = accept(listenfd, ... );/*  获取客户端的连接请求  */
    if((pid = fork()) == 0)   /*  在子进程中处理客户端的请求  */
    {
        close(listenfd);  /*  首先关闭掉监听套接字  */ 
        /* 因为子进程并不需要监听，它只负责处理逻辑并发消息给客户端*/
        DealLogic(connfd);   /*  处理客户端请求  */
        close(connfd);       /*  关闭客户端的连接套接字  */

    }
    close(connfd);  /*  父进程中关闭客户端的连接套接字  */
}

这样每来一个客户端，服务器就fork（分叉）一个进程去处理请求，这样主进程就一直处于监听状态而不会被阻塞。

千万不要以为fork出来一个子进程就产生了2个新的socket描述符，实际上子进程和父进程是共享listenfd和connfd的，每个文件和套接字都有一个引用计数，引用计数在文件表项中维护，它是当前打开着的引用该文件或套接字的描述符的个数。socket返回后与listenfd关联的文件表项的引用计数为1。accept返回后与connfd关联的文件表项的引用计数也为1。然后fork返回后，这两个描述符就在父进程与子进程间共享（也就是被复制），因此与这两个套接字相关联的文件表项各自的访问计数值均为2。这么一来，当父进程关闭connfd时，它只是把相应的引用计数值从2减为1。该套接字真正的清理和资源释放要等到其引用计数值到达0时才发生。这会在稍后子进程也关闭connfd时发生。

因此当父进程关闭connfd的时候它只是把这个connfd的访问计数值减了1而已，由于访问计数值还 > 0（因为还有客户端的connfd连着呢），所以它并没有断开和客户端的连接。

那么如果父进程不关闭connfd有什么后果？

第一，因为可分配的socket描述符是有限的，如果分配了以后不释放，自然内核不会对它回收再利用，那么有限个描述符耗总会有耗尽的一天。

第二，服务器在将获取客户端的连接后，将与客户端通信的任务交给子进程，而父进程期望能继续监听并accept下一个连接了，但如果每获取一个链接，父进程不关闭自己跟客户的连接，那么这个连接会永远存在！即服务器获取到的所有客户端连接都不会断开，始终存在与服务器的生命周期中，那后果可想而知。。。。

常见的I/O模型

常见网络IO模型有如下几类：

阻塞式IO
非阻塞式IO
IO复用
信号驱动IO
异步IO
除了这几个经典的模型之外，还有其他的比如
多进程或者多线程并发I/O, 基于事件驱动的服务器模型和多线程的服务器模型（Multi-Thread），以及windows下的IOCP模型和linux下的epoll模型

阻塞I/O（blocking I/O）

---

简介：进程会一直阻塞，直到数据拷贝完成，阻塞IO的特点就是在IO执行的两个阶段（等待数据和拷贝数据两个阶段）都被block了

应用程序调用一个IO函数，导致应用程序阻塞，等待数据准备好。 如果数据没有准备好，一直等待….数据准备好了，从内核拷贝到用户空间,IO函数返回成功指示。

几乎所有的程序员第一次接触到的网络编程都是从listen()、send()、recv() 等接口开始的，这些接口都是阻塞型的。使用这些接口可以很方便的构建服务器/客户机的模型。下面是一个简单地“一问一答”的服务器。

套接字在调用recv()/recvfrom（）函数时，发生在内核中等待数据和复制数据的过程。调用recv()函数时，系统首先查是否有准备好的数据。如果数据没有准备好，那么系统就处于等待状态。当数据准备好后，将数据从系统缓冲区复制到用户空间，然后该函数返回。在套接应用程序中，当调用recv()函数时，未必用户空间就已经存在数据，那么此时recv()函数就会处于等待状态。

当使用socket()函数创建套接字时，默认的套接字都是阻塞的。这意味着当调用Sockets API不能立即完成时，线程处于等待状态，直到操作完成。

但是并不是所有Sockets API以阻塞套接字为参数调用都会发生阻塞。例如，以阻塞模式的套接字为参数调用bind()、listen()函数时，函数会立即返回。将可能阻塞套接字的Sockets API调用分为以下四种:

1．输入操作： recv()、recvfrom()函数。以阻塞套接字为参数调用该函数接收数据。如果此时套接字缓冲区内没有数据可读，则调用线程在数据到来前一直睡眠。

2．输出操作： send()、sendto()函数。以阻塞套接字为参数调用该函数发送数据。如果套接字缓冲区没有可用空间，线程会一直睡眠，直到有空间。

3．接受连接：accept()。以阻塞套接字为参数调用该函数，等待接受对方的连接请求。如果此时没有连接请求，线程就会进入睡眠状态。

4．外出连接：connect()函数。对于TCP连接，客户端以阻塞套接字为参数，调用该函数向服务器发起连接。该函数在收到服务器的应答前，不会返回。这意味着TCP连接总会等待至少到服务器的一次往返时间。

使用阻塞模式的套接字，开发网络程序比较简单，容易实现。当希望能够立即发送和接收数据，且处理的套接字数量比较少的情况下，使用阻塞模式来开发网络程序比较合适。

阻塞模式套接字的不足表现为，在大量建立好的套接字线程之间进行通信时比较困难。当使用“生产者-消费者”模型开发网络程序时，为每个套接字都分别分配一个读线程、一个处理数据线程和一个用于同步的事件，那么这样无疑加大系统的开销。其最大的缺点是当希望同时处理大量套接字时，将无从下手，其扩展性很差.

同时我们注意到，大部分的socket接口都是阻塞型的。所谓阻塞型接口是指系统调用（一般是IO接口）不返回调用结果并让当前线程一直阻塞，只有当该系统调用获得结果或者超时出错时才返回。

实际上，除非特别指定，几乎所有的IO接口 ( 包括socket接口 ) 都是阻塞型的。这给网络编程带来了一个很大的问题，如在调用send()的同时，线程将被阻塞，在此期间，线程将无法执行任何运算或响应任何的网络请求。

阻塞模式给网络编程带来了一个很大的问题，如在调用 send()的同时，线程将被阻塞，在此期间，线程将无法执行任何运算或响应任何的网络请求，即我们当前描述的阻塞IO服务器模型其实是一个（同步 + 阻塞 + 迭代 类型的服务器模式）。这种服务器是最低效的模型，给多客户机、多业务逻辑的网络编程带来了挑战。

这时，我们可能会选择多线程的方式（即同步+阻塞+并发）来解决这个问题。

多线程/进程服务器（同步 + 阻塞 + 并发）

一个简单的改进方案是在服务器端使用多线程（或多进程）。多线程（或多进程）的目的是让每个连接都拥有独立的线程（或进程），这样任何一个连接的阻塞都不会影响其他的连接。具体使用多进程还是多线程，并没有一个特定的模式。传统意义上，进程的开销要远远大于线程，所以如果需要同时为较多的客户机提供服务，则不推荐使用多进程；如果单个服务执行体需要消耗较多的CPU资源，譬如需要进行大规模或长时间的数据运算或文件访问，则进程较为安全。通常，使用pthread_create ()创建新线程，fork()创建新进程。

这种方式本质上仍然是阻塞I/O，但是使用了多进程或者多线程的I/O来实现并发操作

具体使用多进程还是多线程，并没有一个特定的模式。传统意义上，进程的开销要远远大于线程，所以，如果需要同时为较多的客户机提供服务，则不推荐使用多进程；如果单个服务执行体需要消耗较多的 CPU 资源，譬如需要进行大规模或长时间的数据运算或文件访问，则进程较为安全。通常，使用 pthread_create () 创建新线程，fork() 创建新进程。
多线程/进程服务器同时为多个客户机提供应答服务，主线程持续等待客户端的连接请求，如果有连接，则创建新线程，并在新线程中提供为前例同样的问答服务。
服务器套接字每次accept()能够返回一个新的socket。当服务器执行完bind()和listen()后，操作系统已经开始在指定的端口处监听所有的连接请求，如果有请求，则将该连接请求加入请求队列。调用accept()接口正是从 socket s 的请求队列抽取第一个连接信息，创建一个与s同类的新的socket返回句柄。新的socket句柄即是后续read()和recv()的输入参数。如果请求队列当前没有请求，则accept() 将进入阻塞状态直到有请求进入队列。
上述多线程的服务器模型似乎完美的解决了为多个客户机提供问答服务的要求，但其实并不尽然。如果要同时响应成百上千路的连接请求，则无论多线程还是多进程都会严重占据系统资源，降低系统对外界响应效率，而线程与进程本身也更容易进入假死状态。
由此 很多程序员可能会考虑使用“线程池”或“连接池”。“线程池”旨在减少创建和销毁线程的频率，其维持一定合理数量的线程，并让空闲的线程重新承担新的执行任务。“连接池”维持连接的缓存池，尽量重用已有的连接、减少创建和关闭连接的频率。这两种技术都可以很好的降低系统开销，都被广泛应用很多大型系统，如websphere、tomcat和各种数据库等。但是，“线程池”和“连接池”技术也只是在一定程度上缓解了频繁调用IO接口带来的资源占用。而且，所谓“池”始终有其上限，当请求大大超过上限时，“池”构成的系统对外界的响应并不比没有池的时候效果好多少。所以使用“池”必须考虑其面临的响应规模，并根据响应规模调整“池”的大小。

但是，“线程池”和“连接池”技术也只是在一定程度上缓解了频繁调用 IO 接口带来的资源占用。而且，所谓“池”始终有其上限，当请求大大超过上限时，“池”构成的系统对外界的响应并不比没有池的时候效果好多少。所以使用“池”必须考虑其面临的响应规模，并根据响应规模调整“池”的大小。

对应上例中的所面临的可能同时出现的上千甚至上万次的客户端请求，“线程池”或“连接池”或许可以缓解部分压力，但是不能解决所有问题。

非阻塞I/O （nonblocking I/O）

---

在这种模型中，当用户进程发出read操作时，如果kernel中的数据还没有准备好，那么它并不会block用户进程，而是立刻返回一个error。从用户进程角度讲 ，它发起一个read操作后，并不需要等待，而是马上就得到了一个结果。用户进程判断结果是一个error时，它就知道数据还没有准备好，于是它可以再次发送read操作。一旦kernel中的数据准备好了，并且又再次收到了用户进程的system call，那么它马上就将数据拷贝到了用户内存，然后返回。

所以，在非阻塞式IO中，用户进程其实是需要不断的主动询问kernel数据准备好了没有。

非阻塞的接口相比于阻塞型接口的显著差异在于，在被调用之后立即返回。linux下使用如下的函数可以将某句柄fd设为非阻塞状态。

    fcntl( fd, F_SETFL, O_NONBLOCK );

从应用程序的角度来说，blocking read 调用会延续很长时间。在内核执行读操作和其他工作时，应用程序会被阻塞。

非阻塞的IO可能并不会立即满足，需要应用程序调用许多次来等待操作完成。这可能效率不高，因为在很多情况下，当内核执行这个命令时，应用程序必须要进行忙碌等待，直到数据可用为止。另一个问题是，在循环调用非阻塞IO的时候，将大幅度占用CPU，所以一般使用select等来检测”是否可以操作“。

同样在非阻塞状态下，recv() 接口在被调用后立即返回，而返回值代表了不同的含义。

lag=fcntl(sockfd,F_GETFL,0);
fcntl(sockfd,F_SETFL,flag|O_NONBLOCK)

非阻塞式I/O模型对4种I/O操作返回的错误
读操作：接收缓冲区无数据时返回EWOULDBLOCK
写操作：发送缓冲区无空间时返回EWOULDBLOCK；空间不够时部分拷贝，返回实际拷贝字节数
建立连接：启动3次握手，立刻返回错误EINPROGRESS；服务器客户端在同一主机上connect立即返回成功
接受连接：没有新连接返回EWOULDBLOCK

可以看到服务器线程可以通过循环调用recv()接口，可以在单个线程内实现对所有连接的数据接收工作。但是上述模型绝不被推荐。因为，循环调用recv()将大幅度推高CPU 占用率；此外，在这个方案中recv()更多的是起到检测“操作是否完成”的作用，实际操作系统提供了更为高效的检测“操作是否完成“作用的接口，例如select()多路复用模式，可以一次检测多个连接是否活跃。

I/O复用(select 和poll) （I/O multiplexing）

---

IO multiplexing这个词可能有点陌生，但是如果我说select/epoll，大概就都能明白了。有些地方也称这种IO方式为事件驱动IO(event driven IO)。我们都知道，select/epoll的好处就在于单个process就可以同时处理多个网络连接的IO。它的基本原理就是select/epoll这个function会不断的轮询所负责的所有socket，当某个socket有数据到达了，就通知用户进程。它的流程如图：

当用户进程调用了select，那么整个进程会被block，而同时，kernel会“监视”所有select负责的socket，当任何一个socket中的数据准备好了，select就会返回。这个时候用户进程再调用read操作，将数据从kernel拷贝到用户进程。
这个图和blocking IO的图其实并没有太大的不同，事实上还更差一些。因为这里需要使用两个系统调用(select和recvfrom)，而blocking IO只调用了一个系统调用(recvfrom)。但是，用select的优势在于它可以同时处理多个connection。所以，如果处理的连接数不是很高的话，使用select/epoll的server不一定比使用multi-threading + blocking IO的server性能更好，可能延迟还更大。select/epoll的优势并不是对于单个连接能处理得更快，而是在于能处理更多的连接。
在多路复用模型中，对于每一个socket，一般都设置成为non-blocking，但是，如上图所示，整个用户的process其实是一直被block的。只不过process是被select这个函数block，而不是被socket IO给block。因此select()与非阻塞IO类似。
大部分Unix/Linux都支持select函数，该函数用于探测多个文件句柄的状态变化。
下面给出select接口的原型：

FD_ZERO(int fd, fd_set* fds)
FD_SET(int fd, fd_set* fds)
FD_ISSET(int fd, fd_set* fds)
FD_CLR(int fd, fd_set* fds)
int select(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds,
struct timeval *timeout)

这里，fd_set 类型可以简单的理解为按 bit 位标记句柄的队列，例如要在某 fd_set 中标记一个值为16的句柄，则该fd_set的第16个bit位被标记为1。具体的置位、验证可使用 FD_SET、FD_ISSET等宏实现。在select()函数中，readfds、writefds和exceptfds同时作为输入参数和输出参数。如果输入的readfds标记了16号句柄，则select()将检测16号句柄是否可读。在select()返回后，可以通过检查readfds有否标记16号句柄，来判断该“可读”事件是否发生。另外，用户可以设置timeout时间。

该模型只是描述了使用select()接口同时从多个客户端接收数据的过程；由于select()接口可以同时对多个句柄进行读状态、写状态和错误状态的探测，所以可以很容易构建为多个客户端提供独立问答服务的服务器系统。如下图。

这里需要指出的是，客户端的一个 connect() 操作，将在服务器端激发一个“可读事件”，所以 select() 也能探测来自客户端的 connect() 行为。
上述模型中，最关键的地方是如何动态维护select()的三个参数readfds、writefds和exceptfds。

作为输入参数，readfds应该标记所有的需要探测的“可读事件”的句柄，其中永远包括那个探测 connect() 的那个“母”句柄；同时，writefds 和 exceptfds 应该标记所有需要探测的“可写事件”和“错误
事件”的句柄 ( 使用 FD_SET() 标记 )。

作为输出参数，readfds、writefds和exceptfds中的保存了 select() 捕捉到的所有事件的句柄值。程序员需要检查的所有的标记位 ( 使用FD_ISSET()检查 )，以确定到底哪些句柄发生了事件。

上述模型主要模拟的是“一问一答”的服务流程，所以如果select()发现某句柄捕捉到了“可读事件”，服务器程序应及时做recv()操作，并根据接收到的数据准备好待发送数据，并将对应的句柄值加入writefds，准备下一次的“可写事件”的select()探测。同样，如果select()发现某句柄捕捉到“可写事件”，则程序应及时做send()操作，并准备好下一次的“可读事件”探测准备。

这种模型的特征在于每一个执行周期都会探测一次或一组事件，一个特定的事件会触发某个特定的响应。我们可以将这种模型归类为“事件驱动模型”。

相比其他模型，使用select() 的事件驱动模型只用单线程（进程）执行，占用资源少，不消耗太多 CPU，同时能够为多客户端提供服务。如果试图建立一个简单的事件驱动的服务器程序，这个模型有一定的参考价值。

但这个模型依旧有着很多问题。首先select()接口并不是实现“事件驱动”的最好选择。因为当需要探测的句柄值较大时，select()接口本身需要消耗大量时间去轮询各个句柄。很多操作系统提供了更为高效的接口，如linux提供了epoll，BSD提供了kqueue，Solaris提供了/dev/poll，…。

如果需要实现更高效的服务器程序，类似epoll这样的接口更被推荐。遗憾的是不同的操作系统特供的epoll接口有很大差异，所以使用类似于epoll的接口实现具有较好跨平台能力的服务器会比较困难。

其次，该模型将事件探测和事件响应夹杂在一起，一旦事件响应的执行体庞大，则对整个模型是灾难性的。
单个庞大的执行体1的将直接导致响应其他事件的执行体迟迟得不到执行，并在很大程度上降低了事件探测的及时性。

幸运的是，有很多高效的事件驱动库可以屏蔽上述的困难，常见的事件驱动库有libevent库，还有作为libevent替代者的libev库。这些库会根据操作系统的特点选择最合适的事件探测接口，并且加入了信号(signal) 等技术以支持异步响应，这使得这些库成为构建事件驱动模型的不二选择。

我们将在介绍如何使用libev库替换select或epoll接口，实现高效稳定的服务器模型。

事件驱动（event driven I/O）

Libevent 是一种高性能事件循环/事件驱动库。

为了实际处理每个请求，libevent 库提供一种事件机制，它作为底层网络后端的包装器。事件系统让为连接添加处理函数变得非常简便，同时降低了底层IO复杂性。这是 libevent 系统的核心。

创建 libevent 服务器的基本方法是，注册当发生某一操作（比如接受来自客户端的连接）时应该执行的函数，然后调用主事件循环 event_dispatch()。执行过程的控制现在由 libevent 系统处理。注册事件和将调用的函数之后，事件系统开始自治；在应用程序运行时，可以在事件队列中添加（注册）或 删除（取消注册）事件。事件注册非常方便，可以通过它添加新事件以处理新打开的连接，从而构建灵活的网络处理系统。
使用事件驱动模型实现高效稳定的网络服务器程序

信号驱动I/O （signal driven I/O (SIGIO)）

---

使用信号驱动I/O时，当网络套接字可读后，内核通过发送SIGIO信号通知应用进程，于是应用可以开始读取数据。有时也称此方式为异步I/O。但是严格讲，该方式并不能算真正的异步I/O，因为实际读取数据到应用进程缓存的工作仍然是由应用自己负责的。

首先我们允许套接口进行信号驱动I/O,并安装一个信号处理函数，进程继续运行并不阻塞。当数据准备好时，进程会收到一个SIGIO信号，可以在信号处理函数中调用I/O操作函数处理数据。

首先允许套接字使用信号驱动I/O模式，并且通过sigaction系统调用注册一个SIGIO信号处理程序。当有数据到达后，系统向应用进程交付一个SIGIO信号，然后既可以如图中所示那样在信号处理程序中读取套接字数据，然后通知主循环处理逻辑，也可以直接通知主循环逻辑，让主程序进行读取操作。

无论采用上面描述的哪种方式读取数据，应用进程都不会因为尚无数据达到而被阻塞，应用主循环逻辑可以继续执行其他功能，直到收到通知后去读取数据或者处理已经在信号处理程序中读取完毕的数据。
为了让套接字描述符可以工作于信号驱动I/O模式，应用进程必须完成如下三步设置：
1.注册SIGIO信号处理程序。(安装信号处理器)
2.使用fcntl的F_SETOWN命令，设置套接字所有者。（设置套接字的所有者）
3.使用fcntl的F_SETFL命令，置O_ASYNC标志，允许套接字信号驱动I/O。（允许这个套接字进行信号输入输出）

注意，必须保证在设置套接字所有者之前，向系统注册信号处理程序，否则就有可能在fcntl调用后，信号处理程序注册前内核向应用交付SIGIO信号，导致应用丢失此信号。下面的程序片段描述了怎样为套接字设置信号驱动I/O：

sigaction 函数： 
    int sigaction(int signum,const struct sigaction *act,struct sigaction *oldact) 

该函数会按照参数signum指定的信号编号来设置该信号的处理函数，signum可指定SIGK
ILL和SIGSTOP以外的所有信号，如果参数act不是NULL指针，则用来设置新的信号处理方式。

实际上，Linux内核从2.6开始，也引入了支持异步响应的IO操作，如aio_read, aio_write，这就是异步IO。

异步I/O （asynchronous I/O (the POSIX aio_functions)）

---

Linux下的asynchronous IO其实用得不多，从内核2.6版本才开始引入。先看一下它的流程：

用户进程发起read操作之后，立刻就可以开始去做其它的事。而另一方面，从kernel的角度，当它受到一个asynchronous read之后，首先它会立刻返回，所以不会对用户进程产生任何block。然后，kernel会等待数据准备完成，然后将数据拷贝到用户内存，当这一切都完成之后，kernel会给用户进程发送一个signal，告诉它read操作完成了。
使用异步 I/O 大大提高应用程序的性能

异步IO是真正非阻塞的，它不会对请求进程产生任何的阻塞，因此对高并发的网络服务器实现至关重要。

IOCP（I/O Completion Port）

IOCP（I/O Completion Port）,常称I/O完成端口。 IOCP模型属于一种通讯模型，适用于(能控制并发执行的)高负载服务器的一个技术。 通俗一点说，就是用于高效处理很多很多的客户端进行数据交换的一个模型。或者可以说，就是能异步I/O操作的模型。
Windows下高并发的高性能服务器一般会采用完成端口IOCP技术,Linux下则会采用Epoll实现一个高性能的I/O.

总结

---

到目前为止，已经将四个IO模型都介绍完了。现在回过头来回答最初的那几个问题：blocking和non-blocking的区别在哪，synchronous IO和asynchronous IO的区别在哪。
先回答最简单的这个：blocking与non-blocking。前面的介绍中其实已经很明确的说明了这两者的区别。调用blocking IO会一直block住对应的进程直到操作完成，而non-blocking IO在kernel还在准备数据的情况下会立刻返回。
在说明synchronous IO和asynchronous IO的区别之前，需要先给出两者的定义。Stevens给出的定义（其实是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;
两者的区别就在于synchronous IO做”IO operation”的时候会将process阻塞。按照这个定义，之前所述的blocking IO，non-blocking IO，IO multiplexing都属于synchronous IO。有人可能会说，non-blocking IO并没有被block啊。这里有个非常“狡猾”的地方，定义中所指的”IO operation”是指真实的IO操作，就是例子中的recvfrom这个系统调用。non-blocking IO在执行recvfrom这个系统调用的时候，如果kernel的数据没有准备好，这时候不会block进程。但是当kernel中数据准备好的时候，recvfrom会将数据从kernel拷贝到用户内存中，这个时候进程是被block了，在这段时间内进程是被block的。而asynchronous IO则不一样，当进程发起IO操作之后，就直接返回再也不理睬了，直到kernel发送一个信号，告诉进程说IO完成。在这整个过程中，进程完全没有被block。
还有一种不常用的signal driven IO，即信号驱动IO。总的来说，UNP中总结的IO模型有5种之多：阻塞IO，非阻塞IO，IO复用，信号驱动IO，异步IO。前四种都属于同步IO。阻塞IO不必说了。非阻塞IO ，IO请求时加上O_NONBLOCK一类的标志位，立刻返回，IO没有就绪会返回错误，需要请求进程主动轮询不断发IO请求直到返回正确。IO复用同非阻塞IO本质一样，不过利用了新的select系统调用，由内核来负责本来是请求进程该做的轮询操作。看似比非阻塞IO还多了一个系统调用开销，不过因为可以支持多路IO，才算提高了效率。信号驱动IO，调用sigaltion系统调用，当内核中IO数据就绪时以SIGIO信号通知请求进程，请求进程再把数据从内核读入到用户空间，这一步是阻塞的。
异步IO，如定义所说，不会因为IO操作阻塞，IO操作全部完成才通知请求进程。

Linux下的asynchronous IO其实用得不多，从内核2.6版本才开始引入。先看一下它的流程：
用户进程发起read操作之后，立刻就可以开始去做其它的事。而另一方面，从kernel的角度，当它受到一个asynchronous read之后，首先它会立刻返回，所以不会对用户进程产生任何block。然后，kernel会等待数据准备完成，然后将数据拷贝到用户内存，当这一切都完成之后，kernel会给用户进程发送一个signal，告诉它read操作完成了。
用异步IO实现的服务器这里就不举例了，以后有时间另开文章来讲述。异步IO是真正非阻塞的，它不会对请求进程产生任何的阻塞，因此对高并发的网络服务器实现至关重要。

小结

---

常见网络IO模型有如下几类：

阻塞式IO（简单迭代型+多进程或者多线程并发型）
非阻塞式IO
IO复用（select / poll）
信号驱动IO（signal）
异步IO(async）

前四种都是同步，只有最后一种才是异步IO。

同步IO引起进程阻塞，直至IO操作完成。
异步IO不会引起进程阻塞。
IO复用是先通过select调用阻塞。

除了这几个经典的模型之外，还有其他的比如

多进程或者多线程并发I/O
基于事件驱动的服务器模型和多线程的服务器模型（Multi-Thread）
windows下的IOCP模型和linux下的epoll模型