按照man手冊(cè)的說法：epoll是為處理大批量句柄而作了改進(jìn)的poll。要使用epoll只需要這三個(gè)系統(tǒng)調(diào)用：epoll_create(2)， epoll_ctl(2)， epoll_wait(2)。
<1>支持一個(gè)進(jìn)程打開大數(shù)目的socket描述符(FD)
select 最不能忍受的是一個(gè)進(jìn)程所打開的FD是有一定限制的，由FD_SETSIZE設(shè)置，默認(rèn)值是2048。對(duì)于那些需要支持的上萬連接數(shù)目的IM服務(wù)器來說顯然太少了。這時(shí)候你
一是可以選擇修改這個(gè)宏然后重新編譯內(nèi)核，不過資料也同時(shí)指出這樣會(huì)帶來網(wǎng)絡(luò)效率的下降，
二是可以選擇多進(jìn)程的解決方案(傳統(tǒng)的Apache方案)，不過雖然linux上面創(chuàng)建進(jìn)程的代價(jià)比較小，但仍舊是不可忽視的，加上進(jìn)程間數(shù)據(jù)同步遠(yuǎn)比不上線程間同步的高效，所以也不是一種完美的方案。
epoll則沒有這個(gè)限制，它所支持的FD上限是最大可以打開文件的數(shù)目，這個(gè)數(shù)字一般遠(yuǎn)大于2048,舉個(gè)例子,在1GB內(nèi)存的機(jī)器上大約是10萬左右，具體數(shù)目可以cat /proc/sys/fs/file-max察看,一般來說這個(gè)數(shù)目和系統(tǒng)內(nèi)存關(guān)系很大。
<2>IO效率不隨FD數(shù)目增加而線性下降
傳統(tǒng)的select/poll另一個(gè)致命弱點(diǎn)就是當(dāng)你擁有一個(gè)很大的socket集合，不過由于網(wǎng)絡(luò)延時(shí)，任一時(shí)間只有部分的socket是"活躍"的，但是select/poll每次調(diào)用都會(huì)線性掃描全部的集合，導(dǎo)致效率呈現(xiàn)線性下降。
epoll不存在這個(gè)問題，它只會(huì)對(duì)"活躍"的socket進(jìn)行操作---這是因?yàn)樵趦?nèi)核實(shí)現(xiàn)中epoll是根據(jù)每個(gè)fd上面的callback函數(shù)實(shí)現(xiàn)的。那么，只有"活躍"的socket才會(huì)主動(dòng)的去調(diào)用 callback函數(shù)，其他idle狀態(tài)socket則不會(huì)，在這點(diǎn)上，epoll實(shí)現(xiàn)了一個(gè)"偽"AIO，因?yàn)檫@時(shí)候推動(dòng)力在os內(nèi)核。在一些 benchmark中，如果所有的socket基本上都是活躍的---比如一個(gè)高速LAN環(huán)境，epoll并不比select/poll有什么效率，相反，如果過多使用epoll_ctl,效率相比還有稍微的下降。但是一旦使用idle connections模擬WAN環(huán)境,epoll的效率就遠(yuǎn)在select/poll之上了。
<3>使用mmap加速內(nèi)核與用戶空間的消息傳遞。
這點(diǎn)實(shí)際上涉及到epoll的具體實(shí)現(xiàn)了。無論是select,poll還是epoll都需要內(nèi)核把FD消息通知給用戶空間，如何避免不必要的內(nèi)存拷貝就很重要，在這點(diǎn)上，epoll是通過內(nèi)核于用戶空間mmap同一塊內(nèi)存實(shí)現(xiàn)的。而如果你想我一樣從2.5內(nèi)核就關(guān)注epoll的話，一定不會(huì)忘記手工 mmap這一步的。
<4>內(nèi)核微調(diào)
這一點(diǎn)其實(shí)不算epoll的優(yōu)點(diǎn)了，而是整個(gè)linux平臺(tái)的優(yōu)點(diǎn)。也許你可以懷疑linux平臺(tái)，但是你無法回避linux平臺(tái)賦予你微調(diào)內(nèi)核的能力。比如，內(nèi)核TCP/IP協(xié)議棧使用內(nèi)存池管理sk_buff結(jié)構(gòu)，那么可以在運(yùn)行時(shí)期動(dòng)態(tài)調(diào)整這個(gè)內(nèi)存pool(skb_head_pool)的大小--- 通過echo XXXX>/proc/sys/net/core/hot_list_length完成。再比如listen函數(shù)的第2個(gè)參數(shù)(TCP完成3次握手的數(shù)據(jù)包隊(duì)列長(zhǎng)度)，也可以根據(jù)你平臺(tái)內(nèi)存大小動(dòng)態(tài)調(diào)整。更甚至在一個(gè)數(shù)據(jù)包面數(shù)目巨大但同時(shí)每個(gè)數(shù)據(jù)包本身大小卻很小的特殊系統(tǒng)上嘗試最新的NAPI網(wǎng)卡驅(qū)動(dòng)架構(gòu)。
//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
在linux的網(wǎng)絡(luò)編程中，很長(zhǎng)的時(shí)間都在使用select來做事件觸發(fā)。在linux新的內(nèi)核中，有了一種替換它的機(jī)制，就是epoll。
相比于select，epoll最大的好處在于它不會(huì)隨著監(jiān)聽fd數(shù)目的增長(zhǎng)而降低效率。因?yàn)樵趦?nèi)核中的select實(shí)現(xiàn)中，它是采用輪詢來處理的，輪詢的fd數(shù)目越多，自然耗時(shí)越多。并且，在linux/posix_types.h頭文件有這樣的聲明：
#define __FD_SETSIZE 1024
表示select最多同時(shí)監(jiān)聽1024個(gè)fd，當(dāng)然，可以通過修改頭文件再重編譯內(nèi)核來擴(kuò)大這個(gè)數(shù)目，但這似乎并不治本。
epoll的接口非常簡(jiǎn)單，一共就三個(gè)函數(shù)：
1. int epoll_create(int size);
創(chuàng)建一個(gè)epoll的句柄，size用來告訴內(nèi)核這個(gè)監(jiān)聽的數(shù)目一共有多大。這個(gè)參數(shù)不同于select()中的第一個(gè)參數(shù)，給出最大監(jiān)聽的fd+1的值。需要注意的是，當(dāng)創(chuàng)建好epoll句柄后，它就是會(huì)占用一個(gè)fd值，在linux下如果查看/proc/進(jìn)程id/fd/，是能夠看到這個(gè)fd的，所以在使用完epoll后，必須調(diào)用close()關(guān)閉，否則可能導(dǎo)致fd被耗盡。
2. int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event);
epoll的事件注冊(cè)函數(shù)，它不同與select()是在監(jiān)聽事件時(shí)告訴內(nèi)核要監(jiān)聽什么類型的事件，而是在這里先注冊(cè)要監(jiān)聽的事件類型。第一個(gè)參數(shù)是epoll_create()的返回值，第二個(gè)參數(shù)表示動(dòng)作，用三個(gè)宏來表示：
EPOLL_CTL_ADD：注冊(cè)新的fd到epfd中；
EPOLL_CTL_MOD：修改已經(jīng)注冊(cè)的fd的監(jiān)聽事件；
EPOLL_CTL_DEL：從epfd中刪除一個(gè)fd；
第三個(gè)參數(shù)是需要監(jiān)聽的fd，第四個(gè)參數(shù)是告訴內(nèi)核需要監(jiān)聽什么事，struct epoll_event結(jié)構(gòu)如下：
struct epoll_event {
__uint32_t events; /* Epoll events */
epoll_data_t data; /* User data variable */
};
events可以是以下幾個(gè)宏的集合：
EPOLLIN ：表示對(duì)應(yīng)的文件描述符可以讀（包括對(duì)端SOCKET正常關(guān)閉）；
EPOLLOUT：表示對(duì)應(yīng)的文件描述符可以寫；
EPOLLPRI：表示對(duì)應(yīng)的文件描述符有緊急的數(shù)據(jù)可讀（這里應(yīng)該表示有帶外數(shù)據(jù)到來）；
EPOLLERR：表示對(duì)應(yīng)的文件描述符發(fā)生錯(cuò)誤；
EPOLLHUP：表示對(duì)應(yīng)的文件描述符被掛斷；
EPOLLET： 將EPOLL設(shè)為邊緣觸發(fā)(Edge Triggered)模式，這是相對(duì)于水平觸發(fā)(Level Triggered)來說的。
EPOLLONESHOT：只監(jiān)聽一次事件，當(dāng)監(jiān)聽完這次事件之后，如果還需要繼續(xù)監(jiān)聽這個(gè)socket的話，需要再次把這個(gè)socket加入到EPOLL隊(duì)列里
3. int epoll_wait(int epfd, struct epoll_event * events, int maxevents, int timeout);
等待事件的產(chǎn)生，類似于select()調(diào)用。參數(shù)events用來從內(nèi)核得到事件的集合，maxevents告之內(nèi)核這個(gè)events有多大，這個(gè)maxevents的值不能大于創(chuàng)建epoll_create()時(shí)的size，參數(shù)timeout是超時(shí)時(shí)間（毫秒，0會(huì)立即返回，-1將不確定，也有說法說是永久阻塞）。該函數(shù)返回需要處理的事件數(shù)目，如返回0表示已超時(shí)。
--------------------------------------------------------------------------------------------
從man手冊(cè)中，得到ET和LT的具體描述如下
EPOLL事件有兩種模型：
Edge Triggered (ET)
Level Triggered (LT)
假如有這樣一個(gè)例子：
1. 我們已經(jīng)把一個(gè)用來從管道中讀取數(shù)據(jù)的文件句柄(RFD)添加到epoll描述符
2. 這個(gè)時(shí)候從管道的另一端被寫入了2KB的數(shù)據(jù)
3. 調(diào)用epoll_wait(2)，并且它會(huì)返回RFD，說明它已經(jīng)準(zhǔn)備好讀取操作
4. 然后我們讀取了1KB的數(shù)據(jù)
5. 調(diào)用epoll_wait(2)......
Edge Triggered 工作模式：
如果我們?cè)诘?步將RFD添加到epoll描述符的時(shí)候使用了EPOLLET標(biāo)志，那么在第5步調(diào)用epoll_wait(2)之后將有可能會(huì)掛起，因?yàn)槭Ｓ嗟臄?shù)據(jù)還存在于文件的輸入緩沖區(qū)內(nèi)，而且數(shù)據(jù)發(fā)出端還在等待一個(gè)針對(duì)已經(jīng)發(fā)出數(shù)據(jù)的反饋信息。只有在監(jiān)視的文件句柄上發(fā)生了某個(gè)事件的時(shí)候 ET 工作模式才會(huì)匯報(bào)事件。因此在第5步的時(shí)候，調(diào)用者可能會(huì)放棄等待仍在存在于文件輸入緩沖區(qū)內(nèi)的剩余數(shù)據(jù)。在上面的例子中，會(huì)有一個(gè)事件產(chǎn)生在RFD句柄上，因?yàn)樵诘?步執(zhí)行了一個(gè)寫操作，然后，事件將會(huì)在第3步被銷毀。因?yàn)榈?步的讀取操作沒有讀空文件輸入緩沖區(qū)內(nèi)的數(shù)據(jù)，因此我們?cè)诘?步調(diào)用 epoll_wait(2)完成后，是否掛起是不確定的。epoll工作在ET模式的時(shí)候，必須使用非阻塞套接口，以避免由于一個(gè)文件句柄的阻塞讀/阻塞寫操作把處理多個(gè)文件描述符的任務(wù)餓死。最好以下面的方式調(diào)用ET模式的epoll接口，在后面會(huì)介紹避免可能的缺陷。
i 基于非阻塞文件句柄
ii 只有當(dāng)read(2)或者write(2)返回EAGAIN時(shí)才需要掛起，等待。但這并不是說每次read()時(shí)都需要循環(huán)讀，直到讀到產(chǎn)生一個(gè)EAGAIN才認(rèn)為此次事件處理完成，當(dāng)read()返回的讀到的數(shù)據(jù)長(zhǎng)度小于請(qǐng)求的數(shù)據(jù)長(zhǎng)度時(shí)，就可以確定此時(shí)緩沖中已沒有數(shù)據(jù)了，也就可以認(rèn)為此事讀事件已處理完成。
Level Triggered 工作模式
相反的，以LT方式調(diào)用epoll接口的時(shí)候，它就相當(dāng)于一個(gè)速度比較快的poll(2)，并且無論后面的數(shù)據(jù)是否被使用，因此他們具有同樣的職能。因?yàn)榧词故褂肊T模式的epoll，在收到多個(gè)chunk的數(shù)據(jù)的時(shí)候仍然會(huì)產(chǎn)生多個(gè)事件。調(diào)用者可以設(shè)定EPOLLONESHOT標(biāo)志，在 epoll_wait(2)收到事件后epoll會(huì)與事件關(guān)聯(lián)的文件句柄從epoll描述符中禁止掉。因此當(dāng)EPOLLONESHOT設(shè)定后，使用帶有 EPOLL_CTL_MOD標(biāo)志的epoll_ctl(2)處理文件句柄就成為調(diào)用者必須作的事情。
然后詳細(xì)解釋ET, LT:
LT(level triggered)是缺省的工作方式，并且同時(shí)支持block和no-block socket.在這種做法中，內(nèi)核告訴你一個(gè)文件描述符是否就緒了，然后你可以對(duì)這個(gè)就緒的fd進(jìn)行IO操作。如果你不作任何操作，內(nèi)核還是會(huì)繼續(xù)通知你的，所以，這種模式編程出錯(cuò)誤可能性要小一點(diǎn)。傳統(tǒng)的select/poll都是這種模型的代表．
ET(edge-triggered)是高速工作方式，只支持no-block socket。在這種模式下，當(dāng)描述符從未就緒變?yōu)榫途w時(shí)，內(nèi)核通過epoll告訴你。然后它會(huì)假設(shè)你知道文件描述符已經(jīng)就緒，并且不會(huì)再為那個(gè)文件描述符發(fā)送更多的就緒通知，直到你做了某些操作導(dǎo)致那個(gè)文件描述符不再為就緒狀態(tài)了(比如，你在發(fā)送，接收或者接收請(qǐng)求，或者發(fā)送接收的數(shù)據(jù)少于一定量時(shí)導(dǎo)致了一個(gè)EWOULDBLOCK 錯(cuò)誤）。但是請(qǐng)注意，如果一直不對(duì)這個(gè)fd作IO操作(從而導(dǎo)致它再次變成未就緒)，內(nèi)核不會(huì)發(fā)送更多的通知(only once),不過在TCP協(xié)議中，ET模式的加速效用仍需要更多的benchmark確認(rèn)（這句話不理解）。
在許多測(cè)試中我們會(huì)看到如果沒有大量的idle -connection或者dead-connection，epoll的效率并不會(huì)比select/poll高很多，但是當(dāng)我們遇到大量的idle- connection(例如WAN環(huán)境中存在大量的慢速連接)，就會(huì)發(fā)現(xiàn)epoll的效率大大高于select/poll。（未測(cè)試）
另外，當(dāng)使用epoll的ET模型來工作時(shí)，當(dāng)產(chǎn)生了一個(gè)EPOLLIN事件后，
讀數(shù)據(jù)的時(shí)候需要考慮的是當(dāng)recv()返回的大小如果等于請(qǐng)求的大小，那么很有可能是緩沖區(qū)還有數(shù)據(jù)未讀完，也意味著該次事件還沒有處理完，所以還需要再次讀取：
while(rs)
{
buflen = recv(activeevents[i].data.fd, buf, sizeof(buf), 0);
if(buflen < 0)
{
// 由于是非阻塞的模式,所以當(dāng)errno為EAGAIN時(shí),表示當(dāng)前緩沖區(qū)已無數(shù)據(jù)可讀
// 在這里就當(dāng)作是該次事件已處理處.
if(errno == EAGAIN)
break;
else
return;
}
else if(buflen == 0)
{
// 這里表示對(duì)端的socket已正常關(guān)閉.
}
if(buflen == sizeof(buf)
rs = 1; // 需要再次讀取
else
rs = 0;
}
還有，假如發(fā)送端流量大于接收端的流量(意思是epoll所在的程序讀比轉(zhuǎn)發(fā)的socket要快),由于是非阻塞的socket,那么send()函數(shù)雖然返回,但實(shí)際緩沖區(qū)的數(shù)據(jù)并未真正發(fā)給接收端,這樣不斷的讀和發(fā)，當(dāng)緩沖區(qū)滿后會(huì)產(chǎn)生EAGAIN錯(cuò)誤(參考man send),同時(shí),不理會(huì)這次請(qǐng)求發(fā)送的數(shù)據(jù).所以,需要封裝socket_send()的函數(shù)用來處理這種情況,該函數(shù)會(huì)盡量將數(shù)據(jù)寫完再返回，返回-1表示出錯(cuò)。在socket_send()內(nèi)部,當(dāng)寫緩沖已滿(send()返回-1,且errno為EAGAIN),那么會(huì)等待后再重試.這種方式并不很完美,在理論上可能會(huì)長(zhǎng)時(shí)間的阻塞在socket_send()內(nèi)部,但暫沒有更好的辦法.
ssize_t socket_send(int sockfd, const char* buffer, size_t buflen)
{
ssize_t tmp;
size_t total = buflen;
const char *p = buffer;
while(1)
{
tmp = send(sockfd, p, total, 0);
if(tmp < 0)
{
// 當(dāng)send收到信號(hào)時(shí),可以繼續(xù)寫,但這里返回-1.
if(errno == EINTR)
return -1;
// 當(dāng)socket是非阻塞時(shí),如返回此錯(cuò)誤,表示寫緩沖隊(duì)列已滿,
// 在這里做延時(shí)后再重試.
if(errno == EAGAIN)
{
usleep(1000);
continue;
}
return -1;
}
if((size_t)tmp == total)
return buflen;
total -= tmp;
p += tmp;
}
return tmp;
}