1. 程式人生 > >Epoll模型【轉】

Epoll模型【轉】

轉自:https://www.cnblogs.com/tianhangzhang/p/5295972.html

相比於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 採取了記憶體拷貝方法。

3、 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;

}