Epoll模型

Epoll模型

相比於select，epoll最大的好處在於它不會隨着監聽fd數目的增加而下降效率。由於在內核中的select實現中，它是採用輪詢來處理的，輪詢的fd數目越多，天然耗時越多。而且，在linux/posix_types.h頭文件有這樣的聲明：

#define __FD_SETSIZE    1024

表示select最多同時監聽1024個fd，固然，能夠經過修改頭文件再重編譯內核來擴大這個數目，但這彷佛並不治本。

 

經常使用模型的特色

Linux 下設計併發網絡程序，有典型的 Apache 模型（ Process Per Connection ，簡稱 PPC ）， TPC （ Thread Per Connection ）模型，以及 select 模型和 poll 模型。

1 、PPC/TPC 模型

這兩種模型思想相似，就是讓每個到來的鏈接一邊本身作事去，別再來煩我 。只是 PPC 是爲它開了一個進程，而 TPC 開了一個線程。但是別煩我是有代價的，它要時間和空間啊，鏈接多了以後，那麼多的進程 / 線程切換，這開銷就上來了；所以這類模型能接受的最大鏈接數都不會高，通常在幾百個左右。

2 、select 模型

　　1. 最大併發數限制，由於一個進程所打開的 FD （文件描述符）是有限制的，由 FD_SETSIZE 設置，默認值是 1024/2048 ，所以 Select 模型的最大併發數就被相應限制了。本身改改這個 FD_SETSIZE ？想法雖好，但是先看看下面吧 …

　　2. 效率問題， select 每次調用都會線性掃描所有的 FD 集合，這樣效率就會呈現線性降低，把 FD_SETSIZE 改大的後果就是，你們都慢慢來，什麼？都超時了？？！！

　　3. 內核 / 用戶空間 內存拷貝問題，如何讓內核把 FD 消息通知給用戶空間呢？在這個問題上 select 採起了內存拷貝方法。

三、 poll 模型

　　基本上效率和 select 是相同的， select 缺點的 2 和 3 它都沒有改掉。

 

Epoll 的提高

Epoll 的改進之處。

　　1. Epoll 沒有最大併發鏈接的限制，上限是最大能夠打開文件的數目，這個數字通常遠大於 2048, 通常來講這個數目和系統內存關係很大 ，具體數目能夠 cat /proc/sys/fs/file-max 察看。

　　2. 效率提高， Epoll 最大的優勢就在於它只管你「活躍」的鏈接 ，而跟鏈接總數無關，所以在實際的網絡環境中， Epoll 的效率就會遠遠高於 select 和 poll 。

　　3. 內存拷貝， Epoll 在這點上使用了「共享內存 」，這個內存拷貝也省略了。

 

Epoll 爲何高效

Epoll 的高效和其數據結構的設計是密不可分的。

首先回憶一下 select 模型，當有 I/O 事件到來時， select 通知應用程序有事件到了快去處理，而應用程序必須輪詢全部的 FD 集合，測試每一個 FD 是否有事件發生，並處理事件。

 

int res = select(maxfd+1, &readfds, NULL, NULL, 120);

if (res > 0)

{

    for (int i = 0; i < MAX_CONNECTION; i++)

    {

        if (FD_ISSET(allConnection[i], &readfds))

        {

            handleEvent(allConnection[i]);

        }

    }

}

// if(res == 0) handle timeout, res < 0 handle error

 

Epoll 不只會告訴應用程序有I/0 事件到來，還會告訴應用程序相關的信息，這些信息是應用程序填充的，所以根據這些信息應用程序就能直接定位到事件，而沒必要遍歷整個FD 集合。

int res = epoll_wait(epfd, events, 20, 120);

for (int i = 0; i < res;i++)

{

    handleEvent(events[n]);

}

 

epoll的接口很是簡單，一共就三個函數：

1. int epoll_create(int size);

建立一個epoll的句柄，size用來告訴內核這個監聽的數目一共有多大。這個參數不一樣於select()中的第一個參數，給出最大監聽的fd+1的值。須要注意的是，當建立好epoll句柄後，它就是會佔用一個fd值，在linux下若是查看/proc/進程id/fd/，是可以看到這個fd的，因此在使用完epoll後，必須調用close()關閉，不然可能致使fd被耗盡。

 

2. int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event);

epoll的事件註冊函數，它不一樣與select()是在監聽事件時告訴內核要監聽什麼類型的事件，而是在這裏先註冊要監聽的事件類型。控制某個 Epoll 文件描述符上的事件：註冊、修改、刪除。

 

第一個參數是epoll_create()的返回值，建立 Epoll 專用的文件描述符。相對於 select 模型中的 FD_SET 和 FD_CLR 宏。

第二個參數表示動做，用三個宏來表示：

EPOLL_CTL_ADD：註冊新的fd到epfd中；

EPOLL_CTL_MOD：修改已經註冊的fd的監聽事件；

EPOLL_CTL_DEL：從epfd中刪除一個fd；

第三個參數是須要監聽的fd，

第四個參數是告訴內核須要監聽什麼事，struct epoll_event結構以下：

struct epoll_event {

 　　 __uint32_t events;  /* Epoll events */

  　　epoll_data_t data;  /* User data variable */

　　};

 

events能夠是如下幾個宏的集合：

　　EPOLLIN ：     表示對應的文件描述符能夠讀（包括對端SOCKET正常關閉）；

　　EPOLLOUT：    表示對應的文件描述符能夠寫；

　　EPOLLPRI：      表示對應的文件描述符有緊急的數據可讀（這裏應該表示有帶外數據到來）；

　　EPOLLERR：     表示對應的文件描述符發生錯誤；

　　EPOLLHUP：     表示對應的文件描述符被掛斷；

　　EPOLLET：      將EPOLL設爲邊緣觸發(Edge Triggered)模式，這是相對於水平觸發(Level Triggered)來講的。

　　EPOLLONESHOT： 只監聽一次事件，當監聽完此次事件以後，若是還須要繼續監聽這個socket的話，須要再次把這個socket加入到EPOLL隊列裏

 

3. int epoll_wait(int epfd, struct epoll_event * events, int maxevents, int timeout);

　等待 I/O 事件的發生；參數說明：

　　epfd: 由 epoll_create() 生成的 Epoll 專用的文件描述符；

　　epoll_event: 用於回傳代處理事件的數組；

　　maxevents: 每次能處理的事件數；

　　timeout: 等待 I/O 事件發生的超時值；

　　返回發生事件數。

　　相對於 select 模型中的 select 函數。

　　參數events用來從內核獲得事件的集合，maxevents告以內核這個events有多大，這個maxevents的值不能大於建立epoll_create()時的size，參數timeout是超時時間（毫秒，0會當即返回，-1將不肯定，也有說法說是永久阻塞）。該函數返回須要處理的事件數目，如返回0表示已超時。

　　生成一個 Epoll 專用的文件描述符，實際上是申請一個內核空間，用來存放你想關注的 socket fd 上是否發生以及發生了什麼事件。 size 就是你在這個 Epoll fd 上能關注的最大 socket fd 數，大小自定，只要內存足夠。

 

EPOLL事件有兩種模型：

Edge Triggered (ET)  邊緣觸發 只有數據到來，才觸發，無論緩存區中是否還有數據。

Level Triggered (LT)  水平觸發 只要有數據都會觸發。

 

例如：

1. 咱們已經把一個用來從管道中讀取數據的文件句柄(RFD)添加到epoll描述符

2. 這個時候從管道的另外一端被寫入了2KB的數據

3. 調用epoll_wait(2)，而且它會返回RFD，說明它已經準備好讀取操做

4. 而後咱們讀取了1KB的數據

5. 調用epoll_wait(2)......

 

Edge Triggered 工做模式：

若是咱們在第1步將RFD添加到epoll描述符的時候使用了EPOLLET標誌，那麼在第5步調用epoll_wait(2)以後將有可能會掛起，由於剩餘的數據還存在於文件的輸入緩衝區內，並且數據發出端還在等待一個針對已經發出數據的反饋信息。只有在監視的文件句柄上發生了某個事件的時候 ET 工做模式纔會彙報事件。所以在第5步的時候，調用者可能會放棄等待仍在存在於文件輸入緩衝區內的剩餘數據。在上面的例子中，會有一個事件產生在RFD句柄上，由於在第2步執行了一個寫操做，而後，事件將會在第3步被銷燬。由於第4步的讀取操做沒有讀空文件輸入緩衝區內的數據，所以咱們在第5步調用 epoll_wait(2)完成後，是否掛起是不肯定的。epoll工做在ET模式的時候，必須使用非阻塞套接口，以免因爲一個文件句柄的阻塞讀/阻塞寫操做把處理多個文件描述符的任務餓死。最好如下面的方式調用ET模式的epoll接口，在後面會介紹避免可能的缺陷。

   i    基於非阻塞文件句柄

   ii   只有當read(2)或者write(2)返回EAGAIN時才須要掛起，等待。但這並非說每次read()時都須要循環讀，直到讀到產生一個EAGAIN才認爲這次事件處理完成，當read()返回的讀到的數據長度小於請求的數據長度時，就能夠肯定此時緩衝中已沒有數據了，也就能夠認爲此事讀事件已處理完成。

 

Level Triggered 工做模式

相反的，以LT方式調用epoll接口的時候，它就至關於一個速度比較快的poll(2)，而且不管後面的數據是否被使用，所以他們具備一樣的職能。由於即便使用ET模式的epoll，在收到多個chunk的數據的時候仍然會產生多個事件。調用者能夠設定EPOLLONESHOT標誌，在 epoll_wait(2)收到事件後epoll會與事件關聯的文件句柄從epoll描述符中禁止掉。所以當EPOLLONESHOT設定後，使用帶有 EPOLL_CTL_MOD標誌的epoll_ctl(2)處理文件句柄就成爲調用者必須做的事情。

詳細解釋ET, LT:

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確認（這句話不理解）。

 

在許多測試中咱們會看到若是沒有大量的idle -connection或者dead-connection，epoll的效率並不會比select/poll高不少，可是當咱們遇到大量的idle- connection(例如WAN環境中存在大量的慢速鏈接)，就會發現epoll的效率大大高於select/poll。（未測試）

 

另外，當使用epoll的ET模型來工做時，當產生了一個EPOLLIN事件後，

讀數據的時候須要考慮的是當recv()返回的大小若是等於請求的大小，那麼頗有多是緩衝區還有數據未讀完，也意味着該次事件尚未處理完，因此還須要再次讀取：

while(rs)

{

  buflen = recv(activeevents[i].data.fd, buf, sizeof(buf), 0);

  if(buflen < 0)

  {

    // 因爲是非阻塞的模式,因此當errno爲EAGAIN時,表示當前緩衝區已無數據可讀

    // 在這裏就看成是該次事件已處理處.

    if(errno == EAGAIN)

     break;

    else

     return;

   }

   else if(buflen == 0)

   {

     // 這裏表示對端的socket已正常關閉.

   }

   if(buflen == sizeof(buf)

     rs = 1;   // 須要再次讀取

   else

     rs = 0;

}

還有，假如發送端流量大於接收端的流量(意思是epoll所在的程序讀比轉發的socket要快),因爲是非阻塞的socket,那麼send()函數雖然返回,但實際緩衝區的數據並未真正發給接收端,這樣不斷的讀和發，當緩衝區滿後會產生EAGAIN錯誤(參考man send),同時,不理會此次請求發送的數據.因此,須要封裝socket_send()的函數用來處理這種狀況,該函數會盡可能將數據寫完再返回，返回-1表示出錯。在socket_send()內部,當寫緩衝已滿(send()返回-1,且errno爲EAGAIN),那麼會等待後再重試.這種方式並不很完美,在理論上可能會長時間的阻塞在socket_send()內部,但暫沒有更好的辦法.

 

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)

    {

      // 當send收到信號時,能夠繼續寫,但這裏返回-1.

      if(errno == EINTR)

        return -1;

      // 當socket是非阻塞時,如返回此錯誤,表示寫緩衝隊列已滿,

      // 在這裏作延時後再重試.

      if(errno == EAGAIN)

      {

        usleep(1000);

        continue;

      }

      return -1;

    }

    if((size_t)tmp == total)

      return buflen;

    total -= tmp;

    p += tmp;

  }

 

  return tmp;

}