Linux 2.6內核中提高網絡I/O性能的新方法-epoll I/O多路復用技術在比較多的TCP網絡服務器中有使用，即比較多的用到select函數。
1、為什么select落后
首先，在Linux內核中，select所用到的FD_SET是有限的，即內核中有個參數__FD_SETSIZE定義了每個FD_SET的句柄個數，在我用的2.6.15-25-386內核中，該值是1024，搜索內核源代碼得到：
include/linux/posix_types.h:
#define __FD_SETSIZE 1024
也就是說，如果想要同時檢測1025個句柄的可讀狀態是不可能用select實現的。或者同時檢測1025個句柄的可寫狀態也是不可能的。其次，內核中實現 select是用輪詢方法，即每次檢測都會遍歷所有FD_SET中的句柄，顯然，select函數執行時間與FD_SET中的句柄個數有一個比例關系，即 select要檢測的句柄數越多就會越費時。當然，在前文中我并沒有提及poll方法，事實上用select的朋友一定也試過poll，我個人覺得 select和poll大同小異，個人偏好于用select而已。
2、內核中提高I/O性能的新方法epoll
epoll是什么？按照man手冊的說法：是為處理大批量句柄而作了改進的poll。要使用epoll只需要這三個系統調用：epoll_create(2)， epoll_ctl(2)， epoll_wait(2)。
當然，這不是2.6內核才有的，它是在2.5.44內核中被引進的(epoll(4) is a new API introduced in Linux kernel 2.5.44)
Linux2.6內核epoll介紹
先介紹2本書《The Linux Networking Architecture--Design and Implementation of Network Protocols in the Linux Kernel》，以2.4內核講解Linux TCP/IP實現，相當不錯.作為一個現實世界中的實現，很多時候你必須作很多權衡，這時候參考一個久經考驗的系統更有實際意義。舉個例子,linux內核中sk_buff結構為了追求速度和安全，犧牲了部分內存，所以在發送TCP包的時候，無論應用層數據多大,sk_buff最小也有272的字節.其實對于socket應用層程序來說，另外一本書《UNIX Network Programming Volume 1》意義更大一點.2003年的時候，這本書出了最新的第3版本，不過主要還是修訂第2版本。其中第6章《I/O Multiplexing》是最重要的。Stevens給出了網絡IO的基本模型。在這里最重要的莫過于select模型和Asynchronous I/O模型.從理論上說，AIO似乎是最高效的，你的IO操作可以立即返回，然后等待os告訴你IO操作完成。但是一直以來，如何實現就沒有一個完美的方案。最著名的windows完成端口實現的AIO,實際上也是內部用線程池實現的罷了，最后的結果是IO有個線程池，你應用也需要一個線程池...... 很多文檔其實已經指出了這帶來的線程context-switch帶來的代價。在linux 平臺上，關于網絡AIO一直是改動最多的地方，2.4的年代就有很多AIO內核patch,最著名的應該算是SGI那個。但是一直到2.6內核發布，網絡模塊的AIO一直沒有進入穩定內核版本(大部分都是使用用戶線程模擬方法，在使用了NPTL的linux上面其實和windows的完成端口基本上差不多了)。2.6內核所支持的AIO特指磁盤的AIO---支持io_submit(),io_getevents()以及對Direct IO的支持(就是繞過VFS系統buffer直接寫硬盤，對于流服務器在內存平穩性上有相當幫助)。
所以，剩下的select模型基本上就是我們在linux上面的唯一選擇，其實，如果加上no-block socket的配置，可以完成一個"偽"AIO的實現，只不過推動力在于你而不是os而已。不過傳統的select/poll函數有著一些無法忍受的缺點，所以改進一直是2.4-2.5開發版本內核的任務，包括/dev/poll，realtime signal等等。最終，Davide Libenzi開發的epoll進入2.6內核成為正式的解決方案
3、epoll的優點
<1>支持一個進程打開大數目的socket描述符(FD)
select 最不能忍受的是一個進程所打開的FD是有一定限制的，由FD_SETSIZE設置，默認值是2048。對于那些需要支持的上萬連接數目的IM服務器來說顯然太少了。這時候你一是可以選擇修改這個宏然后重新編譯內核，不過資料也同時指出這樣會帶來網絡效率的下降，二是可以選擇多進程的解決方案(傳統的 Apache方案)，不過雖然linux上面創建進程的代價比較小，但仍舊是不可忽視的，加上進程間數據同步遠比不上線程間同步的高效，所以也不是一種完美的方案。不過 epoll則沒有這個限制，它所支持的FD上限是最大可以打開文件的數目，這個數字一般遠大于2048,舉個例子,在1GB內存的機器上大約是10萬左右，具體數目可以cat /proc/sys/fs/file-max察看,一般來說這個數目和系統內存關系很大。
<2>IO效率不隨FD數目增加而線性下降
傳統的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之上了。
<3>使用mmap加速內核與用戶空間的消息傳遞。
這點實際上涉及到epoll的具體實現了。無論是select,poll還是epoll都需要內核把FD消息通知給用戶空間，如何避免不必要的內存拷貝就很重要，在這點上，epoll是通過內核于用戶空間mmap同一塊內存實現的。而如果你想我一樣從2.5內核就關注epoll的話，一定不會忘記手工 mmap這一步的。
<4>內核微調
這一點其實不算epoll的優點了，而是整個linux平臺的優點。也許你可以懷疑 linux平臺，但是你無法回避linux平臺賦予你微調內核的能力。比如，內核TCP/IP協議棧使用內存池管理sk_buff結構，那么可以在運行時期動態調整這個內存pool(skb_head_pool)的大小--- 通過echo XXXX>/proc/sys/net/core/hot_list_length完成。再比如listen函數的第2個參數(TCP完成3次握手的數據包隊列長度)，也可以根據你平臺內存大小動態調整。更甚至在一個數據包面數目巨大但同時每個數據包本身大小卻很小的特殊系統上嘗試最新的NAPI網卡驅動架構。
4、epoll的工作模式
令人高興的是，2.6內核的epoll比其2.5開發版本的/dev/epoll簡潔了許多，所以，大部分情況下，強大的東西往往是簡單的。唯一有點麻煩是epoll有2種工作方式:LT和ET。
LT(level triggered)是缺省的工作方式，并且同時支持block和no-block socket.在這種做法中，內核告訴你一個文件描述符是否就緒了，然后你可以對這個就緒的fd進行IO操作。如果你不作任何操作，內核還是會繼續通知你的，所以，這種模式編程出錯誤可能性要小一點。傳統的select/poll都是這種模型的代表．
ET (edge-triggered)是高速工作方式，只支持no-block socket。在這種模式下，當描述符從未就緒變為就緒時，內核通過epoll告訴你。然后它會假設你知道文件描述符已經就緒，并且不會再為那個文件描述符發送更多的就緒通知，直到你做了某些操作導致那個文件描述符不再為就緒狀態了(比如，你在發送，接收或者接收請求，或者發送接收的數據少于一定量時導致了一個EWOULDBLOCK 錯誤）。但是請注意，如果一直不對這個fd作IO操作(從而導致它再次變成未就緒)，內核不會發送更多的通知(only once),不過在TCP協議中，ET模式的加速效用仍需要更多的benchmark確認。
epoll只有epoll_create,epoll_ctl,epoll_wait 3個系統調用，具體用法請參考http://www.xmailserver.org/linux-patches/nio-improve.html ，在http://www.kegel.com/rn/也有一個完整的例子，大家一看就知道如何使用了
Leader/follower模式線程pool實現，以及和epoll的配合。
5、 epoll的使用方法
首先通過create_epoll(int maxfds)來創建一個epoll的句柄，其中maxfds為你epoll所支持的最大句柄數。這個函數會返回一個新的epoll句柄，之后的所有操作將通過這個句柄來進行操作。在用完之后，記得用close()來關閉這個創建出來的epoll句柄。之后在你的網絡主循環里面，每一幀的調用epoll_wait(int epfd, epoll_event events, int max events, int timeout)來查詢所有的網絡接口，看哪一個可以讀，哪一個可以寫了?；镜恼Z法為：
nfds = epoll_wait(kdpfd, events, maxevents, -1);
其中kdpfd為用epoll_create創建之后的句柄，events是一個epoll_event*的指針，當epoll_wait這個函數操作成功之后，epoll_events里面將儲存所有的讀寫事件。max_events是當前需要監聽的所有socket句柄數。最后一個timeout是 epoll_wait的超時，為0的時候表示馬上返回，為-1的時候表示一直等下去，直到有事件范圍，為任意正整數的時候表示等這么長的時間，如果一直沒有事件，則范圍。一般如果網絡主循環是單獨的線程的話，可以用-1來等，這樣可以保證一些效率，如果是和主邏輯在同一個線程的話，則可以用0來保證主循環的效率。
epoll_wait范圍之后應該是一個循環，遍利所有的事件：
for(n = 0; n < nfds; ++n) {
if(events[n].data.fd == listener) { //如果是主socket的事件的話，則表示有新連接進入了，進行新連接的處理。
client = accept(listener, (struct sockaddr *) &local, &addrlen);
if(client < 0){
perror("accept");
continue;
}
setnonblocking(client); // 將新連接置于非阻塞模式
ev.events = EPOLLIN | EPOLLET; // 并且將新連接也加入EPOLL的監聽隊列。
//注意，這里的參數EPOLLIN | EPOLLET并沒有設置對寫socket的監聽，
//如果有寫操作的話，這個時候epoll是不會返回事件的，
//如果要對寫操作也監聽的話，應該是EPOLLIN | EPOLLOUT | EPOLLET
ev.data.fd = client;
if (epoll_ctl(kdpfd, EPOLL_CTL_ADD, client, &ev) < 0) { // 設置好event之后，將這個新的event通過epoll_ctl
//加入到epoll的監聽隊列里面，這里用EPOLL_CTL_ADD
//來加一個新的 epoll事件，通過EPOLL_CTL_DEL來減少
//一個epoll事件，通過EPOLL_CTL_MOD來改變一個事件的
//監聽方式。
fprintf(stderr, "epoll set insertion error: fd=%d0, client);
return -1;
}
} else // 如果不是主socket的事件的話，則代表是一個用戶socket的事件，
//則來處理這個用戶socket的事情，比如說read(fd,xxx)之類的，或者一些其他的處理。
do_use_fd(events[n].data.fd);
}
對，epoll的操作就這么簡單，總共不過4個API：epoll_create, epoll_ctl, epoll_wait和close。
如果您對epoll的效率還不太了解，請參考我之前關于網絡游戲的網絡編程等相關的文章。
以前公司的服務器都是使用HTTP連接，但是這樣的話，在手機目前的網絡情況下不但顯得速度較慢，而且不穩定。因此大家一致同意用 SOCKET來進行連接。雖然使用SOCKET之后，對于用戶的費用可能會增加(由于是用了CMNET而非CMWAP)，但是，秉著用戶體驗至上的原則，相信大家還是能夠接受的(希望那些玩家月末收到帳單不后能夠保持克制...)。
這次的服務器設計中，最重要的一個突破，是使用了EPOLL模型，雖然對之也是一知半解，但是既然在各大PC網游中已經經過了如此嚴酷的考驗，相信他不會讓我們失望，使用后的結果，確實也是表現相當不錯。在這里，我還是主要大致介紹一下這個模型的結構。
6、Linux下EPOll編程實例
EPOLL模型似乎只有一種格式，所以大家只要參考我下面的代碼，就能夠對EPOLL有所了解了，代碼的解釋都已經在注釋中：
while (TRUE) {
int nfds = epoll_wait (m_epoll_fd, m_events, MAX_EVENTS, EPOLL_TIME_OUT);//等待EPOLL時間的發生，相當于監聽，
//至于相關的端口，需要在初始化EPOLL的時候綁定。
if (nfds <= 0)
continue;
m_bOnTimeChecking = FALSE;
G_CurTime = time(NULL);
for (int i=0; i<nfds; i++) {
try {
if (m_events[i].data.fd == m_listen_http_fd)//如果新監測到一個HTTP用戶連接到綁定的HTTP端口，
//建立新的連接。由于我們新采用了SOCKET連接，所以基本沒用。
{
OnAcceptHttpEpoll ();
} else if (m_events[i].data.fd == m_listen_sock_fd)//如果新監測到一個SOCKET用戶連接到了綁定的SOCKET端口，
//建立新的連接。
{
OnAcceptSockEpoll ();
} else if (m_events[i].events & EPOLLIN)//如果是已經連接的用戶，并且收到數據，那么進行讀入。
{
OnReadEpoll (i);
}
OnWriteEpoll (i);//查看當前的活動連接是否有需要寫出的數據。
} catch (int) {
PRINTF ("CATCH捕獲錯誤\n");
continue;
}
}
m_bOnTimeChecking = TRUE;
OnTimer ();//進行一些定時的操作，主要就是刪除一些短線用戶等。
}
其實EPOLL的精華，也就是上述的幾段短短的代碼，看來時代真的不同了，以前如何接受大量用戶連接的問題，現在卻被如此輕松的搞定，真是讓人不得不感嘆，對哪。
Epoll模型主要負責對大量并發用戶的請求進行及時處理，完成服務器與客戶端的數據交互。其具體的實現步驟如下：
(a) 使用epoll_create()函數創建文件描述，設定將可管理的最大socket描述符數目。
(b) 創建與epoll關聯的接收線程，應用程序可以創建多個接收線程來處理epoll上的讀通知事件，線程的數量依賴于程序的具體需要。
(c) 創建一個偵聽socket描述符ListenSock；將該描述符設定為非阻塞模式，調用Listen（）函數在套接字上偵聽有無新的連接請求，在epoll_event結構中設置要處理的事件類型EPOLLIN，工作方式為 epoll_ET，以提高工作效率，同時使用epoll_ctl()注冊事件，最后啟動網絡監視線程。
(d) 網絡監視線程啟動循環，epoll_wait()等待epoll事件發生。
(e) 如果epoll事件表明有新的連接請求，則調用accept（）函數，將用戶socket描述符添加到epoll_data聯合體，同時設定該描述符為非阻塞，并在epoll_event結構中設置要處理的事件類型為讀和寫，工作方式為epoll_ET.
(f) 如果epoll事件表明socket描述符上有數據可讀，則將該socket描述符加入可讀隊列，通知接收線程讀入數據，并將接收到的數據放入到接收數據的鏈表中，經邏輯處理后，將反饋的數據包放入到發送數據鏈表中，等待由發送線程發送。