I/O多路复用+高性能网络模式

前言：
本篇文章将介绍客户端-服务端之间从最简单的Socket模型到I/O多路复用的模式演变过程，并介绍Reactor和Proactor两种高性能网络模式

文章内容摘自：小林Coding
I/O多路复用+高性能网络模式

传统Socket模型

服务端流程：
1.创建Socket套接字
2.使用bind函数绑定ip地址和端口
3.listen函数监听端口让套接字变成可以被动连接的状态，此时服务端会被阻塞，等待连接的到来
4.当连接到来时，应用程序通过accept socket接口从全连接队列中拿出一个已经连接好的socket进行网络通信
5.使用recv/send函数进行数据的收发
6.当不使用服务端时，使用close函数关闭服务端
客户端流程：
1.创建Socket套接字
2.可以选择用bind函数去绑定端口，也可以暂时不绑定.如果没有用Bind函数去指定端口的话，后续客户端会在调用Connect()函数时随机的从内核参数指定的范围内选择一个随机数作为自己的端口，流程如下：

1.判断这个随机产生的端口是不是有相同的四元组，如果没有，则直接使用这个
端口

2.如果这个端口有相同的四元组，判断是不是开启了参数tcp_tw_reuse,如果没
开启这个参数，则重新在内核参数指定范围内再选择一个端口，重复判断过程

3.如果开启了tcp_tw_reuse参数，则需要判断相同的四元组连接是不是已经进入
time_wait状态并且时间超过了1秒，如果是，则可以无缝复用这个链接，如果
不是，则重新在内核参数指定范围内再选择一个端口，重复判断过程.

3.用Connect()函数和服务端进行连接
4.用read/write函数进行数据的读写

---

传统Socket模型的性能瓶颈

传统Socket模型采用的是阻塞同步的网络模式，这里先给大家普及一下
阻塞，非阻塞，同步，异步的概念.

阻塞：当一个任务发出一个请求之后，它需要等待这个请求被正确处理完毕并返回处理结果之后，该任务才能继续执行.

非阻塞：当一个任务发出一个请求之后，它不需要等待这个请求被处理完就可以继续往后执行，并通过轮询和回调的方式来获取请求的处理结果.

同步：同步的关键词是等待，只要有等待的过程，就算同步，比如说：任务需要等待请求的处理结果之后才能继续执行，那么这就是一个同步的过程，所以说阻塞一般和同步挂钩，但是非阻塞也可以跟同步搭配，非阻塞虽然不用等待任务被处理完毕，但是可能仍然要等待数据从内核态被拷贝的用户态的一个拷贝过程.

异步：没有等待的过程，既不需要等待请求是否被处理完毕，也不需要等待数据拷贝.

---

所以对于传统的Socket的阻塞同步网络模式来说，服务端正在处理某一个客户端的网络 I/O，或者因为读写操作被阻塞住的话，那么服务端就没有办法和其他客户端正常连接，所以大大限制了服务端的性能

多进程模型

主进程负责监听连接，一旦连接完成，accept()函数会返回一个已经连接好的socket,主进程此时会通过fork函数创建若干个子进程.父进程和子进程之间通过返回值来区分.

因为fork函数几乎可以复制父进程的所有内容，所以连同把父进程的文件描述符也复制过来了，子进程可以通过文件描述符并使用已经连接好的Socket和客户端进行通信

值得注意的是，使用多进程模型，需要在使用结束时及时使用wait函数和waitpid函数获取子进程的终止状态并且释放资源，避免它们成为僵尸进程白白占用系统资源

---

多线程模型

多线程模型由线程池来实现，主要的目的就是避免线程频繁的创建和销毁带来的性能开销.

线程池的工作逻辑：

1. 创建一个固定大小的线程池，并初始化一定数量的工作线程
2. 工作线程按照循环的方式，从请求队列中拿出请求并做出处理
3. 当新请求到来时，主线程会把请求（Socket）放入请求队列中
5. 使用互斥锁，信号量等工具，让工作线程安全的从请求队列中取出请求
6. 工作线程处理好请求之后，会再次回到线程池中，再次以循环的方式等待是否
有请求可以处理
6.服务器停止工作时，主线程通知工作线程释放资源，安全关闭.

不管是多进程模型，还是多线程模型，如果一个TCP连接就要分配一个进程/线程的话，那么如果有10W个TCP连接就要分配10W个进程/线程，所以多线程模型也不是完美的

普通的线程池工作逻辑
线程池中的所有线程都是工作线程，工作线程中的空闲线程会从请求队列中取出请求并且执行
半同步/半反应堆线程（模拟Proactor模式）
除了工作线程之外，有专门负责监听和任务调度的线程存在，例如主线程
当请求到来时，主线程或者其他负责调度的线程会接受请求，然后根据任务类型分发给其他的工作线程.

1.主线程充当异步线程，监听所有socket上的事件,步骤如下：

2.当请求连接到来时，主线程接收并获得新连接好的socket

3.将该socket注册到epoll上，然后用epoll_wait等待事件到来

4.如果监听的socket有读写事件发生时，主线程从socket上接收数据，并封装成请求插入到请求队列中

---

I/O多路复用

I/O多路复用的思想就是让一个进程可以去维护多个Socket,而不是像多进程/线程模型那样，一个进程/线程只能对应一个Socket

其中select/poll/epoll是系统内核提供给用户态的多路复用系统调用函数，进程可以通过这些函数从内核中获取多个事件

select/poll

select和poll实现多路复用的方式很类似
select是把所有已连接的Socket放进一个文件描述符集合之中，然后把整个文件描述符集合拷贝到内核，由内核来检查是否有事件发生，内核会以遍历的方式遍历整个文件描述符集合然后把有事件发生的Socket标记为可读或可写，然后再把整个文件描述符集合拷贝回用户态，再次遍历文件描述符集合找到可读或可写的Socket做出处理

所以select需要经历两次遍历文件描述符集合+两次文件描述符集合的拷贝

而poll跟select很相似，只不过poll没有用Bitsmap来存储文件描述符集合，而是用动态数组+链表的方式存储文件描述符集合的，所以二者都是使用线性结构来存储Socket集合的.

---

epoll

1.epoll使用红黑树来跟踪存储所有待检测的文件描述符的，因为红黑树是一个高效的数据结构，所以它只需要O(logn)就可以完成插入查询删除操作，而select和poll就没有这样高效的数据结构，正是因为epoll中内核有了红黑树来存储socket，所以他不需要像select/poll那样，在操作时将整个文件描述符集合全部拷贝到内核，而是只需要传入一个待检测的文件描述符即可.

2.epoll采用事件驱动机制，在内核中维护了一个链表来存储所有的就绪事件，当监测的Socket上有事件发生时，内核会通过回调函数将事件加入就绪事件队列中.当用户调用epoll_wait函数获取事件时，只会返回有事件发生的文件描述符个数，而不会像select/poll那样遍历整个文件描述符集合

epoll相关函数

epoll_create()  //创建一个epoll对象

epoll_ctl()  //将待检测的socket注册到epoll上

epoll_wait()  //等待事件的到来

加入epoll之后的服务端流程

1.创建Socket套接字

2.使用bind函数绑定ip地址和端口

3.用listen监听端口

4.将服务端socket通过epoll_ctl注册到epoll上

5.epoll_wait等待连接到来，当连接到来时，用accept函数获取已经连接
好的socket

6.将已经连接好的socket注册到epoll上

7.使用epoll_wait函数等待事件的到来

水平触发和边缘触发

边缘触发
当监测的Socket上有可读事件发生时，服务端会在epoll_wait上唤醒一次，即使进程没有主动调用read函数进行读操作，服务端也仅仅会唤醒一次，并且尽可能一次性的将内核缓冲区的数据读完

因为边缘触发只有一次通知，所以服务端会尽可能的多读写数据，以免浪费了读写数据的机会，并且是以循环的方式在文件描述符上读写数据的，所以文件描述符此时必须是非阻塞的，否则就会被阻塞在读写函数上，程序就没办法继续进行下去了.

水平触发
当被监控的Socket上有可读事件发生时，服务端会不断的从epoll_wait上唤醒，并读取内核缓冲区的数据直到内核缓冲区的数据被读完

当内核通知文件描述符是可读写时，接下来还要继续检查它的状态，确保它依然是可读或者可写的，所以没必要像边缘触发那样一次性读写过多的数据.

---

Reactor模式和Proactor模式

Reactor
是一种非阻塞同步网络模式，它感知的就绪的网络事件，当感知到有事件发生时，应用进程会主动的使用write/read函数进行读写操作，将socket缓冲区中的数据读入应用进程的内存之中，这个过程是同步的，读完之后再进行数据的处理.

Proactor
是一种异步网络模式，它感知的是已完成的网络事件，当发出一个异步请求时，需要提供缓冲区的地址，然后系统内核就会帮助我们完成读写操作，这里的读写操作全部都是由操作系统来完成的，而不是像Reactor那样是由应用进程主动调用read/write函数完成的，在操作系统完成读写操作之后，交给应用进程处理

总结
Reactor模式可以理解为：
当事件到来时，操作系统通知应用进程，由应用进程处理
Proactor模式可以理解为：
当事件到来时，操作系统处理，处理完了通知应用进程