5种服务器网络编程模型讲解(转)

做者:快课网——Jay13html

原文连接:http://www.cricode.com/3510.htmlnode

本文介绍几种服务器网络编程模型。废话很少说,直接正题。linux

1.同步阻塞迭代模型

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

其核心代码以下:git

上面的程序存在以下一些弊端:程序员

1)若是没有客户端的链接请求,进程会阻塞在accept系统调用处,程序不能执行其余任何操做。(系统调用使得程序从用户态陷入内核态,具体请参考:程序员的自我修养)github

2)在与客户端创建好一条链路后,经过read系统调用从客户端接受数据,而客户端合适发送数据过来是不可控的。若是客户端迟迟不发生数据过来,则程序一样会阻塞在read调用,此时,若是另外的客户端来尝试链接时,都会失败。编程

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

2.多进程并发模型

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

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

上述程序在accept系统调用时,若是没有客户端来创建链接,择会阻塞在accept处。一旦某个客户端链接创建起来,则当即开启一个新的进程来处理与这个客户的数据交互。避免程序阻塞在read调用,而影响其余客户端的链接。

3.多线程并发模型

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

在服务端的线程模型实现方式通常有三种:

(1)按需生成(来一个链接生成一个线程)

(2)线程池(预先生成不少线程)

(3)Leader follower(LF)

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

 

服务端分为主线程和工做线程,主线程负责accept()链接,而工做线程负责处理业务逻辑和流的读取等。所以,即便在工做线程阻塞的状况下,也只是阻塞在线程范围内,对继续接受新的客户端链接不会有影响。

第二种实现方式,经过线程池的引入能够避免频繁的建立、销毁线程,能在很大程序上提高性能。但无论如何实现,多线程模型先天具备以下缺点:

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

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

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

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

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

以select为例,其核心代码以下:

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万个链接的句柄数据,内核也不须要去遍历所有的链接。

 

下面来看看Linux内核具体的epoll机制实现思路。

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

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

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

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

当调用epoll_wait检查是否有事件发生时,只须要检查eventpoll对象中的rdlist双链表中是否有epitem元素便可。若是rdlist不为空,则把发生的事件复制到用户态,同时将事件数量返回给用户。

epoll数据结构示意图

从上面的讲解可知:经过红黑树和双链表数据结构,并结合回调机制,造就了epoll的高效。

OK,讲解完了Epoll的机理,咱们便能很容易掌握epoll的用法了。一句话描述就是:三步曲。

第一步:epoll_create()系统调用。此调用返回一个句柄,以后全部的使用都依靠这个句柄来标识。

第二步:epoll_ctl()系统调用。经过此调用向epoll对象中添加、删除、修改感兴趣的事件,返回0标识成功,返回-1表示失败。

第三部:epoll_wait()系统调用。经过此调用收集收集在epoll监控中已经发生的事件。

最后,附上一个epoll编程实例。(此代码做者为sparkliang)

相关文章
相关标签/搜索