浅析Linux服务器网络开发模型

40次阅读

共计 2094 个字符，预计需要花费 6 分钟才能阅读完成。

导读	几日前公司同事王开源同志将笔记本系统转成了 liunx 系统，看上去不错，应该有的应用基本上都有了。如文档处理软件、表格处理软件、eclipse 开发环境等。别说，还真不错。自己又一次动心想装一个 liunx 系统使用，可是还没有敢这样做，采用 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 错误)。