目录
EPOLL的触发方式
水平触发 LT(Level Triggered)
边沿触发 ET(Eage Triggered)
比喻
过程
总结
回到epoll
效率
为什么要一次读完?
如何确保读完了所有数据?
举例
回到epoll
效率对比总结
本质
epoll接口介绍 -- epoll接口介绍,epoll模型介绍+原理,接口和模型的关系,epoll优点(和select/poll进行对比)-CSDN博客
EPOLL的触发方式
水平触发 LT(Level Triggered)
epoll的默认方式
- 如果我们没有处理[已就绪的事件],会一直通知我们
可以把已就绪的事件看作高电平,通知看作有效
- 水平触发就是,只要处于高电平,就有效
边沿触发 ET(Eage Triggered)
数据/连接有变化的时候,才会通知,且只通知一次
- 变化 -- 从无到有,从有到多
比喻
过程
可以把这两个模式看做是两个快递员送货的方式
- a快递员 -- 当有快递送到,而你不去取/取了一部分,会一直打电话通知让你来取,直到取完
- b快递员 -- 也会在快递送到时通知,区别在于:如果你没有取/只取了一部分,他不会将剩下的部分留在那里,而是带走 ; 并且他这次通知了之后就不管了,直到有新快递到来,才又会通知我们,然后带上之前你剩下的快递
总结
乍眼一看,可能会觉得a方式更好
但因为b的特性,如果我们没有一次取完,可能导致货物丢失什么的,或是等待下一个货物等待了很久
- 所以,会倒逼我们在收到通知后,就一次取走所有货物
并且,对比a和b,我们会发现,b可以通知到更多的人
- 因为一个快递员在一定时间内打出的电话次数是有限的
- a可能一直在打重复电话,而b通知到的人数更多
回到epoll
效率
也就是说:
- ET的特性会倒逼程序员,在处理通知时,需要一次将收到的数据全部读取,否则会错过这一次发来的完整数据,直到对方向我们发来新的数据,才能接收到上一轮剩下的数据
- 所以,ET的io效率更高 -- 通知一次,就把数据全部取走
联系到tcp层:
- 如果一次就能把数据全部取走,接收缓冲区就会更大的空间,从而向对方发送一个更大的窗口,这样对方一次就能发送更多的数据(和延迟应答的原理类似)
因为ET下可以通知更多的进程
- 所以通知效率也更高
为什么要一次读完?
如果不强制要求,可能会导致通信双方无法完成正常通信
- 假设,a收到了b的10k数据,但a只读取了1k,剩下的还在内核缓冲区里
- 然后就会卡在这里: a在等待b的通知,想要继续读取数据 ; 而b在等待a的应答,收到应答后才会继续发送数据
- 这就尴尬了
- 所以,必须一次读完
如何确保读完了所有数据?
举例
假如a月初领了1000块,到了月中的时候,你找他借钱,此时你并不知道他现在有多少钱
如果你想把他手里的钱全部借走,怎么做?
- 可以先借100,如果要多少给多少,说明他手里还有钱,可以继续要
- 直到给的比要的少,有零有整的,说明此时已经要完了
- 如果此时再继续要,他就会说自己已经没有钱了
回到epoll
总结一下就是 -- 保证全部取走 = 循环读取,直到没有数据
注意:
- 如果是阻塞io下,recv/read函数在没有数据可以读取的情况下,会阻塞至有数据到达
- 但这不是我们希望的,因为我们写的是个单进程,一旦阻塞,整个服务器就寄了
- 所以,我们要在ET模式下设置为非阻塞模式
我们之前实验过,如果当前没有数据,会返回[错误码为11]的错误
效率对比总结
但并不是说ET的效率就一定比LT方式高
- 普遍情况下,确实是这样的,但还是取决于代码的具体实现
谁说采用了LT模式就不能将所有fd设置为非阻塞方式,然后循环读取,直到没有数据呢?
- 如果我们保证在LT模式下,在第一次通知时,就取走全部数据,也就达到了和ET一样的效果
- 只不过一个是主动,一个是被动这么做
本质
前面我们一直在说的通知,其本质是 -- 添加结点入就绪队列
- 只要上层调用epoll_wait,就能获取队列中的数据
当然,如果不调用也没办法
- 毕竟内核也不能强迫调用接口吧,通知就是它能做到的极限了
- 就像tcp中的psh标志,他也只是催促对方赶紧将收到的数据准备好交给上层,而无法硬塞给上层
epoll读取数据的流程:
- 就是等就绪队列有数据+调用epoll_wait接口 -> 将就绪队列中的数据读取到tcp层的接收缓冲区中 -> 上层从缓冲区中读出数据(读出的方式就是ET和LT的区别)
- LT -- 不保证一次读完,但每次都会将未被读取的结点放入队列
- ET -- 因为只会将结点放入队列中一次,所以必须读完数据
