我們知道epoll有兩種觸發模式：水平觸發(LT)和邊緣觸發(ET)

LT模式

1. 若資料可讀，epoll返回可讀事件 若開發者沒有把資料完全讀完，epoll會不斷通知資料可讀，直到資料全部被讀取。
2. 若socket可寫，epoll返回可寫事件，而且是隻要socket傳送緩衝區未滿，就一直通知可寫事件。
3. 優點是對於read操作比較簡單，只要有read事件就讀，讀多讀少都可以。

ET模式

1. 若socket可讀，返回可讀事件。
2. 若沒有把所有資料讀取完畢，epoll不會再次通知epoll read事件，也就是說存在一種隱患，如果在讀到可讀事件時，沒有讀取全部資料，那麼可能導致epoll再也不會通知該socket的read事件。
3. ET模式下，只有socket的狀態發生變化時才會通知，也就是讀取緩衝區由無資料到有資料時通知read事件，傳送緩衝區由滿變成未滿通知write事件。

簡單說明一下兩種觸發模式的特點後，來說一下我遇到的問題：我自己寫了一個http伺服器，使用了epoll加執行緒池的reactor模式，並且只支援HTTP短連線，所以當瀏覽器請求一個較複雜的web頁面時，伺服器會接收到較多的併發連線，這些是前提。今天在伺服器程式碼基本完成後，進行了測試。
在測試中我發現：在瀏覽器發出較多請求或者頻繁重新整理頁面時，總會有幾個請求得不到響應。所以就抓包來分析了一下，抓包結果可以看到未響應的請求事實上已經和伺服器完成了三次握手，而我在伺服器中打log卻並沒有看到伺服器與該請求建立了連線。所以分析可能是accept函式沒有成功，經測試發現實際上accept並沒有被呼叫。
這裡要說明一下，accept實際上與TCP的三次握手並沒有關聯，它只是從監聽套接字的監聽佇列中取出一個套接字，當然了，前提是監聽佇列非空。這就可以聯想到，抓包發現瀏覽器已經與伺服器完成了三次握手並建立了連線，也就是說現在的監聽佇列非空，然而accept卻沒有被呼叫，這顯然產生了矛盾。
問題出在哪裡呢？我想到可能是epoll中的監聽套接字沒有觸發EPOLLIN事件，想到我對於監聽套接字設定了ET模式，那麼可能會發生下面的情況：有多個連線同時到達監聽埠，這時監聽佇列由空變為非空，EPOLLIN事件被觸發，但是我在程式中只進行了一次accept，所以只有一個連線被接受，之後儘管監聽佇列非空，由於在ET模式下，也不會再次觸發EPOLL事件了。
想到這裡，我趕緊去把程式碼中監聽套接字的觸發模式改為LT模式，果然bug被消除了。所以可以得到結論：在epoll中，監聽套接字的觸發模式最好設定為LT模式