1 网络IO模型介绍
服务器端编程经常需要构造高性能的IO模型，常见的IO模型有四种：
2 I/O基础知识
2.1 什么是文件描述符？
在网络中，一个socket对象就是1个文件描述符，在文件中，1个文件句柄（即file对象）就是1个文件描述符。其实可以理解为就是一个“指针”或“句柄”，指向1个socket或file对象，当file或socket发生改变时，这个对象对应的文件描述符，也会发生相应改变。
2.2 什么是I/O
1、先了解什么是I/O？
I/O（input/output），即输入/输出。操作系统会对IO设备进行编址，IO设备用操作系统分配的地址来处理自己的输入输出信息。
2、常用的I/O模型
阻塞IO:blocking IO、非阻塞IO:non-blocking IO、同步IO:synchronous IO、异步IO:asynchronous IO
3、IO发生时涉及的对象和步骤。对于一个network IO (这里我们以read举例)，它会涉及到两个系统对象，一个是调用这个IO的process(or thread)，另一个就是系统内核(kernel)。当一个read操作发生 时，它会经历两个阶段：
(1)等待数据准备 (Waiting for the data to be ready)----内核等待数据可读
(2)将数据从内核拷贝到进程中 (Copying the data from the kernel to the process)----将内核读到的数据拷贝到进程
记住这两点很重要，因为这些IO Model的区别就是在两个阶段上各有不同的情况。
2.3 I/O操作包括哪些?
- 网络操作，即建立socket对象，进行建立连接，发送、接收、处理请求、响应等
- 文件操作，即建立file对象，进行文件的读、写操作
- 终端操作。即进行交互式输入输出等操作
注意：对于windows只支持Socket操作；其他系统支持以上三种I/O操作，但是无法检测普通文件操作，即自动读取普通文件，监测文件是否发现变化。
3 网络IO模型
同步(synchronous)IO、异步(asynchronous)IO、阻塞(blocking)IO、非阻塞(non-blocking)IO分别是什么，到底有什么区别？这个问题其实不同的人给出的答案都可能不同，比如wiki，就认为 asynchronous IO和non-blocking IO是同一个东西。这其实是因为不同的人有不同的知识背景，并且在讨论这个问题的时候上下文(context)也不相同。所以，为了更好的回答这个问题，我先限定一下本文的上下文。
本文讨论的背景是Linux环境下的network IO。本文最重要的参考文献是Richard Stevens的“UNIX® Network Programming Volume 1, Third Edition: The Sockets Networking ”，6.2节“I/O Models ”，Stevens在这节中详细说明了各种IO的特点和区别。
3.1 阻塞IO：Blocking I/O
默认情况下，所有的socket都是阻塞的，如下图：
当用户进程调用了recvfrom这个系统调用，kernel就开始了IO的第一个阶段：准备数据。对于network io来说，很多时候数据在一开始还没有到达（比如没有收到一个完整的TCP/UDP包），这个时候kernel就要等待数据。而在用户进程这边，整个进程会被阻塞。当kernel一直等到数据准备好了，它就会将数据从kernel中拷贝到用户内存，然后kernel返回结果，用户进程才解除block的状态，重新运行起来。所以blocking IO的特点是：I/O执行时的两个操作都是阻塞的（等待数据准备---Waiting for the data to be ready)和将数据从内核拷贝到用户进程中---Copying the data from the kernel to the process）。
在python的socket模型中：accept()和recv()都是阻塞的，所谓阻塞型接口是指系统调用（一般是IO接口）如果不返回结果就一直等待，就是socket中的有发就有收、收发必相等。如果两边都在同时收，就会阻塞后面的代码无法执行。
那既然原生的Socket是阻塞的，那有什么办法来解决呢？使用多线程或多进程。多线程（多进程）的目的是让每个连接都拥有独立的线程（进程），这样任何一个连接的阻塞都不会影响其他的连接。
我们假设对上述的服务器/客户机模型提出更高的要求，即让服务器同时为多个客户机提供一问一答的服务。于是有了如下的模型。
在上述的线程/时间图例中，主线程持续等待客户端的连接请求，如果有连接，则创建新线程，并在新线程中提供为前例同样的问答服务。
那为何一个socket可以accept多次。实际上socket的设计者可能特意为多客户机的情况留下了伏笔，让accept()能够返回一个新的socket对象，该socket对象即为当前请求的客户机socket对象(accept同时返回当前请求客户机的socket对象以及由ip地址和端口号组成的元组)。执行完bind()和listen()后，操作系统已经开始在指定的端口处监听所有的连接请求，如果有请求，则将该连接请求加入请求队列。调用accept()接口正是从请求队列抽取第一个连接信息，创建一个新的socket返回句柄。新的socket句柄为后续的read()和recv()提供服务。如果请求队列当前没有请求，则accept()将进入阻塞状态直到有请求进入队列。
上述多线程的服务器模型似乎完美的解决了为多个客户机提供问答服务的要求，但其实并不尽然。如果要同时响应成百上千路的连接请求，则无论多线程还是多进程都会严重占据系统资源，降低系统对外界响应效率，而线程与进程本身也更容易进入假死状态。
很多程序员可能会考虑使用“线程池”或“连接池”。“线程池”旨在减少创建和销毁线程的频率，其维持一定合理数量的线程，并让空闲的线程重新承担新的执行任务。“连接池”维持连接的缓存池，尽量重用已有的连接、减少创建和关闭连接的频率。这两种技术都可以很好的降低系统开销，都被广泛应用很多大型系统，如websphere、tomcat和各种数据库等。但是，“线程池”和“连接池”技术也只是在一定程度上缓解了频繁调用IO接口带来的资源占用。而且，所谓“池”始终有其上限，当请求大大超过上限时，“池”构成的系统对外界的响应并不比没有池的时候效果好多少。所以使用“池”必须考虑其面临的响应规模，并根据响应规模调整“池”的大小。
对应上例中的所面临的可能同时出现的上千甚至上万次的客户端请求，“线程池”或“连接池”或许可以缓解部分压力，但是不能解决所有问题。总之，多线程模型可以方便高效的解决小规模的服务请求，但面对大规模的服务请求，多线程模型也会遇到瓶颈，可以用非阻塞接口来尝试解决这个问题。
3.2 非阻塞IO: non-blocking IO
在python socket中，设置setblocking的值为False(默认为True)，那么现在accept()将不再阻塞，如下图：
从图中可以看出，当用户进程调用recvfrom操作时，如果kernel中的数据还没有准备好，那么它并不会block用户进程，而是立刻返回一个error。 从用户进程角度讲，它发起一个recvfrom操作后，并不需要等待，而是马上就得到了一个结果。用户进程判断结果是一个error时，它就知道数据还没有准备好，于是它可以再次发送recvfrom操作。一旦kernel中的数据准备好了，并且又再次收到了用户进程的system call，那么它马上就将数据拷贝到用户内存，然后返回。
所以，在非阻塞IO中，用户进程其实是需要不断的主动询问kernel数据是否准备好。非阻塞IO接口相比于阻塞型IO接口的显著差异在于，在被调用之后立即返回。python中设置setblocking为False时 accept() 将不会阻塞。
3.3 IO多路复用（IO multiplexing）
IO多路复用模型是建立在内核提供的多路分离函数select基础之上的，使用select函数可以避免非阻塞IO模型中轮询等待的问题。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就会返回。此时用户进程再调用recvfrom操作，将数据从kernel拷贝到用户进程。
这个图和blocking
IO的图其实并没有太大的不同，事实上还更差一些。因为这里需要使用两个系统调用(select和recvfrom)，而blocking
IO只调用了一个系统调用(recvfrom)。但是，用select的优势在于它可以同时处理多个connection。（在IO多路复用中，对一个IO端口，两次调用，两次返回，比阻塞IO并没有什么优越性；关键是能实现同时对多个IO端口进行监听，所以，如果处理的连接数不是很高的话，使用select/epoll的web server不一定比使用multi-threading + blocking
IO的web server性能更好，可能延迟还更大。select/epoll的优势并不是对于单个连接能处理得更快，而是在于能处理更多的连接。）
I/O复用模型中会用到select、poll、epoll函数，这几个函数也会使进程阻塞，但是和阻塞I/O所不同的的，这两个函数可以同时阻塞多个I/O操作。而且可以同时对多个读操作，多个写操作的I/O函数进行检测，直到有数据可读或可写时，才真正调用I/O操作函数（在多路复用模型中，对于每一个socket，一般都设置成为non-blocking，但是，如上图所示，整个用户的process其实是一直被block的。只不过process是被select这个函数block，而不是被socket IO给block。因此select()与非阻塞IO类似。）。
3.4 异步I/O：asynchronous IO
linux下的asynchronous IO其实用得很少。先看一下它的流程：
用户进程发起read操作之后，立刻就可以开始去做其它的事。而另一方面，从kernel的角度，当它受到一个asynchronous read之后，首先它会立刻返回，所以不会对用户进程产生任何block。然后，kernel会等待数据准备完成，然后将数据拷贝到用户内存，当这一切都完成之后，kernel会给用户进程发送一个signal，告诉它read操作完成了。
异步IO是真正非阻塞的，它不会对请求进程产生任何的阻塞，相比于IO多路复用模型，异步IO并不十分常用，不少高性能并发服务程序使用IO多路复用模型+多线程任务处理的架构基本可以满足需求。况且目前操作系统对异步IO的支持并非特别完善，更多的是采用IO多路复用模型模拟异步IO的方式（IO事件触发时不直接通知用户线程，而是将数据读写完毕后放到用户指定的缓冲区中）。
3.5 四种网络IO模型的比较
到目前为止，已经将四个IO模型都介绍完了。现在回过头来看下面的问题:
1、blocking和non-blocking的区别在哪？
blocking与non-blocking的区别：调用blocking IO会一直block住对应的进程直到操作完成，而non-blocking IO会立刻返回。
2、synchronous IO和asynchronous IO的区别在哪？
在说明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。
注：同步IO引起进程阻塞，直至IO操作完成。异步IO不会引起进程阻塞。
3、它们之间的区别在哪？
4、non-blocking IO和asynchronous IO的区别
经过上面的介绍，会发现non-blocking IO和asynchronous IO的区别还是很明显的。在non-blocking IO中，虽然进程大部分时间都不会被block，但是它仍然要求进程去主动的check，并且当数据准备完成以后，也需要进程主动的再次调用recvfrom来将数据拷贝到用户内存(此过程阻塞)。而asynchronous IO则完全不同，它就像是用户进程将整个IO操作交给了他人（kernel）完成，然后他人做完后发信号通知。在此期间，用户进程不需要去检查IO操作的状态，也不需要主动的去拷贝数据(全程非阻塞)。
参考资料：
http://www.cnblogs.com/luotianshuai/p/5098408.html
http://blog.csdn.net/historyasamirror/article/details/5778378
http://www.cnblogs.com/fanzhidongyzby/p/4098546.html