阻塞I/O

默认情况下，所有的socket都是阻塞的. 如图所示

应用发起recvfrom这个系统调用, 应用被阻塞
内核等待数据准备好
数据准备好, 内核将数据复制到应用缓冲区
应用从阻塞里恢复，处理数据

这也是理解和编程起来比较简单的模型，所以计算机早期用的很多,现在在处理超大文件的时候，也依然适用于这种模型。

非阻塞I/O

相比于Blocking I/O, Non-Blocking I/O的等待数据阶段不会被阻塞，也就是说操作系统不会挂起应用, 应用
不断轮询(polling)内核看是否数据准备好。某次轮询发现准备好了，再直接发系统调用阻塞取数据.

Unix网络编程里对轮询的定义是:
应用进程对非阻塞描述符循环发送系统调用，以查看某个操作是否就绪

I/O多路复用

在处理非常多的描述符的时候，I/O多路复用技术显得非常有用。I/O多路复用需要发送2次系统调用:

select或者poll, 获取可读条件, 等待描述符变成可读
发起recvfrom系统调用，内核复制数据到应用。

在只有1个客户端的时候，I/O多路复用技术甚至不如阻塞I/O.因为多发了一次系统调用。
但有些常用的网络场景，如:

既要处理TCP,又要处理UDP
一个服务器处理多个服务或者多个协议
一个TCP服务器既要监听socket，又要处理已连接socket

这些场景下，多发的这次系统调用能带来更高的I/O处理效率，能更均匀的使用服务器时间片, 处理更多连接。
常用的方法是把I/O多路复用和非阻塞I/O结合使用，这样应用进程不需要阻塞，能处理别的业务，同时又能够处理多个I/O请求

信号驱动I/O

信号模型的步骤是:

应用进程发起一个信号，告诉内核要什么文件，然后立马返回
内核准备好数据
应用进程收到信号发起recvfrom系统调用来阻塞取数据

信号驱动模型类似于你去一点点买奶茶，对方给你一个小票。
什么时候好了对方喊xx号(这就是信号)好了.然后你来取奶茶(recvfrom取数据)

异步I/O

步骤：

应用进程发起aio_read系统调用，告诉内核要什么文件，然后立马返回
内核准备好数据, copy到应用进程, 然后给应用进程发aio_read指定的信号
应用进程收到信号，开始处理数据,整个过程应用进程都没有被阻塞

AIO模型是比较高效的, 异步非阻塞，从各个方面来说都是。但是编程难度比较大(和人的思维惯性相左)，代码写起来不易维护，可能未来会火吧。目前I/O多路复用已经足够用了。

总结

前四种模型的区别主要在第一阶段，第二阶段recvfrom将数据从内核复制到应用的缓冲区期间，都会阻塞应用进程。
而异步I/O模型在两个阶段都要处理.

Non-Blocking I/O和Signal-Driven I/O在数据准备阶段都不会阻塞，前者要轮询内核数据是否准备好，后者是直接等待内核通知回调
Asynchronous I/O是在真正意义上的POSIX定义的异步io操作, 在数据准备和复制阶段都不会阻塞应用,但是编程难度大
I/O Multiplexing在数据准备阶段也会阻塞，但是可以处理更多I/O请求，也就是说加了层中间人抽象，虽然阻塞了应用进程，但是能知道多个fd可读可写,也是大名鼎鼎的reactor模式的基础