码迷,mamicode.com
首页 > 其他好文 > 详细

几种典型的服务器网络编程模型归纳(select poll epoll)

时间:2016-12-17 14:32:39      阅读:225      评论:0      收藏:0      [点我收藏+]

标签:write   缓冲区   blocking   ror   而且   发送   应用程序   其他   链表   

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

其核心代码如下:

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系统调用上。

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

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)

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

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为例,其核心代码如下:

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需要复制大量的句柄数据结构,产生巨大的开销;
select返回的是含有整个句柄的数组,应用程序需要遍历整个数组才能发现哪些句柄发生了事件;
select的触发方式是水平触发,应用程序如果没有完成对一个已经就绪的文件描述符进行IO操作,那么之后每次select调用还是会将这些文件描述符通知进程。
3、相比select模型,poll使用链表保存文件描述符,因此没有了监视文件数量的限制,但其他三个缺点依然存在。
拿select模型为例,假设我们的服务器需要支持100万的并发连接,则在__FD_SETSIZE 为1024的情况下,则我们至少需要开辟1k个进程才能实现100万的并发连接。除了进程间上下文切换的时间消耗外,从内核/用户空间大量的无脑内存拷贝、数组轮询等,是系统难以承受的。因此,基于select模型的服务器程序,要达到10万级别的并发访问,是一个很难完成的任务。

int select(int maxfdp,fd_set *readfds,fd_set *writefds,fd_set *errorfds,struct timeval *timeout);

另一个使用select的例子如下,从网络上接收数据存入一个文件:

main()  
{  
    int sock;  
    FILE *fp;  
    struct fd_set fds;  
    struct timeval timeout={3,0}; //select等待3秒,3秒轮询,要非阻塞就置0  
    char buffer[256]={0}; //256字节的接收缓冲区  
    /* 假定已经建立UDP连接,具体过程不写,简单,当然TCP也同理,主机ip和port都已经给定,要写的文件已经打开 
    sock=socket(...); 
    bind(...); 
    fp=fopen(...); */  
    while(1)  
   {  
        FD_ZERO(&fds); //每次循环都要清空集合,否则不能检测描述符变化  
        FD_SET(sock,&fds); //添加描述符  
        FD_SET(fp,&fds); //同上  
        maxfdp=sock>fp?sock+1:fp+1;    //描述符最大值加1  
        switch(select(maxfdp,&fds,&fds,NULL,&timeout))   //select使用  
        {  
            case -1: exit(-1);break; //select错误,退出程序  
            case 0:break; //再次轮询  
            default:  
                  if(FD_ISSET(sock,&fds)) //测试sock是否可读,即是否网络上有数据  
                  {  
                        recvfrom(sock,buffer,256,.....);//接受网络数据  
                        if(FD_ISSET(fp,&fds)) //测试文件是否可写  
                            fwrite(fp,buffer...);//写入文件  
                            //...
                         //buffer清空;  
                   }// end if break;  
          }// end switch  
     }//end while  
}//end main   

select具体参数参见我的另一篇博客:传送门

5.IO多路复用模型之epoll
epoll IO多路复用:一个看起来很美好的解决方案。参考文章:高并发网络编程之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万个连接的句柄数据,内核也不需要去遍历全部的连接。
select poll epoll总结参考我的另一篇博客:传送门
epoll是在2.6内核中提出的,是之前的select和poll的增强版本。相对于select和poll来说,epoll更加灵活,没有描述符限制。epoll使用一个文件描述符管理多个描述符,将用户关系的文件描述符的事件存放到内核的一个事件表中,这样在用户空间和内核空间的copy只需一次。

epoll操作过程需要三个接口,分别如下:

#include <sys/epoll.h>
int epoll_create(int size);
int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event);
int epoll_wait(int epfd, struct epoll_event * events, int maxevents, int timeout);

  epoll既然是对select和poll的改进,就应该能避免上述的三个缺点。那epoll都是怎么解决的呢?在此之前,我们先看一下epoll和select和poll的调用接口上的不同,select和poll都只提供了一个函数——select或者poll函数。而epoll提供了三个函数,epoll_create,epoll_ctl和epoll_wait,epoll_create是创建一个epoll句柄;epoll_ctl是注册要监听的事件类型;epoll_wait则是等待事件的产生。

  1、对于第一个缺点,epoll的解决方案在epoll_ctl函数中。每次注册新的事件到epoll句柄中时(在epoll_ctl中指定EPOLL_CTL_ADD),会把所有的fd拷贝进内核,而不是在epoll_wait的时候重复拷贝。epoll保证了每个fd在整个过程中只会拷贝一次。

 2、对于第二个缺点,epoll的解决方案不像select或poll一样每次都把current轮流加入fd对应的设备等待队列中,而只在epoll_ctl时把current挂一遍(这一遍必不可少)并为每个fd指定一个回调函数,当设备就绪,唤醒等待队列上的等待者时,就会调用这个回调函数,而这个回调函数会把就绪的fd加入一个就绪链表)。epoll_wait的工作实际上就是在这个就绪链表中查看有没有就绪的fd(利用schedule_timeout()实现睡一会,判断一会的效果)。
 3、对于第三个缺点,epoll没有这个限制,它所支持的FD上限是最大可以打开文件的数目,这个数字一般远大于2048,举个例子,在1GB内存的机器上大约是10万左右,具体数目可以cat /proc/sys/fs/file-max察看,一般来说这个数目和系统内存关系很大。

当某一进程调用epoll_create方法时,Linux内核会创建一个eventpoll结构体,这个结构体中有两个成员与epoll的使用方式密切相关。eventpoll结构体如下所示:

struct eventpoll{
    ....
    /*红黑树的根节点,这颗树中存储着所有添加到epoll中的需要监控的事件*/
    struct rb_root  rbr;
    /*双链表中则存放着将要通过epoll_wait返回给用户的满足条件的事件*/
    struct list_head rdlist;
    ....
};

每一个epoll对象都有一个独立的eventpoll结构体,用于存放通过epoll_ctl方法向epoll对象中添加进来的事件。这些事件都会挂载在红黑树中,如此,重复添加的事件就可以通过红黑树而高效的识别出来(红黑树的插入时间效率是lgn,其中n为树的高度)。

而所有添加到epoll中的事件都会与设备(网卡)驱动程序建立回调关系,也就是说,当相应的事件发生时会调用这个回调方法。这个回调方法在内核中叫ep_poll_callback,它会将发生的事件添加到rdlist双链表中。

在epoll中,对于每一个事件,都会建立一个epitem结构体,如下所示:

struct epitem{
    struct rb_node  rbn;//红黑树节点
    struct list_head    rdllink;//双向链表节点
    struct epoll_filefd  ffd;  //事件句柄信息
    struct eventpoll *ep;    //指向其所属的eventpoll对象
    struct epoll_event event; //期待发生的事件类型
}

图示如下:
技术分享
当调用epoll_wait检查是否有事件发生时,只需要检查eventpoll对象中的rdlist双链表中是否有epitem元素即可。如果rdlist不为空,则把发生的事件复制到用户态,同时将事件数量返回给用户。

epoll的用法分为三步:
**第一步:epoll_create()系统调用。此调用返回一个句柄,之后所有的使用都依靠这个句柄来标识。
第二步:epoll_ctl()系统调用。通过此调用向epoll对象中添加、删除、修改感兴趣的事件,返回0标识成功,返回-1表示失败。
第三步:epoll_wait()系统调用。通过此调用收集收集在epoll监控中已经发生的事件。**

下面是一个简单使用了epoll和pipe管道的例子,子进程写,父进程使用epoll监听管道写端。

#include <iostream>
#include <unistd.h>
#include <errno.h>
#include <sys/epoll.h>
#include <cstdio>
#include <cstdlib>
#include <cstring>
using namespace std;

int main()
{
    struct epoll_event ev;                     //事件临时变量
    const int MAXEVENTS = 1024;                //最大事件数
    struct epoll_event events[MAXEVENTS];      //监听事件数组
    int ret,pid;
    int pipe_fd[2];
    if((ret=pipe(pipe_fd))<0)//创建管道的两端,0读 1写
    {
        cout<<"create pipe fail:"<<ret<< ",errno:" << errno <<endl;
        return -1;
    }
    ev.data.fd = pipe_fd[0];        //设置监听文件描述符

    /*EPOLLLT 是默认行为,基本上就是说,只要一个文件描述符处于就绪状态,epoll 就会不停的通知你有事件发生。传统的 select/poll 都是这样的
EPOLLET 是新的方式,只在一个文件描述符新处于就绪的时候通知一次,之后不管数据有没有读完,都不会再通知,当然,有新数据到还是会通知的。
所以,用 EPOLLET 的时候,一定要把文件描述符设置为 non-blocking,而且最好是一直读数据,读到返回 EAGAIN 才停下*/
    ev.events = EPOLLIN|EPOLLET;    //设置要处理的事件类型

    int epfd=epoll_create(MAXEVENTS);
    ret=epoll_ctl(epfd,EPOLL_CTL_ADD,pipe_fd[0],&ev);
    if (ret != 0)
    {
        cout << "epoll_ctl fail:" << ret << ",errno:" << errno << endl;
        close(pipe_fd[0]);
        close(pipe_fd[1]);
        close(epfd);
        return -1;
    }
    if((pid=fork())>0)//父进程
    {
        int count=epoll_wait(epfd,events,MAXEVENTS,5000);
        char r_buf[100];
        for(int i=0;i<count;i++)
        {
            if((events[i].data.fd==pipe_fd[0])&&(events[0].events&EPOLLIN))
            {
                int r_num=read(pipe_fd[0],r_buf,100);
                printf("read num is %d bytes data from the pipe,value is %d \n",r_num,atoi(r_buf));
            }
        }
        close(pipe_fd[1]);
        close(pipe_fd[0]);
        close(epfd);
        cout<<"parent close read fd[0],wirte fd[1] and epfd over"<<endl;

    }//子进程
    else if(pid==0)
    {
        close(pipe_fd[0]);//关读端
        cout<<"sub close read fd[0] over,sub does‘t read"<<endl;
        char w_buf[100];
        strcpy(w_buf,"1234");
        if(write(pipe_fd[1],w_buf,5)!=-1)//子进程往管道里写
            printf("sub write over \n");
        close(pipe_fd[1]);//关写端
        printf("sub close write fd[1] over \n");
    }
    return 0;
}

几种典型的服务器网络编程模型归纳(select poll epoll)

标签:write   缓冲区   blocking   ror   而且   发送   应用程序   其他   链表   

原文地址:http://blog.csdn.net/drdairen/article/details/53694550

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!