概述和问题
当TCP客户同事处理两个输入：标准输入和TCP套接字。我们遇到的问题是就在客户阻塞于（标准输入上的）
fgets调用期间，服务器进程会被杀死。服务器TCP虽然正确地给TCP发送了一个FIN，但是既然客户进程正阻塞于标准输入读入的过程，它将看不到这个EOF，知道套接字读时为止（可能已过了很长时间）。这样的进程需要一种预先告知内核的能力，使得内核一旦发现进程指定的一个或者多个I/O条件就绪（也就是说输入已准备好被读取，或者描述符已能承接更多的输入），它就通知进程。这个能力成为I/O复用。
通俗来说地讲 I/O多路复用，又称事件驱动，多个描述符的I/O操作都能在一个线程内并发交替地顺序完成，这里的“复用”是指复用同一个线程
一、I/O模型
当我们在复杂的服务器上编程时会遇到很多问题，其中I/O问题就是其中的一个，所以我们要熟知Linux中各种I/O模型。
- 阻塞式I/O
- 非阻塞式I/O
- I/O复用（select，poll和epoll）
- 信号驱动式I/O（SIGIO）
- 异步I/O（POSIX的aio_系列函数）
1、阻塞式I/O
当前最流行的I/O模型是阻塞式I/O模型，在默认情境下，所有套接字都是阻塞的包括accept、send、recv和connect，针对于阻塞I/O执行的系统调用可能因为无法立即完成而被系统挂起，直到等待的事件发生为止。
2、非阻塞I/O
当我们在创建socket的时候默认是阻塞的。我们可以给socket系统调用的第二个参数传递SOCK_NONBLOCK标志，或者通过fcntl系统调用的F_SETFL命令，将其设置为非阻塞的。针对于非阻塞I/O执行的系统调用则总是立即返回，而不管事件是否已经发生。如果事件没有立即返回，这些系统调用就返回-1，和出错的情况一样。此时我们必须根据errno来区分这两种情况。对于accept、send和recv而言。事件未发生时errno通常被设置为EAGAIN（再来一次）。或者EWOULDBLOCK（期望阻塞），对于connect而言，errno则被设置为EINPROGRESS（处理中）。
很显然只有在时间已经发生了情况下操作非阻塞I/O可以提高程序的效率。因此非阻塞I/O通常要和其他I/O通知机制一起使用，比如I/O复用和SIGIO信号。
3、IO复用模型
I/O复用是最常使用的I/O通知机制，它指的是，应用程序通过I/O复用函数向内核注册一组事件，内核通过I/O复用函数把其中就绪的事件通知给应用程序。Linux上常用的I/O复用函数本身是阻塞的，它们能提高程序效率的原因在于它们具有同时监听多个I/O时间的能力。
4、信号驱动I/O模型
我们也可以用信号，让内核在描述符就绪时发送SIGNO信号通知我们，
5、异步I/O模型
从理论上说，阻塞I/O、I/O复用和信号驱动I/O都是同步I/O模型。
因为在这三种I/O模型中，I/O的读写操作，都是在I/O事件发生之后，由应用程序来完成的。而在POSIX规范所定义的异步I/O模型则不同。对异步I/O而言，用户可以直接对I/O执行读写操作，这些操作告诉内核用户读写缓冲区的位置，以及I/O操作完成之后内核通知应用程序的方式。异步I/O的读写操作总是立即返回，而不论I/O是否阻塞的，因为真正的读写操作已经由内核接管。也就是说，同步I/O模型要求用户代码自行执行I/O操作（ 将数据从内核缓冲区读入用户缓冲区，或将数据从用户缓冲区写入内核缓冲区），而异步I/O机制则由内核来执行I/O操作（数据在内核缓冲区和用户缓冲区之间的移动是由内核在“后台”完成的）。可以这么认为，同步I/O向应用程序通知的是I/O就绪事件，而异步I/O向应用程序通知的是I/O完成事件。Linux环境下，aio.h头文件中定义的函数提供了对异步I/O的支持。
同步I/O模型通常用于实现Reactor模型，而异步I/O模型则用于实现Proactor模型，有关Reactor模型的内容，在我博客内有一篇文章《Reactor模式详解》专门讲解。
6、模型比较
