服务器处理连接的架构演变

[[399160]]

本文转载自微信公众号「编程杂技」，服务作者theanarkh。器处转载本文请联系编程杂技公众号。理连

服务器是接的架构现代软件中非常重要的一个组成。服务器，演变顾名思义，服务是器处提供服务的组件 ，那么既然提供服务 ，理连那就要为众人所知，接的架构不然大家怎么能找到服务呢?演变就像我们想去吃麦当劳一样
，那我们首先得知道他在哪里。免费模板服务所以，器处服务器很重要的理连一个属性就是需要发布服务信息，服务信息包括提供的接的架构服务和服务地址  。这样大家才能知道需要什么服务的演变时候，去哪里找
。

对应到计算机中，服务地址就是ip+端口 ，但是ip和端口不容易记 ，不利于使用，源码库所以又设计出DNS协议 ，这样我们就可以使用域名来访问一个服务，DNS服务会根据域名解析出ip。解决了寻找服务的问题后，接下来的问题就是服务器如何高效地处理连接。本文介绍服务器处理连接的架构演进 。

一个基于tcp协议的服务器，基本的流程如下(本文皆为伪代码)。

复制int socketfd = socket();  bind(socketfd);  listen(socketfd);  1.2.3.

执行完以上步骤 ，一个服务器正式开始服务 。高防服务器下面我们看一下基于上面的模型，分析各种各样的处理方法。

1 单进程accept

复制while(1) {     int socketForCommunication  = accept(socketfd);    handle(socketForCommunication);  }  1.2.3.4.

上面是一个服务器处理连接最朴素的模型，处理逻辑就是服务器不断地调用accept摘下完成三次握手的连接，然后处理
，如果没有连接则服务器阻塞
 。我们看看这种模式的处理过程。假设有n个请求到来。那么socket的服务器租用结构是 。

这时候进程从accept中被唤醒。然后拿到一个新的socket用于通信 。结构变成

很多同学都了解三次握手是什么 ，但是可能很少同学会深入思考或者看他的实现。众所周知 ，一个服务器启动的时候，会监听一个端口，其实就是新建了一个socket。源码下载那么如果有一个连接到来的时候，我们通过accept就能拿到这个新连接对应的socket。那么这个socket和监听的socket是不是同一个呢?其实socket分为监听型和通信型的。

表面上，服务器用一个端口实现了多个连接 ，但是这个端口是用于监听的，底层用于和客户端通信的香港云服务器其实是另一个socket 。所以每一个连接过来，负责监听的socket发现是一个建立连接的包(syn包)，他就会生成一个新的socket与之通信(accept的时候返回的那个)。监听socket里只保存了他监听的ip和端口
，通信socket首先从监听socket中复制ip和端口 ，然后把客户端的ip和端口也记录下来 
，当下次收到一个数据包的时候，操作系统就会根据四元组从socket池子里找到该socket，从而完成数据的处理。

言归正传 ，串行这种模式如果处理的过程中有调用了阻塞api，比如文件io，就会影响后面请求的处理。可想而知
，效率是有多低。而且并发量比较大的时候，监听socket对应的队列很快就会被占满(已完成连接队列有一个最大长度)。这是最简单的模式，虽然服务器的设计中肯定不会使用这种模式 ，但是他让我们了解了一个服务器处理请求的整体过程。

2 多进程模式

串行模式中 ，所有请求都在一个进程中排队被处理
，这是效率低下的原因 。这时候我们可以把请求分给多个进程处理来提供效率，因为在串行处理的模式中，如果有文件io操作，他就会阻塞主进程 ，从而阻塞后续请求的处理，在多进程的模式中，即使一个请求阻塞了进程 ，那么操作系统会挂起该进程，接着调度其他进程执行，那么其他进程就可以执行新的任务。多进程模式下分为几种。

2.1 主进程accept，子进程处理请求

这种模式下，主进程负责摘取已完成连接的节点 ，然后把这个节点对应的请求交给子进程处理 ，逻辑如下。

复制while(1) {          var socketForCommunication = accept(socket);         if (fork() > 0) {  // 忽略出错处理            continue;            // 父进程负责accept       } else {              // 子进程           handle(socketForCommunication);          exit();        }     }  1.2.3.4.5.6.7.8.9.10.11.

这种模式下 ，每次来一个请求 ，就会新建一个进程去处理。这种模式比串行的稍微好了一点，每个请求独立处理
，假设a请求阻塞在文件io ，那么不会影响b请求的处理
，尽可能地做到了并发 。他的瓶颈就是系统的进程数有限
，如果有大量的请求 ，系统无法扛得住
。再者 ，进程的开销很大 。对于系统来说是一个沉重的负担
。

2.2 子进程accept

这种模式不是等到请求来的时候再创建进程。而是在服务器启动的时候 ，就会创建多个进程。然后多个进程分别调用accept。这种模式的架构如下。

复制for (let i = 0 ; i < 进程个数; i++) {         if (fork() > 0) {             // 父进程负责监控子进程      } else {             // 子进程处理请求          while(1) {                 var socketForCommunication = accept(socket);                handle(socketForCommunication);            }        }    }  1.2.3.4.5.6.7.8.9.10.11.

这种模式下多个子进程都阻塞在accept。如果这时候有一个请求到来 ，那么所有的子进程都会被唤醒 ，但是首先被调度的子进程会首先摘下这个请求节点 。后续的进程被唤醒后可能会遇到已经没有请求可以处理。又进入睡眠，进程被无效唤醒，这是著名的惊群现象
。架构如下。

改进方式就是在accpet之前加锁
，拿到锁的进程才能进行accept 。这样就保证了只有一个进程会阻塞在accept ，nginx解决了这个问题 。但是新版操作系统已经在内核层面解决了这个问题
 。每次只会唤醒一个进程。

2.3 进程池模式

进程池模式就是服务器启动的时候 ，预先创建一定数量的进程 ，但是这些进程是worker进程。他不负责accept请求。他只负责处理请求。主进程负责accept，他把accept返回的socket交给worker进程处理 。模式如下

这种模式的逻辑如下

复制let fds = [[], [], []…进程个数];    let process = [];    for (let i = 0 ; i < 进程个数; i++) {         // 创建管道用于传递文件描述符  5.      socketpair(fds[i]);        let pid;        if (pid = fork() > 0) {             // 父进程          process.push({ pid, 其他字段});        } else {             let index = i;            // 子进程处理请求          while(1) {                 // 从管道中读取文件描述符              var socket = read(fd[index][1]);                // 处理请求              handle(socket);            }        }    }    for (;;) {         var newSocket = accept(socket);        // 找出处理该请求的子进程      let i = findProcess();        // 传递文件描述符      write(fds[i][0], newSocket);    }  1.2.3.4.5.6.7.8.9.10.11.12.13.14.15.16.17.18.19.20.21.22.23.24.25.26.

使用进程池的模式时，主进程负责accept，然后把请求交给子进程处理 ，但是和多进程的模式2.1相比，进程池模式相对比较复杂，因为在多进程模式2.1中 ，当主进程收到一个请求的时候，实时fork一个子进程，这时候 ，这个子进程会继承主进程中新请求对应的fd，所以他可以直接处理该fd对应的请求，在进程池的模式中 ，子进程是预先创建的 ，当主进程收到一个请求的时候
，子进程中是无法拿得到该请求对应的fd的 。

这时候，需要主进程使用传递文件描述符的技术把这个请求对应的fd传给子进程。一个进程其实就是一个结构体task_struct，他有一个字段记录了打开的文件描述符，当我们访问一个文件描述符的时候
，操作系统就会根据fd的值 ，从task_struct中找到fd对应的底层资源，所以主进程给子进程传递文件描述符的时候  ，传递的不仅仅是一个数字fd，因为如果仅仅这样做，在子进程中该fd可能没有对应任何资源 ，或者对应的资源和主进程中的是不一致的。而传递文件描述符
，操作系统帮我们处理了很多事情，让我们在子进程中可以通过fd访问到正确的资源，即主进程中收到的请求。

3 多线程模式

多线程模式和多进程模式是类似的，也是分为下面几种

1 主进程accept ，创建子线程处理 2 子线程accept 3 线程池

前面两种和多进程模式中是一样的
，但是第三种比较特别 ，我们主要介绍第三种
。在子进程模式时，每个子进程都有自己的task_struct ，这就意味着在fork之后
，每个进程负责维护自己的数据，而线程则不一样，线程是共享主线程(主进程)的数据的，当主进程从accept中拿到一个fd的时候 ，传给线程的话，线程是可以直接操作的
。所以在线程池模式时，架构如下。

主进程负责accept请求，然后通过互斥的方式插入一个任务到共享队列中 ，线程池中的子线程同样是通过互斥的方式 ，从共享队列中摘取节点进行处理。

4 事件驱动

现在很多服务器(nginx，Nodejs，redis)都开始使用事件驱动模式去设计
。从之前的设计模式中我们知道
，为了应对大量的请求，服务器需要大量的进程/线程。这个是个非常大的开销。而事件驱动模式 ，一般是配合单进程(单线程) ，再多的请求，也是在一个进程里处理的。但是因为是单进程，所以不适合cpu密集型
，因为一个任务一直在占据cpu的话 ，后续的任务就无法执行了。他更适合io密集的(一般都会提供一个线程池，负责处理cpu或者阻塞型的任务) 。大部分操作系统都提供了事件驱动的api。但是事件驱动在不同系统中实现不一样。所以一般都会有一层抽象层抹平这个差异。这里以linux的epoll为例子。

复制// 创建一个epoll    var epollFD = epoll_create();    /*    在epoll给某个文件描述符注册感兴趣的事件 ，这里是监听的socket，注册可读事件，即连接到来    event = {        event: 可读       fd ：监听socket       // 一些上下文    }   */    epoll_ctl(epollFD , EPOLL_CTL_ADD , socket, event);    while(1) {         // 阻塞等待事件就绪，events保存就绪事件的信息，total是个数      var total= epoll_wait(epollFD , 保存就绪事件的结构events, 事件个数, timeout);        for (let i = 0; i < total; i++) {             if (events[i].fd === 监听socket) {                 var newSocket = accpet(socket);                // 把新的socket也注册到epoll ，等待可读，即可读取客户端数据              epoll_ctl(epollFD , EPOLL_CTL_ADD , newSocket, 可读事件);            } else {                 // 从events[i]中拿到一些上下文，执行相应的回调          }        }    }  1.2.3.4.5.6.7.8.9.10.11.12.13.14.15.16.17.18.19.20.21.22.23.24.

这就是事件驱动模式的大致过程  。本质上是一个订阅/发布模式。服务器通过注册文件描述符和事件到epoll中 。epoll开始阻塞，等到epoll返回的时候，他会告诉服务器哪些fd的哪些事件触发了 。这时候服务器遍历就绪事件，然后执行对应的回调，在回调里可以再次注册新的事件 。就是这样不断驱动着 。epoll的原理其实也类似事件驱动。epoll底层维护用户注册的事件和文件描述符 。epoll本身也会在文件描述符对应的文件/socket/管道处注册一个回调。然后自身进入阻塞 。等到别人通知epoll有事件发生的时候，epoll就会把fd和事件返回给用户。

复制function epoll_wait() {         for 事件个数          // 调用文件系统的函数判断          if (事件[i]中对应的文件描述符中有某个用户感兴趣的事件发生?) {                 插入就绪事件队列            } else {                 /*               在事件[i]中的文件描述符所对应的文件/socket/管道等indeo节点注册回调 。               即感兴趣的事件触发后回调epoll，回调epoll后
，epoll把该event[i]插入               就绪事件队列返回给用户               */          }    }  1.2.3.4.5.6.7.8.9.10.11.12.13.

现在的服务器的设计中还会涉及到协程 。不过目前自己还没有看过具体的实现 ，所以还无法介绍(想了解原理的话可以看libtask这个协程库)。

5 reuseport端口复用

前面介绍的几种模式中，在处理连接的方案上，大致有下面几种

1 单进程串行处理 2 主进程接收连接
 ，分发给子进程处理。 3 子进程接收请求 ，有惊群现象
。

从串行处理到多进程/多线程模式，在处理连接上有了很大的改进 ，但是依然存在一些问题，2中的问题是，虽然有多个子进程处理请求 ，但是只有一个进程接收请求
，这是远远不够的。3中的问题是，多个子进程可以同时accept ，首先会导致惊群问题，其次，被唤醒处理连接的进程应该处理多少个连接也是一个问题，比如有10个连接，进程1被唤醒后是全部处理还是只处理一个，把剩下的留给其他进程处理呢?即使新版的内核已经解决了惊群问题，但是被唤醒的进程应该处理多少个连接的问题依然存在 ，所以如何接收请求和分发请求是两个可以改进的地方，新版linux支持reuseport特性后，使得处理请求的模式有了很大的改善。r

euseport之前 ，一个socket是无法绑定到同一个地址的 ，通常的做法是主进程bind后，fork子进程，然后子进程listen。但是共享的是同一个socket。reuseport特性支持多个socket绑定到同一个地址，当连接到来时，操作系统会根据地址信息找到一组socket
 ，然后根据策略选择一个socket，然后唤醒阻塞在该socket的进程。这样之前多进程共享socket的模式下 ，被唤醒的进程应该处理多少个请求的问题也解决了，因为reuseport模式中 ，每个进程一个socket 
，对应一个请求队列，内核会把请求分发到各个socket中，被socket唤醒的进程只处理自己的监听socket下的连接就行，架构如下

这种模式在底层解决了多进程请求分发的问题 ，提高了处理请求的效率同时实现了负载均衡。

以上是服务器处理请求的架构演变，服务器作为对性能要求极高的软件，在技术演变的过程中，不仅应用层做了很多改进 ，操作系统内核层面也做了很多改进。