5种服务器网络编程模型

转载地址：http://www.kuqin.com/shuoit/20140914/342168.html

1.同步阻塞迭代模型

同步阻塞迭代模型是最简单的一种IO模型。

其核心代码如下：

1 2 3 4 5 6 7 8

bind(srvfd); listen(srvfd); for(;;){ clifd = accept(srvfd,...); //开始接受客户端来的连接 read(clifd,buf,...); //从客户端读取数据 dosomthingonbuf(buf); write(clifd,buf)//发送数据到客户端 }

上面的程序存在如下一些弊端：

1）如果没有客户端的连接请求，进程会阻塞在accept系统调用处，程序不能执行其他任何操作。(系统调用使得程序从用户态陷入内核态，具体请参考：程序员的自我修养)

2）在与客户端建立好一条链路后，通过read系统调用从客户端接受数据，而客户端合适发送数据过来是不可控的。如果客户端迟迟不发生数据过来，则程序同样会阻塞在read调用，此时，如果另外的客户端来尝试连接时，都会失败。

3）同样的道理，write系统调用也会使得程序出现阻塞(例如：客户端接受数据异常缓慢，导致写缓冲区满，数据迟迟发送不出)。

2.多进程并发模型

同步阻塞迭代模型有诸多缺点。多进程并发模型在同步阻塞迭代模型的基础上进行了一些改进，以避免是程序阻塞在read系统调用上。

多进程模型核心代码如下：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

bind(srvfd); listen(srvfd); for(;;){ clifd = accept(srvfd,...); //开始接受客户端来的连接 ret = fork(); switch( ret ) { case -1 : do_err_handler(); break; case 0: // 子进程 client_handler(clifd); break ; default : // 父进程 close(clifd); continue ; } } //====================================================== void client_handler(clifd){ read(clifd,buf,...); //从客户端读取数据 dosomthingonbuf(buf); write(clifd,buf)//发送数据到客户端 }

上述程序在accept系统调用时，如果没有客户端来建立连接，择会阻塞在accept处。一旦某个客户端连接建立起来，则立即开启一个新的进程来处理与这个客户的数据交互。避免程序阻塞在read调用，而影响其他客户端的连接。

3.多线程并发模型

在多进程并发模型中，每一个客户端连接开启fork一个进程，虽然linux中引入了写实拷贝机制，大大降低了fork一个子进程的消耗，但若客户端连接较大，则系统依然将不堪负重。通过多线程(或线程池)并发模型，可以在一定程度上改善这一问题。

在服务端的线程模型实现方式一般有三种：

（1）按需生成(来一个连接生成一个线程)

（2）线程池(预先生成很多线程)

（3）Leader follower（LF）

为简单起见，以第一种为例，其核心代码如下：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

void *thread_callback( void *args ) //线程回调函数 { int clifd = *(int *)args ; client_handler(clifd); } //=============================================================== void client_handler(clifd){ read(clifd,buf,...); //从客户端读取数据 dosomthingonbuf(buf); write(clifd,buf)//发送数据到客户端 } //=============================================================== bind(srvfd); listen(srvfd); for(;;){ clifd = accept(); pthread_create(...,thread_callback,&clifd); }

服务端分为主线程和工作线程，主线程负责accept()连接，而工作线程负责处理业务逻辑和流的读取等。因此，即使在工作线程阻塞的情况下，也只是阻塞在线程范围内，对继续接受新的客户端连接不会有影响。

第二种实现方式，通过线程池的引入可以避免频繁的创建、销毁线程，能在很大程序上提升性能。但不管如何实现，多线程模型先天具有如下缺点：

1）稳定性相对较差。一个线程的崩溃会导致整个程序崩溃。

2）临界资源的访问控制，在加大程序复杂性的同时，锁机制的引入会是严重降低程序的性能。性能上可能会出现“辛辛苦苦好几年，一夜回到解放前”的情况。

4.IO多路复用模型之select/poll

多进程模型和多线程(线程池)模型每个进程/线程只能处理一路IO，在服务器并发数较高的情况下，过多的进程/线程会使得服务器性能下降。而通过多路IO复用，能使得一个进程同时处理多路IO，提升服务器吞吐量。

在Linux支持epoll模型之前，都使用select/poll模型来实现IO多路复用。

以select为例，其核心代码如下：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

bind(listenfd); listen(listenfd); FD_ZERO(&allset); FD_SET(listenfd, &allset); for(;;){ select(...); if (FD_ISSET(listenfd, &rset)) {/*有新的客户端连接到来*/ clifd = accept(); cliarray[] = clifd; /*保存新的连接套接字*/ FD_SET(clifd, &allset);/*将新的描述符加入监听数组中*/ } for(;;){/*这个for循环用来检查所有已经连接的客户端是否由数据可读写*/ fd = cliarray[i]; if (FD_ISSET(fd , &rset)) dosomething(); } }

select IO多路复用同样存在一些缺点，罗列如下：

1. 单个进程能够监视的文件描述符的数量存在最大限制，通常是1024，当然可以更改数量，但由于select采用轮询的方式扫描文件描述符，文件描述符数量越多，性能越差；(在linux内核头文件中，有这样的定义：#define __FD_SETSIZE 1024)
2. 内核 / 用户空间内存拷贝问题，select需要复制大量的句柄数据结构，产生巨大的开销；
3. select返回的是含有整个句柄的数组，应用程序需要遍历整个数组才能发现哪些句柄发生了事件；
4. select的触发方式是水平触发，应用程序如果没有完成对一个已经就绪的文件描述符进行IO操作，那么之后每次select调用还是会将这些文件描述符通知进程。

相比select模型，poll使用链表保存文件描述符，因此没有了监视文件数量的限制，但其他三个缺点依然存在。

拿select模型为例，假设我们的服务器需要支持100万的并发连接，则在__FD_SETSIZE 为1024的情况下，则我们至少需要开辟1k个进程才能实现100万的并发连接。除了进程间上下文切换的时间消耗外，从内核/用户空间大量的无脑内存拷贝、数组轮询等，是系统难以承受的。因此，基于select模型的服务器程序，要达到10万级别的并发访问，是一个很难完成的任务。

5.IO多路复用模型之epoll

epoll IO多路复用：一个看起来很美好的解决方案。 由于文章：高并发网络编程之epoll详解中对epoll相关实现已经有详细解决，这里就直接摘录过来。

由于epoll的实现机制与select/poll机制完全不同，上面所说的select的缺点在epoll上不复存在。

设想一下如下场景：有100万个客户端同时与一个服务器进程保持着TCP连接。而每一时刻，通常只有几百上千个TCP连接是活跃的(事实上大部分场景都是这种情况)。如何实现这样的高并发？

在select/poll时代，服务器进程每次都把这100万个连接告诉操作系统(从用户态复制句柄数据结构到内核态)，让操作系统内核去查询这些套接字上是否有事件发生，轮询完后，再将句柄数据复制到用户态，让服务器应用程序轮询处理已发生的网络事件，这一过程资源消耗较大，因此，select/poll一般只能处理几千的并发连接。

epoll的设计和实现与select完全不同。epoll通过在Linux内核中申请一个简易的文件系统(文件系统一般用什么数据结构实现？B+树)。把原先的select/poll调用分成了3个部分：

1）调用epoll_create()建立一个epoll对象(在epoll文件系统中为这个句柄对象分配资源)

2）调用epoll_ctl向epoll对象中添加这100万个连接的套接字

3）调用epoll_wait收集发生的事件的连接

如此一来，要实现上面说是的场景，只需要在进程启动时建立一个epoll对象，然后在需要的时候向这个epoll对象中添加或者删除连接。同时，epoll_wait的效率也非常高，因为调用epoll_wait时，并没有一股脑的向操作系统复制这100万个连接的句柄数据，内核也不需要去遍历全部的连接。