从零开始认识多路转接
- 1 EPOLL优缺点
- 2 EPOLL工作模式
1 EPOLL优缺点
poll 的优点(和 select 的缺点对应)
- 接口使用方便:虽然拆分成了三个函数,但是逻辑清晰,使用起来更方便高效。不需要每次循环都设置关注的文件描述符,并且做到了输入输出参数分离开!
- 数据拷贝轻量:只在合适的时候调用 EPOLL_CTL_ADD 将文件描述符结构拷贝到内核中,这个操作并不频繁(而 select/poll 都是每次循环都要进行拷贝)。
- 事件回调机制:避免使用遍历, 而是使用回调函数的方式,将就绪的文件描述符结构加入到就绪队列中。epoll_wait 返回直接访问就绪队列就知道哪些文件描述符就绪。这个操作时间复杂度 O(1). 即使文件描述符数目很多,效率也不会受到影响。
- 没有数量限制:理论上,文件描述符数目是无上限。epoll的接口支持无上限的文件描述符!
网上说:epoll 中使用了内存映射机制
- 内存映射机制: 内核直接将就绪队列通过 mmap 的方式映射到用户态。 避免了拷贝内存这样的额外性能开销。
这种说法是不准确的。我们定义的 struct epoll_event
是我们在用户空间中分配好的内存。势必还是需要将内核的数据拷贝到这个用户空间的内存中的。
可以这么说epoll几乎没有缺点!
2 EPOLL工作模式
select、poll、epoll都存在一个现象:当有事件就绪时,用户不处理就会一直通知用户处理,循环打印日志信息。
EPOLL的工作模式有两种:
- LT水平触发
- ET边缘触发
上面现象是LT模式下的产物,那么怎么理解LT与ET呢?我们通过快递小哥的例子进行讲解:
有两名快递员张三李四,他们一个温和老实,一个严肃霸道。
小明前几天买了5个包裹,今天一起送到了快递站。张三李四分别分到了小明的3个包裹和2个包裹。
张三首先到达了小王所在的小区,他给该小区所以的收件人都打了一遍电话:“请你下来拿快递”。小明这时正在和舍友打无畏契约,拿不了快递。过了一会张三再次给小明打电话让他下来拿快递,小明下去取了一个就立马回去了。张三一看,还有两个包裹啊,于是又给小王打电话!这时李四过来了,把两个快递交给了张三。张三就在这里一直打电话
第二天,又有小明的5个包裹,这次李四来到小区门口,开始打电话:我只给你打一次电话,你有快递到了,不拿我就走人。小明一听,这快递小哥这么硬气,哎我就不拿,那你怎么办。于是小明就没有去拿,结果李四真的走了。一会碰到了张三,张三把小明的包裹给了李四,于是李四又来到小区门口,再一次强硬的打电话。小明决定去拿了,快递不拿他是真走啊!
这里我们可以总结出来:
- 张三:只有底层有快递,就一直打电话给小王。
- 李四:只有包裹变化的时候,我才来通知你拿快递。
在这个例子中,快递就是数据,张三对应LT水平触发模式,李四对应ET边缘触发模式。一般情况下是LT水平触发模式。
这两种模式哪一个更加高效呢?ET模式更加高效!毕竟李四比张三打的电话少的多得多!
LT水平触发是默认的,那么一个如何设置成ET边缘触发模式呢?
- 通过EPOLLET 标志位: 将 EPOLL 设为边缘触发(Edge Triggered)模式, 这是相对于水平触发(Level Triggered)来说的
- 水平触发 Level Triggered 工作模式
- epoll 默认状态下就是 LT 工作模式。
- 当 epoll 检测到 socket 上事件就绪的时候, 可以不立刻进行处理. 或者只处理一部分。
- 如上面的例子, 由于只读了 1K 数据,缓冲区中还剩 1K 数据,在第二次调用epoll_wait 时, epoll_wait 仍然会立刻返回并通知 socket 读事件就绪。
- 直到缓冲区上所有的数据都被处理完, epoll_wait 才不会立刻返回。
- 支持阻塞读写和非阻塞读写。
- 边缘触发 Edge Triggered 工作模式
- 如果将 socket 添加到 epoll 描述符的时候使用了 EPOLLET 标志,epoll 进入 ET 工作模式。
- 当 epoll 检测到 socket 上事件就绪时,必须立刻处理。
- 如上面的例子,虽然只读了 1K 的数据,缓冲区还剩 1K 的数据,在第二次调用epoll_wait 的时候,epoll_wait 不会再返回了。
- 也就是说, ET 模式下,文件描述符上的事件就绪后,只有一次处理机会。
- ET 的性能比 LT 性能更高( epoll_wait 返回的次数少了很多). Nginx 默认采用ET 模式使用 epoll。
- 只支持非阻塞的读写
假如服务端使用ET模式,这时服务端需要的数据是10K,客户端将这10K数据发过来,服务端第一次只读取了1K的数据。由于是ET模式,在客户端发送新的数据之前,服务端一直不会进行读取!所以ET模式下,必须一次性将数据读完,就要进行循环读取直到读取不到!这样也就必须使用非阻塞的读取了(才能支持循环读取)!LT模式没有这种问题。
- ET模式的这种读取方式也就决定了TCP应答中TCP服务端的窗口更大,客户端下一次可以发送更多的数据!增加IO效率!
那么LT设置成非阻塞呢?那么是不是和ET模式一样了呢?所以一般不能说ET模式一定比LT模式的效率更高。可是,ET强制程序员必须使用非阻塞进行读取!LT不会强制程序员使用非阻塞读取!所以可以认为ET模式更加高效!