图2 网络socket编程流程

网络服务器在处理并发处理方式，如上图socket处理流程所示，根据accept得到新连接以后是启用新的进程/线程还是直接在原来本进程内处理，分为如下两种方式。

一种是多进程/线程方式，这种方式为每一个新来的连接生成一个新的进程/线程来单独处理。

另外一种是IO多路复用，这种方式在一个进程/线程中维护所有的连接的socket,通过事件处理的方式依次处理所有连接上的网络事件。

多线程模型如下：

图3 多进程/线程模型

IO多路复用模型如下：

图4IO多路复用模型

2 多进程/线程模型

2.1 模型种类

在多进程/线程的模型中，根据accept在新老进程中的位置又分为两种。一种类型是accept在父进程中进行，每次accept以后，fork一个新进程或者创建一个新线程来处理新accept的连接。一种类型是父进程在listen调用以后，fork出多个进程或者创建多个线程分别进行accept.

图5accept后创建进程/线程

图6 新进程/线程里执行accept

除此以外，随着Linux3.9版本对SO_REUSEPORT模式的支持，可以允许多个进程同时绑定在同一个地址的相同的port上。所以，下面的模型也开始被NGINX支持。

图7 SO_REUSEPORT模型

2.2三种进程/线程模型比较

第一种模型accept以后再fork一个新的进程/线程处理连接，在大流量并发的情况下，主进程需要处理所有的连接请求，在大量并发新连接环境下，accept主进程会成为瓶颈。

第二种模型，解决了第一种模型中的accept瓶颈问题。每一个进程/线程都可以处理连接请求。但是又引入了“网络惊群”的问题。这个问题就是，当有一个新的连接到来时，所有准备accept的进程/线程都会被唤起去抢夺这个新的连接。为了解决这个问题，NGINX在Linux2.6以前的版本引入了一个accept mutex文件锁，各个worker进程竞争这个accetp mutex。新的连接会被持有accept mutex的进程处理。Linux2.6内核已经有效解决了“网络惊群”的问题。可以通过配置来选择是否需要accept mutex机制。

第三种模型是建立Linux 3.9内核支持SO_REUSEPORT选项的基础上。这种模型本身不再有“网络惊群”问题。通过这个选项，可以允许多个进程同时监听同一个地址和端口。当有新的连接到来时，内核会选择某一个进程进行唤起，从而在内核级别把新连接请求相对公平地分配到不同的worker进程中。

多进程/线程的处理模型，在高并发的情况下，需要大量的进程/线程来处理连接，系统负担会比较大。在多线程模型中，因为多个线程共享系统资源，一个线程出问题整个系统都会出现问题，因此，稳定性比较差。

NGINX可以通过配置文件（有的选项需要内核支持），采用第二种或者第三种模型。在第二种模型中，也可以通过配置选择是否使用accept mutex解决网络惊群问题。

3 IO多路复用模型

IO多路复用，又称为event driven IO。就是在同一个进程内同时处理多路IO,进而提高系统吞吐量。一般是通过维护一个连接池，当某个连接有数据到达，通知进程来进行数据处理。

3.1 多路复用的方式

NGINX支持多种并发连接请求，比如select,poll,epoll,kqueue(针对bsd)等等，这些请求可以通过配置文件进行选择。一般在linux上epoll的效率要比select,poll高很多。

3.2 select/poll原理

Select和Poll方式大体原理一样，区别在于Poll支持同时处理的socket数量更多。Select一般最多支持同时处理1024个连接。

图8 Select 实现数据结构

Select和Poll需要经历维护等待队列和堵塞进程两个阶段。在支持大量socket处理的场景下，效率比较低。主要原因在于select的执行过程有如下三次遍历链表操作。

1.     进程调用select/poll 时，会被加入到所有需要处理的socket的等待队列里。

2.     任何一个socket有数据到来，就会把进程唤起。同时遍历所有的socket,把进程从这些socket等待队列中移除。

3.     进程被唤起运行以后，需要再次遍历所有监听的socket,依次去判断哪些socket有数据要处理。

处理完毕以后，再次调用select时，需要重复步骤1.

这种实现方式，在处理大量连接时，socket链表会比较长，处理过程中的三次循环会非常消耗时间。

3.3 epoll原理