EPOLL和IOCP比較
阿新 • • 發佈：2019-01-01
EPOLL是半成品，IOCP是成品，底層機制一樣，協議棧的狀態檢查不需要使用者去查詢，由作業系統來通知。
其實這是任何守護性邏輯高效能的基礎機制。
但是EPOLL只是告訴你現在可以讀和寫，即協議棧的讀寫緩衝被初始化或重設（對於寫，上次資料已經提交併寫緩衝重設為空，對於讀，棧議棧讀緩衝已經開始接受資料。）
但是寫和讀的過程還是由使用者來控制，系統只是告訴你已經為你準備好了和網路驅動對接好的讀寫的通道。如果某個通道的讀寫很慢，我們其實自己可以控制，比如要讀8K位元組，但經過x秒只讀到幾個位元組，這說明這個通道很差，我們可以將這個IO通道從EPOLL中分離出來把它投遞到一個阻塞的socket中，而不影響整個EPOLL的效能。所以EPOLL雖然是半成品，但使用者有更高的控制權。
而對於IOCP，從名稱就可以知道，系統不僅控制IO通道的狀態，而且把讀寫操作都做完了才通知使用者。對於讀，系統已經把資料讀好放在buffer中，其實相當於是RBF，對於寫，已經是寫出了n長度的位元組，所以即使某個IO通道上的傳輸很慢，你也無法控制，因為當你收到通知時，系統已經是讀好資料或寫出資料。所以IOCP在使用者的控制上沒有靈活的空間。
但是由系統來做畢竟比普通的二流以下的程式設計師自己來控制性能普遍來說要更好一些。
在高效能伺服器的開發中，採用一個非阻塞的IO模型配兩三個阻塞的socket混合處理，是最合理的，因為在大量連線中總會有一些客戶端傳輸很慢，對於非常慢的連線，EPOLL，IOCP還不如阻塞模型處理效能更好，即時讀寫速度是一樣的，但阻塞模型簡單，上下文切換和記憶體分配的開銷比較少。所以把一些很慢的連線重新投遞到阻塞的socket上而讓EPOLL能有更多的機會去處理傳輸非常快的連線才是非阻塞的優勢。相比來說，IOCP就不能這樣做。
其實這是任何守護性邏輯高效能的基礎機制。
但是EPOLL只是告訴你現在可以讀和寫，即協議棧的讀寫緩衝被初始化或重設（對於寫，上次資料已經提交併寫緩衝重設為空，對於讀，棧議棧讀緩衝已經開始接受資料。）
但是寫和讀的過程還是由使用者來控制，系統只是告訴你已經為你準備好了和網路驅動對接好的讀寫的通道。如果某個通道的讀寫很慢，我們其實自己可以控制，比如要讀8K位元組，但經過x秒只讀到幾個位元組，這說明這個通道很差，我們可以將這個IO通道從EPOLL中分離出來把它投遞到一個阻塞的socket中，而不影響整個EPOLL的效能。所以EPOLL雖然是半成品，但使用者有更高的控制權。
而對於IOCP，從名稱就可以知道，系統不僅控制IO通道的狀態，而且把讀寫操作都做完了才通知使用者。對於讀，系統已經把資料讀好放在buffer中，其實相當於是RBF，對於寫，已經是寫出了n長度的位元組，所以即使某個IO通道上的傳輸很慢，你也無法控制，因為當你收到通知時，系統已經是讀好資料或寫出資料。所以IOCP在使用者的控制上沒有靈活的空間。
但是由系統來做畢竟比普通的二流以下的程式設計師自己來控制性能普遍來說要更好一些。
在高效能伺服器的開發中，採用一個非阻塞的IO模型配兩三個阻塞的socket混合處理，是最合理的，因為在大量連線中總會有一些客戶端傳輸很慢，對於非常慢的連線，EPOLL，IOCP還不如阻塞模型處理效能更好，即時讀寫速度是一樣的，但阻塞模型簡單，上下文切換和記憶體分配的開銷比較少。所以把一些很慢的連線重新投遞到阻塞的socket上而讓EPOLL能有更多的機會去處理傳輸非常快的連線才是非阻塞的優勢。相比來說，IOCP就不能這樣做。