请求描述：
当进程调用一个进行IO操作的API时（比如read函数），在数据没有到达前，read 会挂起，进程会卡住。在数据读取完毕返回给进程时，
非阻塞就是 read 在数据没有读取完毕前，就返回了（返回值为-1，errno 设置为 EAGAIN）。此时进程没有拿到需要的数据。那怎么办？
一种是异步：
早期的异步实现方式是内核给进程发信号（SIGIO 或者 SIGPOLL）。数据读写完毕后，内核发信号给进程，然后进程内的信号处理函数再调用 read 读取数据（这时可以确保数据真的已经读取完毕了）。但这种方式有一个小小的瑕疵，就是在进程进行多个 fd 读写的时候，信号来的时候没办法分清到底是哪个 fd 上的数据已经真正准备好了。所以进程还是要对所有持有的 fd 进行 read 调用。后来的异步实现，就有了更好的 select / poll / epoll（I/O multiplexing）。现在基本上像比较流行的 Nginx / Redis 都用 epoll（在 FreeBSD 上是 kqueue）
图解：
阻塞式I/O模型：默认情况下，所有套接字都是阻塞的。怎么理解？先理解这么个流程，一个输入操作通常包括两个不同阶段：
（1）等待数据准备好；
（2）从内核向进程复制数据。
对于一个套接字上的输入操作，第一步通常涉及等待数据从网络中到达。当所有等待分组到达时，它被复制到内核中的某个缓冲区。第二步就是把数据从内核缓冲区复制到应用程序缓冲区。 好，下面我们以阻塞套接字的recvfrom的的调用图来说明阻塞
标红的这部分过程就是阻塞，直到阻塞结束recvfrom才能返回。
非阻塞式I/O： 以下这句话很重要：进程把一个套接字设置成非阻塞是在通知内核，当所请求的I/O操作非得把本进程投入睡眠才能完成时，
不要把进程投入睡眠，而是返回一个错误。看看非阻塞的套接字的recvfrom操作如何进行
可以看出recvfrom总是立即返回。
I/O多路复用：虽然I/O多路复用的函数也是阻塞的，但是其与以上两种还是有不同的，I/O多路复用是阻塞在select，epoll这样的系统调用之上，
而没有阻塞在真正的I/O系统调用如recvfrom之上。如图
信号驱动式I/O：用的很少，就不做讲解了。直接上图
异步I/O：这类函数的工作机制是告知内核启动某个操作，并让内核在整个操作（包括将数据从内核拷贝到用户空间）完成后通知我们。如图：
注意红线标记处说明在调用时就可以立马返回，等函数操作完成会通知我们
例子说明：
- 从A的业务代码到A的软件框架
- 从A的软件框架到计算机的操作系统内核
- 从A所在计算机的内核到网卡
- 从网卡经过网线发到交换机等设备，层层转发，到达B所在计算机的网卡
- 从B所在计算机的网卡到B所在计算机的内核
- 从B所在计算机的内核到B的程序的用户空间
- 从B的软件框架到B的业务代码
小乐爱喝茶，废话不说，煮开水。
出场人物：小乐，水壶两把（普通水壶，简称水壶；会响的水壶，简称响水壶）。
1 小乐把水壶放到火上，立等水开。（同步阻塞）
—— 小乐觉得自己有点傻
2 小乐把水壶放到火上，去客厅看电视，时不时去厨房看看水开没有。（同步非阻塞）
—— 小乐还是觉得自己有点傻，于是变高端了，买了把会响笛的那种水壶。水开之后，能大声发出呜呜~~~~的噪音。
3 小乐把响水壶放到火上，立等水开。（异步阻塞）
—— 小乐觉得这样傻等意义不大
4 小乐把响水壶放到火上，去客厅看电视，水壶响之前不再去看它了，响了再去拿壶。（异步非阻塞）
—— 小乐觉得自己聪明了。
所谓同步异步，只是对于水壶而言。
普通水壶，同步；响水壶，异步。
虽然都能干活，但响水壶可以在自己完工之后，提示小乐水开了。这是普通水壶所不能及的。
同步只能让调用者去轮询自己（情况2中），造成小乐效率的低下。
所谓阻塞非阻塞，仅仅对于小乐而言。
—— 立等的小乐，阻塞；看电视的小乐，非阻塞。
情况1和情况3中小乐就是阻塞的，媳妇喊他都不知道。
虽然3中响水壶是异步的，可对于立等的小乐没有太大的意义。
所以一般异步是配合非阻塞使用的，这样才能发挥异步的效用。