本文討論的背景是Linux環境下的network IO。
一、 概念說明
在進行解釋之前，首先要說明幾個概念：
- 用戶空間和內核空間
- 進程切換
- 進程的阻塞
- 文件描述符
- 緩存 I/O
1.1、用戶空間與內核空間
現在操作系統都是采用虛擬存儲器，那么對32位操作系統而言，它的尋址空間（虛擬存儲空間）為4G（2的32次方）。操作系統的核心是內核，獨立于普通的應用程序，可以訪問受保護的內存空間，也有訪問底層硬件設備的所有權限。為了保證用戶進程不能直接操作內核（kernel），保證內核的安全，操心系統將虛擬空間劃分為兩部分，一部分為內核空間，一部分為用戶空間。針對linux操作系統而言，將最高的1G字節（從虛擬地址0xC0000000到0xFFFFFFFF），供內核使用，稱為內核空間，而將較低的3G字節（從虛擬地址0x00000000到0xBFFFFFFF），供各個進程使用，稱為用戶空間。
1.2、進程切換
為了控制進程的執行，內核必須有能力掛起正在CPU上運行的進程，并恢復以前掛起的某個進程的執行。這種行為被稱為進程切換。因此可以說，任何進程都是在操作系統內核的支持下運行的，是與內核緊密相關的。
從一個進程的運行轉到另一個進程上運行，這個過程中經過下面這些變化：
1. 保存處理機上下文，包括程序計數器和其他寄存器。
2. 更新PCB信息。
3. 把進程的PCB移入相應的隊列，如就緒、在某事件阻塞等隊列。
4. 選擇另一個進程執行，并更新其PCB。
5. 更新內存管理的數據結構。
6. 恢復處理機上下文。
注：總而言之就是很耗資源，具體的可以參考這篇文章：進程切換
1.3、進程的阻塞
正在執行的進程，由于期待的某些事件未發生，如請求系統資源失敗、等待某種操作的完成、新數據尚未到達或無新工作做等，則由系統自動執行阻塞原語(Block)，使自己由運行狀態變為阻塞狀態。可見，進程的阻塞是進程自身的一種主動行為，也因此只有處于運行態的進程（獲得CPU），才可能將其轉為阻塞狀態。當進程進入阻塞狀態，是不占用CPU資源的。
1.4、文件描述符fd
文件描述符（File descriptor）是計算機科學中的一個術語，是一個用于表述指向文件的引用的抽象化概念。
文件描述符在形式上是一個非負整數。實際上，它是一個索引值，指向內核為每一個進程所維護的該進程打開文件的記錄表。當程序打開一個現有文件或者創建一個新文件時，內核向進程返回一個文件描述符。在程序設計中，一些涉及底層的程序編寫往往會圍繞著文件描述符展開。但是文件描述符這一概念往往只適用于UNIX、Linux這樣的操作系統。
1.5、緩存 I/O
緩存 I/O 又被稱作標準 I/O，大多數文件系統的默認 I/O 操作都是緩存 I/O。在 Linux 的緩存 I/O 機制中，操作系統會將 I/O 的數據緩存在文件系統的頁緩存（ page cache ）中，也就是說，數據會先被拷貝到操作系統內核的緩沖區中，然后才會從操作系統內核的緩沖區拷貝到應用程序的地址空間。
緩存 I/O 的缺點：
數據在傳輸過程中需要在應用程序地址空間和內核進行多次數據拷貝操作，這些數據拷貝操作所帶來的 CPU 以及內存開銷是非常大的。
二、 IO模式
剛才說了，對于一次IO訪問（以read舉例），數據會先被拷貝到操作系統內核的緩沖區中，然后才會從操作系統內核的緩沖區拷貝到應用程序的地址空間。所以說，當一個read操作發生時，它會經歷兩個階段：
- 等待數據準備 (Waiting for the data to be ready)
- 將數據從內核拷貝到進程中 (Copying the data from the kernel to the process)
正式因為這兩個階段，linux系統產生了下面五種網絡模式的方案。
- 阻塞 I/O（blocking IO）
- 非阻塞 I/O（nonblocking IO）
- I/O 多路復用（ IO multiplexing）
- 信號驅動 I/O（ signal driven IO）
- 異步 I/O（asynchronous IO）
注：由于signal driven IO在實際中并不常用，所以我這只提及剩下的四種IO Model。
三、 I/O 多路復用之select、poll、epoll詳解
select，poll，epoll都是IO多路復用的機制。I/O多路復用就是通過一種機制，一個進程可以監視多個描述符，一旦某個描述符就緒（一般是讀就緒或者寫就緒），能夠通知程序進行相應的讀寫操作。但select，poll，epoll本質上都是同步I/O，因為他們都需要在讀寫事件就緒后自己負責進行讀寫，也就是說這個讀寫過程是阻塞的，而異步I/O則無需自己負責進行讀寫，異步I/O的實現會負責把數據從內核拷貝到用戶空間。（這里啰嗦下）
3.1、select
select是1983年的4.2BSD提出。系統在select用32*32=1024位來進行查詢。返回的時候數組如readfds是已經處理過的了，返回時只有準備好事件的fd。所以需要輪訓(要用FD_ISSET挨個比較)和重新賦值。FD_ISSET（fd,&readfds）
int select (int n, fd_set *readfds, fd_set *writefds, fd_set *exceptfds, struct timeval *timeout);
select 函數監視的文件描述符分3類，分別是writefds、readfds、和exceptfds。調用后select函數會阻塞，直到有描述符就緒（有數據 可讀、可寫、或者有except），或者超時（timeout指定等待時間，如果立即返回設為null即可），函數返回。當select函數返回后，可以 通過遍歷fdset，來找到就緒的描述符。
使用方法總共分三步:
1.三個fd_set初始化，用FD_ZERO FD_SET
2.調用select
3.用fd遍歷每一個fd_set使用FD_ISSET。如果成功就處理。
select目前幾乎在所有的平臺上支持，其良好跨平臺支持也是它的一個優點。select的一個缺點在于單個進程能夠監視的文件描述符的數量存在最大限制，在Linux上一般為1024，可以通過修改宏定義甚至重新編譯內核的方式提升這一限制，但 是這樣也會造成效率的降低。
3.2、poll
int poll (struct pollfd *fds, unsigned int nfds, int timeout);
不同與select使用三個位圖來表示三個fdset的方式，poll使用一個 pollfd的指針實現。
struct pollfd {
int fd; /* file descriptor */
short events; /* requested events to watch */
short revents; /* returned events witnessed */
};
pollfd結構包含了要監視的event和發生的event，不再使用select“參數-值”傳遞的方式。同時，pollfd并沒有最大數量限制（但是數量過大后性能也是會下降）。 和select函數一樣，poll返回后，需要輪詢pollfd來獲取就緒的描述符。
從上面看，select和poll都需要在返回后，通過遍歷文件描述符來獲取已經就緒的socket。事實上，同時連接的大量客戶端在一時刻可能只有很少的處于就緒狀態，因此隨著監視的描述符數量的增長，其效率也會線性下降。
也是分三步
1.pollfd初始化，綁定sock，設置事件event，revent。設置時間限制。
2.調用poll
3.遍歷看他的事件發生了么，如果發生了置0。
3.3、epoll
epoll：一次循環
epoll是在2.6內核中提出的，是之前的select和poll的增強版本。而且只在linux下支持。相對于select和poll來說，epoll更加靈活，沒有描述符限制。epoll使用一個文件描述符管理多個描述符，將用戶關系的文件描述符的事件存放到內核的一個事件表中，這樣在用戶空間和內核空間的copy只需一次。
epoll是直接在內核里的，用戶調用系統調用去注冊，因此省去了每次的復制和輪詢的消耗。這兒用了三個系統調用，epollcreate只要每次調用開始調用一次創造一個epoll就可以了。然后用epoll_ctl來進行添加事件，其實就是注冊到內核管理的epoll里。然后直接epoll_wait就可以了。系統會返回系統調用的。
使用方法
1.準備工作多了，很復雜，這個記錄數據在內核里。
1)構建epoll描述符，通過調用epoll_create
2)用需要的時間和上下文數據指針初始化。
3)調用epoll_ctl 添加文件描述符。
4)調用epoll_wait每次處理20個事件。這兒是接收一個空數組，然后填上東西。也就是有200個東西過來，我可能只填了一個。當然如果50個完成了也是回復20.剩下的不會被漏掉，下次再來處理。
5)遍歷返回的數據。注意這兒返回的都是有用的東西。
3.3.1、 epoll操作過程
epoll操作過程需要三個接口，分別如下：
int epoll_create(int size)；//創建一個epoll的句柄，size用來告訴內核這個監聽的數目一共有多大
int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event)；
int epoll_wait(int epfd, struct epoll_event * events, int maxevents, int timeout);
int epoll_create(int size);
創建一個epoll的句柄，size用來告訴內核這個監聽的數目一共有多大，這個參數不同于select()中的第一個參數，給出最大監聽的fd+1的值，參數size并不是限制了epoll所能監聽的描述符最大個數，只是對內核初始分配內部數據結構的一個建議。
當創建好epoll句柄后，它就會占用一個fd值，在linux下如果查看/proc/進程id/fd/，是能夠看到這個fd的，所以在使用完epoll后，必須調用close()關閉，否則可能導致fd被耗盡。int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event)；
函數是對指定描述符fd執行op操作。
- epfd：是epoll_create()的返回值。
- op：表示op操作，用三個宏來表示：添加EPOLL_CTL_ADD，刪除EPOLL_CTL_DEL，修改EPOLL_CTL_MOD。分別添加、刪除和修改對fd的監聽事件。
- fd：是需要監聽的fd（文件描述符）
- epoll_event：是告訴內核需要監聽什么事，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隊列里
- int epoll_wait(int epfd, struct epoll_event * events, int maxevents, int timeout);
等待epfd上的io事件，最多返回maxevents個事件。
參數events用來從內核得到事件的集合，maxevents告之內核這個events有多大，這個maxevents的值不能大于創建epoll_create()時的size，參數timeout是超時時間（毫秒，0會立即返回，-1將不確定，也有說法說是永久阻塞）。該函數返回需要處理的事件數目，如返回0表示已超時。
epoll操作代碼演示
#define IPADDRESS "127.0.0.1"
#define PORT 8787
#define MAXSIZE 1024
#define LISTENQ 5
#define FDSIZE 1000
#define EPOLLEVENTS 100
listenfd = socket_bind(IPADDRESS,PORT);
struct epoll_event events[EPOLLEVENTS];
//創建一個描述符
epollfd = epoll_create(FDSIZE);
//添加監聽描述符事件
add_event(epollfd,listenfd,EPOLLIN);
//循環等待
for ( ; ; ){
//該函數返回已經準備好的描述符事件數目
ret = epoll_wait(epollfd,events,EPOLLEVENTS,-1);
//處理接收到的連接
handle_events(epollfd,events,ret,listenfd,buf);
}
//事件處理函數
static void handle_events(int epollfd,struct epoll_event *events,int num,int listenfd,char *buf)
{
int i;
int fd;
//進行遍歷;這里只要遍歷已經準備好的io事件。num并不是當初epoll_create時的FDSIZE。
for (i = 0;i < num;i++)
{
fd = events[i].data.fd;
//根據描述符的類型和事件類型進行處理
if ((fd == listenfd) &&(events[i].events & EPOLLIN))
handle_accpet(epollfd,listenfd);
else if (events[i].events & EPOLLIN)
do_read(epollfd,fd,buf);
else if (events[i].events & EPOLLOUT)
do_write(epollfd,fd,buf);
}
}
//添加事件
static void add_event(int epollfd,int fd,int state){
struct epoll_event ev;
ev.events = state;
ev.data.fd = fd;
epoll_ctl(epollfd,EPOLL_CTL_ADD,fd,&ev);
}
//處理接收到的連接
static void handle_accpet(int epollfd,int listenfd){
int clifd;
struct sockaddr_in cliaddr;
socklen_t cliaddrlen;
clifd = accept(listenfd,(struct sockaddr*)&cliaddr,&cliaddrlen);
if (clifd == -1)
perror("accpet error:");
else {
printf("accept a new client: %s:%d\n",inet_ntoa(cliaddr.sin_addr),cliaddr.sin_port); //添加一個客戶描述符和事件
add_event(epollfd,clifd,EPOLLIN);
}
}
//讀處理
static void do_read(int epollfd,int fd,char *buf){
int nread;
nread = read(fd,buf,MAXSIZE);
if (nread == -1) {
perror("read error:");
close(fd); //記住close fd
delete_event(epollfd,fd,EPOLLIN); //刪除監聽
}
else if (nread == 0) {
fprintf(stderr,"client close.\n");
close(fd); //記住close fd
delete_event(epollfd,fd,EPOLLIN); //刪除監聽
}
else {
printf("read message is : %s",buf);
//修改描述符對應的事件，由讀改為寫
modify_event(epollfd,fd,EPOLLOUT);
}
}
//寫處理
static void do_write(int epollfd,int fd,char *buf) {
int nwrite;
nwrite = write(fd,buf,strlen(buf));
if (nwrite == -1){
perror("write error:");
close(fd); //記住close fd
delete_event(epollfd,fd,EPOLLOUT); //刪除監聽
}else{
modify_event(epollfd,fd,EPOLLIN);
}
memset(buf,0,MAXSIZE);
}
//刪除事件
static void delete_event(int epollfd,int fd,int state) {
struct epoll_event ev;
ev.events = state;
ev.data.fd = fd;
epoll_ctl(epollfd,EPOLL_CTL_DEL,fd,&ev);
}
//修改事件
static void modify_event(int epollfd,int fd,int state){
struct epoll_event ev;
ev.events = state;
ev.data.fd = fd;
epoll_ctl(epollfd,EPOLL_CTL_MOD,fd,&ev);
}
//注：另外一端我就省了
epoll總結
在 select/poll中，進程只有在調用一定的方法后，內核才對所有監視的文件描述符進行掃描，而epoll事先通過epoll_ctl()來注冊一 個文件描述符，一旦基于某個文件描述符就緒時，內核會采用類似callback的回調機制，迅速激活這個文件描述符，當進程調用epoll_wait() 時便得到通知。(此處去掉了遍歷文件描述符，而是通過監聽回調的的機制。這正是epoll的魅力所在。)
epoll的優點主要是一下幾個方面：
- 監視的描述符數量不受限制，它所支持的FD上限是最大可以打開文件的數目，這個數字一般遠大于2048,舉個例子,在1GB內存的機器上大約是10萬左 右，具體數目可以cat /proc/sys/fs/file-max察看,一般來說這個數目和系統內存關系很大。select的最大缺點就是進程打開的fd是有數量限制的。這對 于連接數量比較大的服務器來說根本不能滿足。雖然也可以選擇多進程的解決方案( Apache就是這樣實現的)，不過雖然linux上面創建進程的代價比較小，但仍舊是不可忽視的，加上進程間數據同步遠比不上線程間同步的高效，所以也不是一種完美的方案。
- IO的效率不會隨著監視fd的數量的增長而下降。epoll不同于select和poll輪詢的方式，而是通過每個fd定義的回調函數來實現的。只有就緒的fd才會執行回調函數。
- 如果沒有大量的idle -connection或者dead-connection，epoll的效率并不會比select/poll高很多，但是當遇到大量的idle- connection，就會發現epoll的效率大大高于select/poll。
select，poll，epoll區別
select的缺點：
單個進程能夠監視的文件描述符的數量存在最大限制，通常是1024，當然可以更改數量，但由于select采用輪詢的方式掃描文件描述符，文件描述符數量越多，性能越差；(在linux內核頭文件中，有這樣的定義：#define __FD_SETSIZE 1024)
內核 / 用戶空間內存拷貝問題，select需要復制大量的句柄數據結構，產生巨大的開銷；
select返回的是含有整個句柄的數組，應用程序需要遍歷整個數組才能發現哪些句柄發生了事件；
select的觸發方式是水平觸發，應用程序如果沒有完成對一個已經就緒的文件描述符進行IO操作，那么之后每次select調用還是會將這些文件描述符通知進程。
poll:
優勢:
1.無上限1024。
2.由于它不修改pollfd里的數據，所以它可以不用每次都填寫了。
3.方便的知道遠程的狀態比如宕機
缺點:
1、還要輪巡
2、不能動態修改set。
其實大多數client不用考慮這個，除非p2p應用。一些server端用不用考慮這個問題。
大多時候他都比select更好。甚至如下場景比epoll還好:
你要跨平臺，因為epoll只支持linux。
socket數目少于1000個。
大于1000但是是socket壽命比較短。
沒有其他線程干擾的時候。
相比select模型，poll使用鏈表保存文件描述符，因此沒有了監視文件數量的限制，但select三個缺點依然存在。
拿select模型為例，假設我們的服務器需要支持100萬的并發連接，則在__FD_SETSIZE 為1024的情況下，則我們至少需要開辟1k個進程才能實現100萬的并發連接。除了進程間上下文切換的時間消耗外，從內核/用戶空間大量的無腦內存拷貝、數組輪詢等，是系統難以承受的。因此，基于select模型的服務器程序，要達到10萬級別的并發訪問，是一個很難完成的任務。
epoll：
優點：
1.只返回觸發的事件。少了拷貝消耗，迭代輪訓消耗。
2.可以綁定更多上下文，不僅僅是socket。
3.任何時間處理socket。這些問題都是有內核來處理。了。這個還需要繼續學習啊。
4.可以邊緣觸發。
5.多線程可以在同一個epoll wait里等待。
缺點：
1.讀寫狀態變更之類的就要麻煩些，在poll里只要改一個bit就可以了。在這里面則需要改更多的位數。并且都是system call。
2.創建socket也需要兩次系統調用，麻煩。
3.只有linux下可以使用
4.復雜難調試
適合場景
1.多線程，多連接。在單線程還不如poll
2.大量線程監控1000上，
3.相對長壽命的連接。系統調用會很耗時。
4.linux依賴的事情。
epoll IO多路復用模型實現機制
由于epoll的實現機制與select/poll機制完全不同，上面所說的 select的缺點在epoll上不復存在。
設想一下如下場景：有100萬個客戶端同時與一個服務器進程保持著TCP連接。而每一時刻，通常只有幾百上千個TCP連接是活躍的(事實上大部分場景都是這種情況)。如何實現這樣的高并發？
select/poll時代，服務器進程每次都把這100萬個連接告訴操作系統(從用戶態復制句柄數據結構到內核態)，讓操作系統內核去查詢這些套接字上是否有事件發生，輪詢完后，再將句柄數據復制到用戶態，讓服務器應用程序輪詢處理已發生的網絡事件，這一過程資源消耗較大，因此，select/poll一般只能處理幾千的并發連接。
epoll的設計和實現與select完全不同。epoll通過在Linux內核中申請一個簡易的文件系統(文件系統一般用什么數據結構實現？B+樹)。把原先的select/poll調用分成了3個部分：
1）調用epoll_create()建立一個epoll對象(在epoll文件系統中為這個句柄對象分配資源)
2）調用epoll_ctl向epoll對象中添加這100萬個連接的套接字
3）調用epoll_wait收集發生的事件的連接
如此一來，要實現上面說是的場景，只需要在進程啟動時建立一個epoll對象，然后在需要的時候向這個epoll對象中添加或者刪除連接。同時，epoll_wait的效率也非常高，因為調用epoll_wait時，并沒有一股腦的向操作系統復制這100萬個連接的句柄數據，內核也不需要去遍歷全部的連接。
下面來看看Linux內核具體的epoll機制實現思路
當某一進程調用epoll_create方法時，Linux內核會創建一個eventpoll結構體，這個結構體中有兩個成員與epoll的使用方式密切相關。eventpoll結構體如下所示：
struct eventpoll{
....
/*紅黑樹的根節點，這顆樹中存儲著所有添加到epoll中的需要監控的事件*/
struct rb_root rbr;
/*雙鏈表中則存放著將要通過epoll_wait返回給用戶的滿足條件的事件*/
struct list_head rdlist;
....
};
每一個epoll對象都有一個獨立的eventpoll結構體，用于存放通過epoll_ctl方法向epoll對象中添加進來的事件。這些事件都會掛載在紅黑樹中，如此，重復添加的事件就可以通過紅黑樹而高效的識別出來(紅黑樹的插入時間效率是lgn，其中n為樹的高度)。
而所有添加到epoll中的事件都會與設備(網卡)驅動程序建立回調關系，也就是說，當相應的事件發生時會調用這個回調方法。這個回調方法在內核中叫ep_poll_callback,它會將發生的事件添加到rdlist雙鏈表中。
在epoll中，對于每一個事件，都會建立一個epitem結構體，如下所示：
struct epitem{
struct rb_node rbn;//紅黑樹節點
struct list_head rdllink;//雙向鏈表節點
struct epoll_filefd ffd; //事件句柄信息
struct eventpoll *ep; //指向其所屬的eventpoll對象
struct epoll_event event; //期待發生的事件類型
}
當調用epoll_wait檢查是否有事件發生時，只需要檢查eventpoll對象中的rdlist雙鏈表中是否有epitem元素即可。如果rdlist不為空，則把發生的事件復制到用戶態，同時將事件數量返回給用戶。
從上面的講解可知：通過紅黑樹和雙鏈表數據結構，并結合回調機制，造就了epoll的高效。
OK，講解完了Epoll的機理，我們便能很容易掌握epoll的用法了。一句話描述就是：三步曲。
第一步：epoll_create()系統調用。此調用返回一個句柄，之后所有的使用都依靠這個句柄來標識。
第二步：epoll_ctl()系統調用。通過此調用向epoll對象中添加、刪除、修改感興趣的事件，返回0標識成功，返回-1表示失敗。
第三部：epoll_wait()系統調用。通過此調用收集收集在epoll監控中已經發生的事件。
select仍然在現實保留的原因
1.歷史遺留問題，因為select發展了很久的時間，額可以肯定大多的平臺都支持他了，因為你無法保證新的平臺都支持poll或者epoll。放心，我們說的不是enaic那種元祖機子，你聽說過xp嗎？你知道他在全中國全世界知道今天2016/9/10仍然占據多少比例么。oh no，它只支持iselect。
2.時間高精度，因為select可以精確到ns級別。而后二者只能精確到ms級別。當然你會說很多系統調用都沒有那么高精度的。但是對于實時操作系統，也就是類似工業控制的高精領域，或者說比如核電站，核反應堆，oh，no這兒用select不止是讓系統更安全，讓你不被老板炒魷魚，更是關系到我們大眾安全的問題，請你一定不要忘了這一點。
3，當然如果是簡單應用場景，比如低于200個socket，那么你用什么其實問題都不大，更多的問題是在與程序員的編程水平了。
