一、用户空间和内核空间

  以Linux系统为例，ubuntu和CentOS是Linux的两种比较常见的发行版，任何Linux发行版，其系统内核都是Linux。我们在发行版上操作应用，如Redis、Mysql等其实是无法直接执行访问计算机硬件(如cpu，内存，网卡等)的操作的，所以需要借助发行版去访问内核，再通过内核去访问计算机硬件。

  那么问题来了，我们想要用户的应用来访问，计算机就必须要对外暴露一些接口，从而实现对内核的操控，但是内核本身上来说也是一个应用，所以他本身也需要一些内存，cpu等设备资源，用户应用本身也在消耗这些资源，如果不加任何限制，用户随意地去操作系统资源，就有可能导致一些冲突，甚至有可能导致系统出现无法运行的问题，所以把用户和内核隔离开是十分有必要的。因此，用户空间和内核空间应运而生。
  在Linux系统中，权限分成两个等级，0和3，用户空间只能执行受限的命令(Ring3)，而且不能直接调用系统资源，而内核可以执行特权命令(Ring0)，调用一切系统资源。所以一般情况下，用户的操作是运行在用户空间，而内核运行的数据是在内核空间的，而某些情况下，一个应用程序需要去调用一些特权资源，其就要去调用一些内核空间的操作，所以此时他需要在用户态和内核态之间进行切换。

注：
Linux系统为了提高IO效率，在用户空间和内核空间都加入缓冲区。
写数据时，要把用户缓冲区的数据拷贝到内核缓冲区，然后写入设备；
读数据时，要从设备读取数据到内核缓冲区，然后拷贝到用户缓冲区。

上图是用户应用读取数据时的流程图，其中用户在两个阶段需要等待：

• 驱动程序从硬件上读取数据，内核会将读取到的数据写入到内核缓冲区
• 将内核缓冲区的数据拷贝到用户缓冲区中

这也是不同网络模型主要优化的两个方面，在理解了上述流程后，我们正式进入到网络模型的介绍中！

二、网络模型

1. 阻塞IO(Blocking IO)

  用户读取数据时，会先发起一个recvform命令，尝试从内核上加载数据，如果内核没有数据，那么用户就会阻塞等待，此时内核会去从硬件上读取数据，内核读取数据之后，再把数据拷贝到用户空间，并且返回OK，整个过程，都是阻塞等待的，这就是阻塞IO。

总结：
顾名思义，阻塞IO就是两个阶段都必须阻塞等待。

阶段一：

• 用户进程尝试读取数据（比如网卡数据）
• 此时数据尚未到达，内核需要等待数据
• 此时用户进程也处于阻塞状态

阶段二：

• 数据到达并拷贝到内核缓冲区，代表已就绪
• 将内核数据拷贝到用户缓冲区
• 拷贝过程中，用户进程依然阻塞等待
• 拷贝完成，用户进程解除阻塞，处理数据

2. 非阻塞IO(Nonblocking IO)

  用户读取数据时，会先发起一个recvform命令，尝试从内核上加载数据，如果内核没有数据，会返回给用户一个异常，之后用户会再次发起请求，直至数据就绪，之后把数据拷贝到用户空间，并且返回OK，在拷贝数据到用户空间时，是阻塞等待的，这就是非阻塞IO。

总结：
非阻塞IO的recvfrom操作会立即返回结果而不是阻塞用户进程。

阶段一：

• 用户进程尝试读取数据（比如网卡数据）
• 此时数据尚未到达，内核需要等待数据
• 返回异常给用户进程
• 用户进程拿到error后，再次尝试读取
• 循环往复，直到数据就绪

阶段二：

• 将内核数据拷贝到用户缓冲区
• 拷贝过程中，用户进程依然阻塞等待
• 拷贝完成，用户进程解除阻塞，处理数据

  可以看到，在非阻塞IO模型中，用户进程在第一个阶段是非阻塞，只有第二个阶段是阻塞状态。不过虽然是非阻塞，但其采用的是再次请求，因此性能并没有得到提高。而且忙等机制会导致CPU空转，CPU使用率暴增。

3. IO多路复用(IO Multiplexing)

  无论是阻塞IO还是非阻塞IO，用户应用在一阶段都需要调用recvfrom来获取数据，差别在于无数据时的处理方案，我们前面已经分析过，这两种方案性能都不好。
  而在单线程情况下，只能依次处理IO事件，如果正在处理的IO事件恰好未就绪(数据不可读或不可写)，线程就会被阻塞，这会导致所有IO事件都必须等待(即使已经有就绪的事件)，性能自然会很差。我们知道，Redis的网络模型就是IO多路复用，那么IO多路复用有何优化呢？
  在IO多路复用网络模型中，用户去读取数据时，不再去直接调用recvfrom了，而是调用select函数，select函数会将需要监听的数据交给内核，由内核去检查这些数据是否就绪了，如果说这个数据就绪了，就会通知应用程序数据就绪，然后来读取数据，再从内核空间把数据拷贝给用户空间，完成数据处理，如果所有的数据都没就绪，此时再进行等待。

总结：
  文件描述符(File Descriptor)：简称FD，是一个从0开始的无符号整数，用来关联Linux中的一个文件。在Linux中一切皆文件，例如常规文件、视频、硬件设备等，当然也包括网络套接字(Socket)。
  IO多路复用利用单个线程来同时监听多个FD，并在某个FD可读、可写时得到通知，从而避免无效的等待，充分利用CPU资源。

阶段一：

• 用户进程调用select，指定要监听的FD集合
• 核监听FD对应的多个Socket
• 任意一个或多个Socket数据就绪则返回readable
• 此过程中用户进程阻塞

阶段二：

• 用户进程找到就绪的Socket
• 依次调用recvfrom读取数据
• 内核将数据拷贝到用户空间
• 用户进程处理数据

此外，在监听FD的方式、通知的方式有多种实现，常见的有：

• select
• poll
• epoll

  其中select和poll相当于是当被监听的数据准备好之后，他会把你监听的FD整个数据都发给你，你需要到整个FD中去找哪些是就绪的，需要通过遍历的方式，所以性能也并不是那么好。而epoll，相当于数据准备好了之后，会把准备好的数据直接发给你，省去了遍历的动作，因此性能最好。

4. 信号驱动IO(Signal Driven IO)

  信号驱动IO是与内核建立SIGIO的信号关联并设置回调，当内核有FD就绪时，会发出SIGIO信号通知用户，期间用户应用可以执行其它业务，无需阻塞等待。

总结：
  当有大量IO操作时，信号较多，SIGIO处理函数不能及时处理可能导致信号队列溢出，而且内核空间与用户空间的频繁信号交互性能也较低。

阶段一：

• 用户进程调用sigaction，注册信号处理函数
• 内核返回成功，开始监听FD
• 用户进程不阻塞等待，可以执行其它业务
• 当内核数据就绪后，回调用户进程的SIGIO处理函数

阶段二：

• 收到SIGIO回调信号
• 调用recvfrom读取数据
• 内核将数据拷贝到用户空间
• 用户进程处理数据

5. 异步IO(Asynchronous IO)

  异步IO，不仅仅是用户态在试图读取数据后不阻塞，而且当内核的数据准备完成后，也不会阻塞。

总结：
  异步IO会由内核将所有数据处理完成后，包含将数据写入到用户空间中，才算完成，所以性能极高，不会有任何阻塞，全部都由内核完成。可以看到，异步IO模型中，用户进程在两个阶段都是非阻塞状态。不过其在高并发的情况下也存在一些问题，比如，用户应用发送了过多的IO请求，因为IO操作比较费时，那么在内核空间可能会积累很多IO任务，从而导致系统因为内存占用过多而崩溃。所以，异步IO需要采用合适的限流措施。

三、对比