I/O模型

什么是 I/O、I/O 模型

所谓 I/O，无非是把数据移入或移出缓冲区。

进程执行 I/O 操作，归根结底，是向操作系统发出请求，让它要么把缓冲区里的数据清空 （写），要么用数据把缓冲区填满（读）。进程使用这一机制处理所有数据的进出操作，而操作系统内部处理这一任务的机制，就是 I/O 模型。

io.png

对应上图来说，假定应用 A、B 通过 TCP/IP 进行数据交换，那么应用A首先要将数据写入TCP发送缓冲区并等待内核进行处理（第一步），随后内核将数据拷贝一份并通过网卡对外发送（第二步），经过网络传输后数据来到应用B所在系统的内核缓冲区，接着拷贝到TCP接收缓冲区，最后应用B读取数据（第三步），反之亦然。

I/O 模型

阻塞与非阻塞

让我们把视角聚焦到第一步，由于缓冲区大小是有限制的，进程不可能无限制地往缓冲区里写入数据。如果应用A在写数据时发现缓冲区已满，那么内核要如何处理应用A的写请求呢？是直接告诉它缓冲区已满，还是让它等在那直到腾出空间？同样的问题也出现在第三步，应用B读取数据时发现缓冲区里没有它的数据，内核是直接告诉它没有数据还是干脆让它一直等着，直到有数据过来再交给它？

通俗的来说，如果应用需要一直等到条件满足才能执行操作，就是阻塞式 I/O ；而如果应用在条件不满足时立即退出，后续通过轮询等手段发起重试，自然就是非阻塞 I/O 了。

1. BIO图解：

   
   BIO.png

2. NIO图解：

   
   NIO.png

I/O 复用

了解了 NIO 的工作流程，我们继续来看看 I/O 多路复用产生的原因和思路，这次我们把视角放到第三步，即应用B从TCP缓冲区中读取数据这个环节。

考虑到应用B不仅仅对应用A提供服务，假设有1000个应用在向应用B发送数据吧，极端情况下应用B可能需要同时读取1000份数据。简单的解决方案可能是为每个读请求创建一个线程，然后在线程内部轮询内核数据是否准备好，并在数据准备好后进行处理。这当然可以解决问题，可是线程的数量也是受限的，同时大量的线程在调度时会产生极大的上下文切换开销，得不偿失。

另一种方案是由一个线程监控多个读请求，它本身不进行数据处理，只负责轮询内核数据是否准备好了，一旦内核说有数据了就分配其它线程进行读取和处理。注意这里其它线程，也就是工作线程是可以池化的，这样就大大减少了线程资源的创建。

IOMultiplexing.png

信号驱动

I/O 复用模型中监控线程必须持续轮询内核，很多时候轮询可能是低效的，比如一段时间内确实没有谁给应用B发送数据。有没有一种方式不需要进行轮询，只需要发出一个读请求，内核在数据准备好后直接进行通知呢？这就是信号驱动I/O模型。

SIO.png

异步 I/O

其实不管是I/O复用模型还是信号驱动I/O模型，都需要经历两个阶段：

1. 问内核要数据，I/O复用模型中是轮询，信号驱动I/O模型中是建立信号联系，这一步是非阻塞的

2. 读已经就绪的数据，涉及到将数据从内核缓冲区拷贝到TCP接收缓冲区，这一步是阻塞的

那有大神就在思考了，第2步能不能也不阻塞呢？也就是说，我们只管问内核要数据，然后就做甩手掌柜，内核在数据准备就绪后自己把它复制到TCP接收缓冲区，然后再通知我们，我们直接就可以处理数据了，岂不美哉。这就是异步I/O模型。

AIO.png

补充

同步和异步

经过上面的介绍，阻塞与非阻塞想必大家都很清楚了，这里多说一下同步和异步。同步I/O模型中，我们需要主动发起数据读取，内核作为接收方给我们返回数据；而异步I/O模型是内核作为发起方对我们进行通知，我们作为接收方去查收数据。

select/poll 和 epoll

• select/poll 的几大缺点：

  1. 每次调用 select，都需要把 fd 集合从用户态拷贝到内核态，这个开销在 fd 很多时会很大

  2. 同时每次调用 select 都需要在内核遍历传递进来的所有 fd，这个开销在 fd 很多时也很大

  3. select 支持的文件描述符数量太小了，默认是1024

• epoll（Linux 2.6内核正式引入，可被用于代替 POSIX select 和 poll 系统调用）：

  1. 内核与用户空间共享一块内存（零拷贝）

  2. 通过回调解决遍历问题

  3. fd 没有限制，可以支撑10万连接