Linux服务器网络开发模型

一： 典型的Apache模型（Process Per Connection，简称PPC），TPC（Thread PerConnection）模型，select 和epoll

1.2  select 和epoll

假设你在大学中读书,要等待一个朋友来访,而这个朋友只知道你在A号楼,但是不知道你具体住在哪里,于是你们约好了在A号楼门口见面.如果你使用的阻塞IO 模型来处理这个问题,那么你就只能一直守候在A号楼门口等待朋友的到来,在这段时间里你不能做别的事情,不难知道,这种方式的效率是低下的.现在时代变化了,开始使用多路复用IO模型来处理这个问题.你告诉你的朋友来了A号楼找楼管大妈,让她告诉你该怎么走.这里的楼管大妈扮演的就是多路复用IO的角色。

解释select和epoll模型的工作方式：
select版大妈做的是如下的事情:比如同学甲的朋友来了,select版大妈比较笨,她带着朋友挨个房间进行查询谁是同学甲,你等的朋友来了。如果每到来一个朋友楼管大妈都要全楼的查询同学,那么处理的效率必然就低下了,过不久楼底就有不少的人了。
epoll版大妈就比较先进了,她记下了同学甲的信息,比如说他的房间号,那么等同学甲的朋友到来时,只需要告诉该朋友同学甲在哪个房间即可,不用自己亲自带着人满大楼的找人了。epoll大妈可以不用吹灰之力就可以定位到同学甲。一看就很明白 epoll和select 模型的区别了吧。

在Linux内核中，select所用到的FD_SET是有限的，即内核中有个参数__FD_SETSIZE定义了每个FD_SET的句柄个数，在内核源码中 /usr/include/linux/posix_types.h 中
#undef __FD_SETSIZE
#define __FD_SETSIZE    1024
如果想要同时检测1025个句柄的可读状态或 可写状态 ，select是不能实现的。在内核中实现select是使用轮询方法，即每次检测都会遍历所有FD_SET中的句柄，显然，select函数的执行时间与 FD检测的句柄数越多就会越费时。

epoll是多路复用IO(I/O Multiplexing) 中的一种方式,仅用于linux2.6以上内核。而epoll模型它所支持的FD上限是最大可以打开文件的数目，这个数字一般远大于2048,举个例子,在1GB内存的机器上大约是10万左右，具体请查看：cat /proc/sys/fs/file-max ,这个数目和系统内存关系很大。
传统的select/poll另一个致命弱点就是当你拥有一个很大的socket集合，不过由于网络延时，任一时间只有部分的socket是"活跃"的，但是select/poll每次调用都会线性扫描全部的集合，导致效率呈现线性下降。但是epoll不存在这个问题，它只会对"活跃"的socket进行操作---这是因为在内核实现中epoll是根据每个fd上面的callback函数实现的。那么，只有"活跃"的socket才会主动的去调用 callback函数，其他idle状态socket则不会，在这点上，epoll实现了一个"伪"AIO，因为这时候推动力在os内核。在一些 benchmark中，如果所有的socket基本上都是活跃的---比如一个高速LAN环境，epoll并不比select/poll有什么效率，相反，如果过多使用epoll_ctl,效率相比还有稍微的下降。但是一旦使用idle connections模拟WAN环境,epoll的效率就远在select/poll之上了。

epoll有两种工作模式:Edge Triggered (ET)、Level Triggered (LT) 
LT(level triggered)是缺省的工作方式，并且同时支持block和no-block socket.在这种做法中，内核告诉你一个文件描述符是否就绪了，然后可以对这个就绪的fd进行IO操作。如果你不作任何操作，内核还是会继续通知你的，所以，这种模式编程出错误可能性要小一点。传统的select/poll都是这种模型的代表。
ET (edge-triggered)是高速工作方式，只支持no-block socket。在这种模式下，当描述符从未就绪变为就绪时，内核通过epoll告诉你。然后它会假设你知道文件描述符已经就绪，并且不会再为那个文件描述符发送更多的就绪通知，直到你做了某些操作导致那个文件描述符不再为就绪状态了(比如，你在发送，接收或者接收请求，或者发送接收的数据少于一定量时导致了一个EWOULDBLOCK 错误）。

select模型，当有I/O事件到来时，select通知应用程序有事件到了快去处理，而应用程序必须轮询所有的FD集合，测试每个FD是否有事件发生，并处理事件；代码像下面这样：

int res = select(maxfd+1, &readfds, NULL, NULL, 120);

if(res > 0)

{

    for(int i = 0; i < MAX_CONNECTION; i++)

    {

        if(FD_ISSET(allConnection[i],&readfds))

        {

            handleEvent(allConnection[i]);

        }

    }

}

// if(res == 0) handle timeout, res < 0 handle error

Epoll不仅会告诉应用程序有I/0事件到来，还会告诉应用程序相关的信息，这些信息是应用程序填充的，因此根据这些信息应用程序就能直接定位到事件，而不必遍历整个FD集合。

intres = epoll_wait(epfd, events, 20, 120);

for(int i = 0; i < res;i++)

{

    handleEvent(events[n]);

}

二  linux  io 模型

2.1  阻塞型的网络编程接口

初学Socket编程，大家都是从 listen()、send()、recv() 等接口开始的。使用这些接口可以实现一个非常简单的网络通讯程序，如下图所示。

 

    在这个线程 / 时间图例中，黑色的粗线代表线程的等待时间，或者说成是被阻塞的。我们注意到accept()、send()、recv()这几个接口在调用时都发生了阻塞。实际上，在缺省状态下，socket 接口都是阻塞型的。这意味着当一个socket调用不能立即完成时，进程或线程将进入睡眠状态，等待操作完成。这给网络编程带来了一个很大的问题，如在调用 send() 的同时，线程将被阻塞，在此期间，线程将无法执行任何运算或响应任何的网络请求。这给多客户机、多业务逻辑的网络编程带来了挑战。要解决这个问题，我们自然而然的想到多线程。

2.2 多线程/多进程的服务器程序

应对多客户机的网络应用，最简单的解决方式是在服务器端使用多线程（或多进程）。多线程（或多进程）的目的是让每个连接都拥有独立的线程（或进程），这样任何一个连接的阻塞都不会影响其他的连接。

    具体使用多进程还是多线程，并没有一个特定的模式。传统意义上，进程的开销要远远大于线程，所以，如果需要同时为较多的客户机提供服务，则不推荐使用多进程；如果单个服务执行体需要消耗较多的 CPU 资源，譬如需要进行大规模或长时间的数据运算或文件访问，则进程较为安全。在Unix/Linux环境中，使用 pthread_create () 创建新线程，fork() 创建新进程。

    我们假设对上述的服务器 / 客户机模型，提出更高的要求，即让服务器同时为多个客户机提供一问一答的服务。于是有了如下的模型。

 

    在上述的线程 / 时间图例中，主线程持续等待客户端的连接请求，如果有连接，则创建新线程，并在新线程中提供为前例同样的问答服务。很多初学者可能不明白为何一个 socket 可以 accept 多次。实际上，socket 的设计者可能特意为多客户机的情况留下了伏笔，让 accept() 能够返回一个新的 socket。下面是 accept 接口的原型：

输入参数 s 是从 socket()，bind() 和 listen() 中沿用下来的 socket 句柄值。执行完 bind() 和 listen() 后，操作系统已经开始在指定的端口处监听所有的连接请求，如果有请求，则将该连接请求加入请求队列。调用 accept() 接口正是从 socket s 的请求队列抽取第一个连接信息，创建一个与 s 同类的新的 socket 返回句柄。新的 socket 句柄即是后续 read() 和 recv() 的输入参数。如果请求队列当前没有请求，则 accept() 将进入阻塞状态直到有请求进入队列。

    上述多线程的服务器模型似乎完美的解决了为多个客户机提供问答服务的要求，但其实并不尽然。如果要同时响应成百上千路的连接请求，则无论多线程还是多进程都会严重占据系统资源，降低系统对外界响应效率，而线程与进程本身也更容易进入假死状态。

    很多程序员可能会考虑使用“线程池”或“连接池”。“线程池”旨在减少创建和销毁线程的频率，其维持一定合理数量的线程，并让空闲的线程重新承担新的执行任务。“连接池”维持连接的缓存池，尽量重用已有的连接、减少创建和关闭连接的频率。这两种技术都可以很好的降低系统开销，都被广泛应用很多大型系统，如 websphere、tomcat 和各种数据库等。

    但是，“线程池”和“连接池”技术也只是在一定程度上缓解了频繁调用 IO 接口带来的资源占用。而且，所谓“池”始终有其上限，当请求大大超过上限时，“池”构成的系统对外界的响应并不比没有池的时候效果好多少。所以使用“池”必须考虑其面临的响应规模，并根据响应规模调整“池”的大小。

    对应上例中的所面临的可能同时出现的上千甚至上万次的客户端请求，“线程池”或“连接池”或许可以缓解部分压力，但是不能解决所有问题。

    总之，多线程模型可以方便高效的解决小规模的服务请求，但面对大规模的服务请求，多线程模型并不是最佳方案。

附：一个简单的多进程并发服务器demo

/*

==========================================================================

Purpose:

* Fork模型 TCP并发服务器 Demo

Notes:

* 采用TCP短连接,服务器将接收到从不同客户端传来的消息并打印到终端

* 编译: gcc fork.c -o fork

==========================================================================

*/

#include <netinet/in.h>    // for sockaddr_in

#include <sys/types.h>    // for socket

#include <sys/socket.h>    // for socket

#include <stdio.h>        // for printf

#include <stdlib.h>        // for exit

#include <string.h>        // for bzero

#include <unistd.h>        // for fork

#include <sys/signal.h> // for signal

#include <sys/wait.h>    // for wait

#define HELLO_WORLD_SERVER_PORT    8888 

#define LENGTH_OF_LISTEN_QUEUE 20

#define BUFFER_SIZE 1024

void reaper(int sig)

{

    int status;

    //调用wait3读取子进程的返回值,使zombie状态的子进程彻底释放

    while(wait3(&status,WNOHANG,(struct rusage*)0) >=0)

        ;

}

int main(int argc, char **argv)

{

    //设置一个socket地址结构server_addr,代表服务器internet地址, 端口

    struct sockaddr_in server_addr;

    bzero(&server_addr,sizeof(server_addr)); //把一段内存区的内容全部设置为0

    server_addr.sin_family = AF_INET;

    server_addr.sin_addr.s_addr = htons(INADDR_ANY);

    server_addr.sin_port = htons(HELLO_WORLD_SERVER_PORT);

    //创建用于internet的流协议(TCP)socket,用server_socket代表服务器socket

    int server_socket = socket(AF_INET,SOCK_STREAM,0);

    if( server_socket < 0)

    {

        printf("Create Socket Failed!");

        exit(1);

    }

    //把socket和socket地址结构联系起来

    if( bind(server_socket,(struct sockaddr*)&server_addr,sizeof(server_addr)))

    {

        printf("Server Bind Port : %d Failed!", HELLO_WORLD_SERVER_PORT); 

        exit(1);

    }

    //server_socket用于监听

    if ( listen(server_socket, LENGTH_OF_LISTEN_QUEUE) )

    {

        printf("Server Listen Failed!"); 

        exit(1);

    }

    //通知操作系统,当收到子进程的退出信号(SIGCHLD)时,执行reaper函数,释放zombie状态的进程

    (void)signal(SIGCHLD,reaper);

    while (1) //服务器端要一直运行

    {

        //定义客户端的socket地址结构client_addr

        struct sockaddr_in client_addr;

        socklen_t length = sizeof(client_addr);

        int new_server_socket;

        //接受一个到server_socket代表的socket的一个连接

        //如果没有连接请求,就等待到有连接请求--这是accept函数的特性

        //accept函数返回一个新的socket,这个socket(new_server_socket)用于同连接到的客户的通信

        //new_server_socket代表了服务器和客户端之间的一个通信通道

        //accept函数把连接到的客户端信息填写到客户端的socket地址结构client_addr中

        new_server_socket = accept(server_socket,(struct sockaddr*)&client_addr,&length);

        if ( new_server_socket < 0)

        {

            printf("Server Accept Failed!\n");

            break;

        }

        int child_process_pid = fork(); //fork()后,子进程是主进程的拷贝

        //在主进程和子进程中的区别是fork()的返回值不同.

        if(child_process_pid == 0 )//如果当前进程是子进程,就执行与客户端的交互

        {

            close(server_socket); //子进程中不需要被复制过来的server_socket

            char buffer[BUFFER_SIZE];

            bzero(buffer, BUFFER_SIZE);

            strcpy(buffer,"Hello,World! 从服务器来！");

            strcat(buffer,"\n"); //C语言字符串连接

            //发送buffer中的字符串到new_server_socket,实际是给客户端

            send(new_server_socket,buffer,BUFFER_SIZE,0);

            bzero(buffer,BUFFER_SIZE);

            //接收客户端发送来的信息到buffer中

            length = recv(new_server_socket,buffer,BUFFER_SIZE,0);

            if (length < 0)

            {

                printf("Server Recieve Data Failed!\n");

                exit(1);

            }

            printf("\n%s",buffer);

            //关闭与客户端的连接

            close(new_server_socket);//TCP短连接

            exit(0);

        }

        else if(child_process_pid > 0)     //如果当前进程是主进程 

            close(new_server_socket);    //主进程中不需要用于同客户端交互的new_server_socket

    }

    //关闭监听用的socket

    close(server_socket);

    return 0;

}

以上面临的很多问题，一定程度是 IO 接口的阻塞特性导致的。多线程是一个解决方案，还一个方案就是使用非阻塞的接口。非阻塞的接口相比于阻塞型接口的显著差异在于，在被调用之后立即返回。使用如下的函数可以将某句柄 fd 设为非阻塞状态。

下面将给出只用一个线程，但能够同时从多个连接中检测数据是否送达，并且接受数据。

 

在非阻塞状态下，recv() 接口在被调用后立即返回，返回值代表了不同的含义。如在本例中，recv() 返回值大于 0，表示接受数据完毕，返回值即是接受到的字节数；recv() 返回 0，表示连接已经正常断开；recv() 返回 -1，且 errno 等于 EAGAIN，表示 recv 操作还没执行完成；recv() 返回 -1，且 errno 不等于 EAGAIN，表示 recv 操作遇到系统错误 errno。

可以看到服务器线程可以通过循环调用 recv() 接口，可以在单个线程内实现对所有连接的数据接收工作。

但是上述模型绝不被推荐。因为，循环调用 recv() 将大幅度推高 CPU 占用率；此外，在这个方案中，recv() 更多的是起到检测“操作是否完成”的作用，实际操作系统提供了更为高效的检测“操作是否完成“作用的接口，例如 select()。

使用 select() 接口的基于事件驱动的服务器模型

大部分 Unix/Linux 都支持 select 函数，该函数用于探测多个文件句柄的状态变化。下面给出 select 接口的原型：

FD_ZERO(int fd, fd_set* fds) 

FD_SET(int fd, fd_set* fds)

FD_ISSET(int fd, fd_set* fds)

FD_CLR(int fd, fd_set* fds)

int select(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds, struct timeval *timeout)

这里，fd_set 类型可以简单的理解为按 bit 位标记句柄的队列，例如要在某 fd_set 中标记一个值为 16 的句柄，则该 fd_set 的第 16 个 bit 位被标记为 1。具体的置位、验证可使用 FD_SET、FD_ISSET 等宏实现。在 select() 函数中，readfds、writefds 和 exceptfds 同时作为输入参数和输出参数。如果输入的 readfds 标记了 16 号句柄，则 select() 将检测 16 号句柄是否可读。在 select() 返回后，可以通过检查 readfds 有否标记 16 号句柄，来判断该“可读”事件是否发生。另外，用户可以设置 timeout 时间。

下面将重新模拟上例中从多个客户端接收数据的模型。

 

上述模型只是描述了使用 select() 接口同时从多个客户端接收数据的过程；由于 select() 接口可以同时对多个句柄进行读状态、写状态和错误状态的探测，所以可以很容易构建为多个客户端提供独立问答服务的服务器系统。

 

这里需要指出的是，客户端的一个 connect() 操作，将在服务器端激发一个“可读事件”，所以 select() 也能探测来自客户端的 connect() 行为。

上述模型中，最关键的地方是如何动态维护 select() 的三个参数 readfds、writefds 和 exceptfds。作为输入参数，readfds 应该标记所有的需要探测的“可读事件”的句柄，其中永远包括那个探测 connect() 的那个“母”句柄；同时，writefds 和 exceptfds 应该标记所有需要探测的“可写事件”和“错误事件”的句柄 ( 使用 FD_SET() 标记 )。

作为输出参数，readfds、writefds 和 exceptfds 中的保存了 select() 捕捉到的所有事件的句柄值。程序员需要检查的所有的标记位 ( 使用 FD_ISSET() 检查 )，以确定到底哪些句柄发生了事件。

上述模型主要模拟的是“一问一答”的服务流程，所以，如果 select() 发现某句柄捕捉到了“可读事件”，服务器程序应及时做 recv() 操作，并根据接收到的数据准备好待发送数据，并将对应的句柄值加入 writefds，准备下一次的“可写事件”的 select() 探测。同样，如果 select() 发现某句柄捕捉到“可写事件”，则程序应及时做 send() 操作，并准备好下一次的“可读事件”探测准备。下图描述的是上述模型中的一个执行周期。

 

这种模型的特征在于每一个执行周期都会探测一次或一组事件，一个特定的事件会触发某个特定的响应。我们可以将这种模型归类为“事件驱动模型”。

相比其他模型，使用 select() 的事件驱动模型只用单线程（进程）执行，占用资源少，不消耗太多 CPU，同时能够为多客户端提供服务。如果试图建立一个简单的事件驱动的服务器程序，这个模型有一定的参考价值。

但这个模型依旧有着很多问题。

首先，select() 接口并不是实现“事件驱动”的最好选择。因为当需要探测的句柄值较大时，select() 接口本身需要消耗大量时间去轮询各个句柄。很多操作系统提供了更为高效的接口，如 linux 提供了 epoll，BSD 提供了 kqueue，Solaris 提供了 /dev/poll …。如果需要实现更高效的服务器程序，类似 epoll 这样的接口更被推荐。遗憾的是不同的操作系统特供的 epoll 接口有很大差异，所以使用类似于 epoll 的接口实现具有较好跨平台能力的服务器会比较困难。

其次，该模型将事件探测和事件响应夹杂在一起，一旦事件响应的执行体庞大，则对整个模型是灾难性的。如下例，庞大的执行体 1 的将直接导致响应事件 2 的执行体迟迟得不到执行，并在很大程度上降低了事件探测的及时性。

 

幸运的是，有很多高效的事件驱动库可以屏蔽上述的困难，常见的事件驱动库有 libevent 库，还有作为 libevent 替代者的 libev 库。这些库会根据操作系统的特点选择最合适的事件探测接口，并且加入了信号 (signal) 等技术以支持异步响应，这使得这些库成为构建事件驱动模型的不二选择。下章将介绍如何使用 libev 库替换 select 或 epoll 接口，实现高效稳定的服务器模型。

2.4 使用事件驱动库 libev 的服务器模型

Libev 是一种高性能事件循环 / 事件驱动库。作为 libevent 的替代作品，其第一个版本发布与 2007 年 11 月。Libev 的设计者声称 libev 拥有更快的速度，更小的体积，更多功能等优势，这些优势在很多测评中得到了证明。正因为其良好的性能，很多系统开始使用 libev 库。本章将介绍如何使用 Libev 实现提供问答服务的服务器。

（事实上，现存的事件循环 / 事件驱动库有很多，作者也无意推荐读者一定使用 libev 库，而只是为了说明事件驱动模型给网络服务器编程带来的便利和好处。大部分的事件驱动库都有着与 libev 库相类似的接口，只要明白大致的原理，即可灵活挑选合适的库。）

与前章的模型类似，libev 同样需要循环探测事件是否产生。Libev 的循环体用 ev_loop 结构来表达，并用 ev_loop( ) 来启动。

Libev 支持八种事件类型，其中包括 IO 事件。一个 IO 事件用 ev_io 来表征，并用 ev_io_init() 函数来初始化：

初始化内容包括回调函数 callback，被探测的句柄 fd 和需要探测的事件，EV_READ 表“可读事件”，EV_WRITE 表“可写事件”。

现在，用户需要做的仅仅是在合适的时候，将某些 ev_io 从 ev_loop 加入或剔除。一旦加入，下个循环即会检查 ev_io 所指定的事件有否发生；如果该事件被探测到，则 ev_loop 会自动执行 ev_io 的回调函数 callback()；如果 ev_io 被注销，则不再检测对应事件。

无论某 ev_loop 启动与否，都可以对其添加或删除一个或多个 ev_io，添加删除的接口是 ev_io_start() 和 ev_io_stop()。

由此，我们可以容易得出如下的“一问一答”的服务器模型。由于没有考虑服务器端主动终止连接机制，所以各个连接可以维持任意时间，客户端可以自由选择退出时机。

 

上述模型可以接受任意多个连接，且为各个连接提供完全独立的问答服务。借助 libev 提供的事件循环 / 事件驱动接口，上述模型有机会具备其他模型不能提供的高效率、低资源占用、稳定性好和编写简单等特点。

由于传统的 web 服务器，ftp 服务器及其他网络应用程序都具有“一问一答”的通讯逻辑，所以上述使用 libev 库的“一问一答”模型对构建类似的服务器程序具有参考价值；另外，对于需要实现远程监视或远程遥控的应用程序，上述模型同样提供了一个可行的实现方案。

二 nginx 网络模型

Linux服务器网络开发模型,古老的榕树,5-wow.com