Epoll模型詳解

Linux 2.6內核中提升網絡I/O性能的新方法-epoll I/O多路複用技術在比較多的TCP網絡服務器中有使用，即比較多的用到select函數。

一、爲何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而已。

二、內核中提升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內核成爲正式的解決方案

三、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網 卡驅動架構。

四、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的配合。

五、 epoll的使用方法
    首先經過create_epoll(int maxfds)來建立一個epoll的句柄，其中maxfds爲你epoll所支持的最大句柄數。這個函數會返回一個新的epoll句柄，以後的全部操做 將經過這個句柄來進行操做。在用完以後，記得用close()來關閉這個建立出來的epoll句柄。以後在你的網絡主循環裏面，每一幀的調用 epoll_wait(int epfd, epoll_event events, int max events, int timeout)來查詢全部的網絡接口，看哪個能夠讀，哪個能夠寫了。基本的語法爲：
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模型主要負責對大量併發用戶的請求進行及時處理，完成服務器與客戶端的數據交互。其具體的實現步驟以下：
(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描述符加入可讀隊列，通知接收線程讀入數據，並將接收到的數據放入到接收數據 的鏈表中，經邏輯處理後，將反饋的數據包放入到發送數據鏈表中，等待由發送線程發送。

 

 

 

 

C++語言:  epoll使用方法1

01 //epoll_wait範圍以後應該是一個循環，遍利全部的事件：
02 for (n = 0; n < nfds; ++n)
03 {
04         if (events[n].data.fd == listener)
05         {//若是是主socket的事件的話，則表示有新鏈接進入了，進行新鏈接的處理。
06                 client = accept (listener, (struct sockaddr *) &local, &addrlen);
07                 if (client < 0)
08                 {
09                         perror ("accept");
10                         continue;
11                 }
12                 setnonblocking (client);        // 將新鏈接置於非阻塞模式
13                 ev.events = EPOLLIN | EPOLLET; // 而且將新鏈接也加入EPOLL的監聽隊列。
14                 //注意，這裏的參數EPOLLIN | EPOLLET並無設置對寫socket的監聽，
15                 //若是有寫操做的話，這個時候epoll是不會返回事件的，
16                 //若是要對寫操做也監聽的話，應該是EPOLLIN | EPOLLOUT | EPOLLET
17                 ev.data.fd = client;
18                 if (epoll_ctl (kdpfd, EPOLL_CTL_ADD, client, &ev) < 0)
19                 {
20                         /*
21                                 設置好event以後，將這個新的event經過epoll_ctl加入到epoll的監聽隊列裏面，
22                                 這裏用EPOLL_CTL_ADD來加一個新的epoll事件,經過EPOLL_CTL_DEL來減小一個epoll事件，通
23                                 過EPOLL_CTL_MOD來改變一個事件的監聽方式.
24                         */
25                         fprintf (stderr, "epoll set insertion error: fd=%d", client);
26                         return -1;
27                 }
28         }
29         else                                                            // 若是不是主socket的事件的話，則表明是一個用戶socket的事件，
30                 do_use_fd (events[n].data.fd); //則來處理這個用戶socket的事情，好比說read(fd,xxx)之類的，或者一些其餘的處理。
31 }

    對，epoll的操做就這麼簡單，總共不過4個 API：epoll_create, epoll_ctl, epoll_wait和close。
若是您對epoll的效率還不太瞭解，請參考我 以前關於網絡遊戲的網絡編程等相關的文章。

    之前公司的服務器都是使用HTTP鏈接，可是這樣的話，在手機目前的網絡狀況下不但顯得速度較慢，並且不穩定。所以你們一致贊成用 SOCKET來進行鏈接。雖然使用SOCKET以後，對於用戶的費用可能會增長(因爲是用了CMNET而非CMWAP)，可是，秉着用戶體驗至上的原則， 相信你們仍是可以接受的(但願那些玩家月末收到賬單不後可以保持克制...)。
此次的服務器設計中，最重要的一個突破，是使用了EPOLL模型， 雖然對之也是隻知其一;不知其二，可是既然在各大PC網遊中已經通過了如此嚴酷的考驗，相信他不會讓咱們失望，使用後的結果，確實也是表現至關不錯。在這裏，我仍是 主要大體介紹一下這個模型的結構。
六、Linux下EPOll編程實例
EPOLL模型彷佛只有一種格式，因此你們只要參考我下面的代碼， 就可以對EPOLL有所瞭解了，代碼的解釋都已經在註釋中：

 

C++語言:  Codee#11763

01 while (TRUE)
02 {
03         int nfds = epoll_wait (m_epoll_fd, m_events, MAX_EVENTS,EPOLL_TIME_OUT);       //等待EPOLL時間的發生，至關於監聽，
04         //至於相關的端口，須要在初始化EPOLL的時候綁定。
05         if (nfds <= 0)
06                 continue;
07         m_bOnTimeChecking = FALSE;
08         G_CurTime = time (NULL);
09         for (int i = 0; i < nfds; i++)
10         {
11                 try
12                 {
13                         if (m_events[i].data.fd == m_listen_http_fd)    //若是新監測到一個HTTP用戶鏈接到綁定的HTTP端口，
14                                 //創建新的鏈接。因爲咱們新採用了SOCKET鏈接，因此基本沒用。
15                         {
16                                 OnAcceptHttpEpoll ();
17                         }
18                         else if (m_events[i].data.fd == m_listen_sock_fd)       //若是新監測到一個SOCKET用戶鏈接到了綁定的SOCKET端口，
19                                 //創建新的鏈接。
20                         {
21                                 OnAcceptSockEpoll ();
22                         }
23                         else if (m_events[i].events & EPOLLIN) //若是是已經鏈接的用戶，而且收到數據，那麼進行讀入。
24                         {
25                                 OnReadEpoll (i);
26                         }
27 
28                         OnWriteEpoll (i);       //查看當前的活動鏈接是否有須要寫出的數據。
29                 }
30                 catch (int)
31                 {
32                         PRINTF ("CATCH捕獲錯誤\n");
33                         continue;
34                 }
35         }
36         m_bOnTimeChecking = TRUE;
37         OnTimer ();                                     //進行一些定時的操做，主要就是刪除一些短線用戶等。
38 }

    其實EPOLL的精華，也就是上述的幾段短短的代碼，看來時代真的不一樣了，之前如何接受大量用戶鏈接的問題，如今卻被如此輕鬆的搞定，真是讓人不得不感 嘆，對哪。