Linux服务器网络开发模型

为什么Nginx的性能要比Apache高得多?

这主要是因为Nginx使用了最新的epoll（Linux 2.6内核）和kqueue（FreeBSD）网络I/O模型，而Apache则使用的是传统的select模型。曾在一篇博客上看到有这么个实例：
假设你在大学中读书,要等待一个朋友来访,而这个朋友只知道你在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 错误）。

Linux服务器网络开发模型相关推荐

linux服务器网络编程之线程模型
前言本文将主要介绍传统的和目前流行的进程/线程模型,在讲进程/线程模型之前需要先介绍一种设计模式: Reactor 模式.Reactor 模式首先是事件驱动的,有一个或多个并发输入源,有一个Se ...
Netty框架-IO模型（Linux五大网络IO模型）
一. IO读写的基础原理:read.write 1.编程模型一致性以及底层系统调用的理解(缓冲区与直接调用): 1.1.无论是Socket的读写还是文件的读写,在Java层面的应用开发或者是linux ...
明明白白你的Linux服务器——网络篇
原文地址:http://os.51cto.com/art/201007/209530.htm 一.服务器的网络配置在服务器的网络配置时,喜欢图形的朋友可用setup或system-config-ne ...
linux服务器程序开发,怎样搭建一个linux开发服务器
在开发过程中,必然会出现多人同时工作.协着的情况,在嵌入式开发项目中更为平常,这样可以加快项目周期,为产品上市占得时间先机.目前,使用Linux作为开发产品的操作系统情况越来越多,使用越来越广泛.为了 ...
linux服务器i o模型,高性能服务器框架--I/O模型
socket在创建的时候默认是阻塞的.我们可以通过socket系统调用的第二个参数传递SOCK_NONBLOCK标志,或者通过fcntl系统调用的F_SETFL命令,将其设置为非阻塞的.阻塞和非阻塞的 ...
linux 服务器网络有关的内核参数
几乎所有的内核模块,包括内核核心模块和驱动程序,都在/proc/sys 文件系统下提供了某些配置文件以提供用户调整模块的属性和行为.通常一个配置文件对应一个内核参数,文件名就是参数的名字,文件的内容是 ...
Linux高级网络开发奇妙之旅
一.基础理论篇 01.网络协议入门 02.LAN.WAN.WLAN.VLAN 和 VPN 的区别 03.IP 地址介绍 04.广播地址介绍 05.无连接和面向连接协议的区别 06.因特网的IP协议是不 ...
Linux服务器网络故障诊断
1.查看域名服务器服务器是否正常:nslookup工具.如sudo nslookup baidu.com 2.查看物理网线端口是否成功连接:ethtool工具.如ethtool eth0.重点看显示信 ...
明明白白你的Linux服务器——网络篇(2)
三. 寻找恶意IP并用iptables禁止掉找出恶意连接你的服务器80端口的IP,直接用iptables来drop掉它:这里建议写脚本来运行,有兴趣的请参考我在51cto.com里发表的自动分析黑名 ...

Linux服务器网络开发模型

Linux服务器网络开发模型相关推荐

最新文章

热门文章