物联网高并发编程之网络编程中的I/O模型

思惟导图

互联网服务端处理网络请求的原理

首先看看一个典型互联网服务端处理网络请求的典型过程：

由上图能够看到，主要处理步骤包括：

1. 获取请求数据，客户端与服务器创建链接发出请求，服务器接受请求（1-3）；
2. 构建响应，当服务器接收完请求，并在用户空间处理客户端的请求，直到构建响应完成（4）；
3. 返回数据，服务器将已构建好的响应再经过内核空间的网络 I/O 发还给客户端（5-7）。

设计服务端并发模型时，主要有以下两个关键点：

1. 服务器如何管理链接，获取输入数据；
2. 服务器如何处理请求。

以上两个关键点最终都与操做系统的 I/O 模型以及线程(进程)模型相关。下面先详细介绍这I/O模型。

I/O 模型的基本认识

介绍操做系统的 I/O 模型以前，先了解一下几个概念：

1. 阻塞调用与非阻塞调用；
2. 阻塞调用是指调用结果返回以前，当前线程会被挂起，调用线程只有在获得结果以后才会返回；
3. 非阻塞调用指在不能马上获得结果以前，该调用不会阻塞当前线程。

二者的最大区别在于被调用方在收到请求到返回结果以前的这段时间内，调用方是否一直在等待。

阻塞是指调用方一直在等待并且别的事情什么都不作；非阻塞是指调用方先去忙别的事情。

• 同步处理与异步处理：同步处理是指被调用方获得最终结果以后才返回给调用方；异步处理是指被调用方先返回应答，而后再计算调用结果，计算完最终结果后再通知并返回给调用方。
• 阻塞、非阻塞和同步、异步的区别（阻塞、非阻塞和同步、异步其实针对的对象是不同的）：

1. 阻塞、非阻塞的讨论对象是调用者；
2. 同步、异步的讨论对象是被调用者。

• recvfrom 函数：

recvfrom 函数(经 Socket 接收数据)，这里把它视为系统调用。

• 一个输入操做一般包括两个不一样的阶段：

1. 等待数据准备好；
2. 从内核向进程复制数据。

• 对于一个套接字上的输入操做:

第一步一般涉及等待数据从网络中到达。当所等待分组到达时，它被复制到内核中的某个缓冲区。

第二步就是把数据从内核缓冲区复制到应用进程缓冲区。

实际应用程序在系统调用完成上面的 2 步操做时，调用方式的阻塞、非阻塞，操做系统在处理应用程序请求时，处理方式的同步、异步处理的不一样，能够分为 5 种 I/O 模型。

I/O模型

I/O模型1：阻塞式 I/O 模型(blocking I/O）

在阻塞式 I/O 模型中，应用程序在从调用 recvfrom 开始到它返回有数据报准备好这段时间是阻塞的，recvfrom 返回成功后，应用进程开始处理数据报。

比喻：一我的在钓鱼，当没鱼上钩时，就坐在岸边一直等。

优势：程序简单，在阻塞等待数据期间进程/线程挂起，基本不会占用 CPU 资源。

缺点：每一个链接须要独立的进程/线程单独处理，当并发请求量大时为了维护程序，内存、线程切换开销较大，这种模型在实际生产中不多使用。

I/O模型2：非阻塞式 I/O 模型(non-blocking I/O）

在非阻塞式 I/O 模型中，应用程序把一个套接口设置为非阻塞，就是告诉内核，当所请求的 I/O 操做没法完成时，不要将进程睡眠。

而是返回一个错误，应用程序基于 I/O 操做函数将不断的轮询数据是否已经准备好，若是没有准备好，继续轮询，直到数据准备好为止。

比喻：边钓鱼边玩手机，隔会再看看有没有鱼上钩，有的话就迅速拉杆。

优势：不会阻塞在内核的等待数据过程，每次发起的 I/O 请求能够当即返回，不用阻塞等待，实时性较好

缺点：轮询将会不断地询问内核，这将占用大量的 CPU 时间，系统资源利用率较低，因此通常 Web 服务器不使用这种 I/O 模型。

I/O模型3：I/O 复用模型(I/O multiplexing）

在 I/O 复用模型中，会用到 Select 或 Poll 函数或 Epoll 函数(Linux 2.6 之后的内核开始支持)，这两个函数也会使进程阻塞，可是和阻塞 I/O 有所不一样。

这两个函数能够同时阻塞多个 I/O 操做，并且能够同时对多个读操做，多个写操做的 I/O 函数进行检测，直到有数据可读或可写时，才真正调用 I/O 操做函数。

比喻：放了一堆鱼竿，在岸边一直守着这堆鱼竿，没鱼上钩就玩手机。

优势：能够基于一个阻塞对象，同时在多个描述符上等待就绪，而不是使用多个线程(每一个文件描述符一个线程)，这样能够大大节省系统资源。

缺点：当链接数较少时效率相比多线程+阻塞 I/O 模型效率较低，可能延迟更大，由于单个链接处理须要 2 次系统调用，占用时间会有增长。

众所周之，Nginx这样的高性能互联网反向代理服务器大获成功的关键就是得益于Epoll。

I/O模型4：信号驱动式 I/O 模型（signal-driven I/O)

在信号驱动式 I/O 模型中，应用程序使用套接口进行信号驱动 I/O，并安装一个信号处理函数，进程继续运行并不阻塞。

当数据准备好时，进程会收到一个 SIGIO 信号，能够在信号处理函数中调用 I/O 操做函数处理数据。

比喻：鱼竿上系了个铃铛，当铃铛响，就知道鱼上钩，而后能够专心玩手机。

优势：线程并无在等待数据时被阻塞，能够提升资源的利用率。

缺点：信号 I/O 在大量 IO 操做时可能会由于信号队列溢出致使无法通知。

信号驱动 I/O 尽管对于处理 UDP 套接字来讲有用，即这种信号通知意味着到达一个数据报，或者返回一个异步错误。

可是，对于 TCP 而言，信号驱动的 I/O 方式近乎无用，由于致使这种通知的条件为数众多，每个来进行判别会消耗很大资源，与前几种方式相比优点尽失。

I/O模型5：异步 I/O 模型（即AIO，全称asynchronous I/O）

由 POSIX 规范定义，应用程序告知内核启动某个操做，并让内核在整个操做（包括将数据从内核拷贝到应用程序的缓冲区）完成后通知应用程序。

这种模型与信号驱动模型的主要区别在于：信号驱动 I/O 是由内核通知应用程序什么时候启动一个 I/O 操做，而异步 I/O 模型是由内核通知应用程序 I/O 操做什么时候完成。

优势：异步 I/O 可以充分利用 DMA 特性，让 I/O 操做与计算重叠。

缺点：要实现真正的异步 I/O，操做系统须要作大量的工做。目前 Windows 下经过 IOCP 实现了真正的异步 I/O。

而在 Linux 系统下，Linux 2.6才引入，目前 AIO 并不完善，所以在 Linux 下实现高并发网络编程时都是以 IO 复用模型模式为主。

关于AOI的介绍，请见

5 种 I/O 模型总结

从上图中咱们能够看出，越日后，阻塞越少，理论上效率也是最优。

这五种 I/O 模型中，前四种属于同步 I/O，由于其中真正的 I/O 操做(recvfrom)将阻塞进程/线程，只有异步 I/O 模型才与 POSIX 定义的异步 I/O 相匹配。