一：IOCP和Epoll之間的異同。
異：
1：IOCP是WINDOWS系統下使用。Epoll是Linux系統下使用。
2：IOCP是IO操作完畢之後，通過Get函式獲得一個完成的事件通知。
Epoll是當你希望進行一個IO操作時，向Epoll查詢是否可讀或者可寫，若處於可讀或可寫狀態後，Epoll會通過epoll_wait進行通知。
3：IOCP封裝了非同步的訊息事件的通知機制，同時封裝了部分IO操作。但Epoll僅僅封裝了一個非同步事件的通知機制，並不負責IO讀寫操作。Epoll保持了事件通知和IO操作間的獨立性，更加簡單靈活。
4：基於上面的描述，我們可以知道Epoll不負責IO操作，所以它只告訴你當前可讀可寫了，並且將協議讀寫緩衝填充，由使用者去讀寫控制，此時我們可以做出額外的許多操作。IOCP則直接將IO通道里的讀寫操作都做完了才通知使用者，當IO通道里發生了堵塞等狀況我們是無法控制的。

同：
1：它們都是非同步的事件驅動的網路模型。
2：它們都可以向底層進行指標資料傳遞，當返回事件時，除可通知事件型別外，還可以通知事件相關資料。

二：描述一下IOCP:
扯遠點。首先傳統伺服器的網路IO流程如下：
接到一個客戶端連線->建立一個執行緒負責這個連線的IO操作->持續對新執行緒進行資料處理->全部資料處理完畢->終止執行緒。
但是這樣的設計代價是：
1：每個連線建立一個執行緒，將導致過多的執行緒。
2：維護執行緒所消耗的堆疊記憶體過大。
3：作業系統建立和銷燬執行緒過大。
4：執行緒之間切換的上下文代價過大。
此時我們可以考慮使用執行緒池解決其中3和4的問題。這種傳統的伺服器網路結構稱之為會話模型。
後來我們為防止大量執行緒的維護，建立了I/O模型，它被希望要求可以:
1：允許一個執行緒在不同時刻給多個客戶端進行服務。
2：允許一個客戶端在不同時間被多個執行緒服務。
這樣做的話，我們的執行緒則會大幅度減少，這就要求以下兩點：
1：客戶端狀態的分離，之前會話模式我們可以通過執行緒狀態得知客戶端狀態，但現在客戶端狀態要通過其他方式獲取。
2：I/O請求的分離。一個執行緒不再服務於一個客戶端會話，則要求客戶端對這個執行緒提交I/O處理請求。
那麼就產生了這樣一個模式，分為兩部分:
1：會話狀態管理模組。它負責接收到一個客戶端連線，就建立一個會話狀態。
2：當會話狀態發生改變，例如斷掉連線，接收到網路訊息，就傳送一個I/O請求給 I/O工作模組進行處理。
3：I/O工作模組接收到一個I/O請求後，從執行緒池裡喚醒一個工作執行緒，讓該工作執行緒處理這個I/O請求，處理完畢後，該工作執行緒繼續掛起。
上面的做法，則將網路連線 和I/O工作執行緒分離為兩個部分，相互通訊僅依靠 I/O請求。
此時可知有以下一些建議：
1：在進行I/O請求處理的工作執行緒是被喚醒的工作執行緒，一個CPU對應一個的話，可以最大化利用CPU。所以 活躍執行緒的個數 建議等於 硬體CPU個數。
2：工作執行緒我們開始建立了執行緒池，免除建立和銷燬執行緒的代價。因為執行緒是對I/O進行操作的，且一一對應，那麼當I/O全部並行時，工作執行緒必須滿足I/O並行操作需求，所以 執行緒池內最大工作執行緒個數 建議大於或者等於 I/O並行個數。
3：但是我們可知CPU個數又限制了活躍的執行緒個數，那麼執行緒池過大意義很低，所以按常規建議 執行緒池大小 等於 CPU個數*2 左右為佳。例如，8核伺服器建議建立16個工作執行緒的執行緒池。
上面描述的依然是I/O模型並非IOCP，那麼IOCP是什麼呢，全稱 IO完成埠。
它是一種WIN32的網路I/O模型，既包括了網路連線部分，也負責了部分的I/O操作功能，用於方便我們控制有併發性的網路I/O操作。它有如下特點：
1：它是一個WIN32核心物件，所以無法運行於Linux.
2：它自己負責維護了工作執行緒池，同時也負責了I/O通道的記憶體池。
3：它自己實現了執行緒的管理以及I/O請求通知，最小化的做到了執行緒的上下文切換。
4：它自己實現了執行緒的優化排程，提高了CPU和記憶體緩衝的使用率。
使用IOCP的基本步驟很簡單：
1：建立IOCP物件，由它負責管理多個Socket和I/O請求。CreateIoCompletionPort需要將IOCP物件和IOCP控制代碼繫結。
2：建立一個工作執行緒池，以便Socket傳送I/O請求給IOCP物件後，由這些工作執行緒進行I/O操作。注意，建立這些執行緒的時候，將這些執行緒繫結到IOCP上。
3：建立一個監聽的socket。
4：輪詢，當接收到了新的連線後，將socket和完成埠進行關聯並且投遞給IOCP一個I/O請求。注意：將Socket和IOCP進行關聯的函式和建立IOCP的函式一樣，都是CreateIoCompletionPort，不過注意傳參必然是不同的。
5：因為是非同步的，我們可以去做其他，等待IOCP將I/O操作完成會回饋我們一個訊息，我們再進行處理。
其中需要知道的是：I/O請求被放在一個I/O請求佇列裡面，對，是佇列，LIFO機制。當一個裝置處理完I/O請求後，將會將這個完成後的I/O請求丟回IOCP的I/O完成佇列。
我們應用程式則需要在GetQueuedCompletionStatus去詢問IOCP，該I/O請求是否完成。
其中有一些特殊的事情要說明一下，我們有時有需要人工的去投遞一些I/O請求，則需要使用PostQueuedCompletionStatus函式向IOCP投遞一個I/O請求到它的請求佇列中。

三：網路遊戲伺服器注意事項，優化措施
1：IO操作是最大的效能消耗點，注意優化餘地很大。
2：演算法資料結構。排序尋路演算法的優化。list,vector,hashmap的選擇。大資料定址，不要考慮遍歷，注意考慮hash.
3：記憶體管理。過載new/delete，記憶體池，物件池的處理。
4：資料的提前準備和即時計算。
5：CPU方面的統計監視。邏輯幀計數（應當50ms以內）。
6：預分配池減少切換和排程，預處理的執行緒池和連線池等。
7：基與訊息佇列的統計和資訊監視框架。
8：CPU消耗排名：第一AOI同步，第二網路發包I/O操作，第三技能/BUFF判定計算處理，第四定時器的頻率。
9：記憶體洩露檢測，記憶體訪問越界警惕，記憶體碎片的回收。
10：記憶體消耗排名：第一玩家物件包括其物品，第二網路資料緩衝。
11：注意32位和64位的記憶體容錯。
12：減少不必要的分包傳送。
13：減少重複包和重拷貝包的代價。
14：建議分緊急包（立刻傳送）和非緊急包（定時輪訓傳送）。
15：頻寬消耗排名：第一移動位置同步，第二物件載入，第三登陸突發包，第四狀態機定時器訊息。
16：客戶端可做部分預判斷機制，部分操作儘量分包傳送。
17：大量玩家聚集時，部分非緊急包進行丟棄。
18：注意資料庫單表內key數量。
19：活躍使用者和非活躍使用者的分割存取處理。
20：控制玩家操作對資料庫的操作頻率。
21：注意使用共享記憶體等方式對資料進行安全備份儲存。
22：注意安全策略，對內網進行IP檢查，對日誌進行記錄，任意兩環點內均使用加密演算法會更佳。
23：實時注意對閘道器，資料庫等介面進行監察控制。
24：定時器應當儲存一個佇列，而非單向定位。
25：九宮格資料同步時，不需要直接進行九宮格的同步，對角色加一個AOI，基於圓方碰撞原理，拋棄不必要的格資訊，可大幅節省。
26：客戶端做部分的預測機制，伺服器檢測時注意時間戳問題。
27：定期心跳包，檢查死連結是必要的。
28：為了實現更加負責多種類的AI，AI尋路獨立伺服器設計已經是必須的了。其次需要考慮的是聊天，同步。
29：伺服器內網間可以考慮使用UDP。
30：注意所有記憶體池，物件池等的動態擴張分配。

1：以記憶體換取CPU的理念。
2：NPC不死理念。(只會disable)
3：動態擴充套件理念，負載均衡理念。
4：客戶端不可信理念。
5：指標資料，訊息均不可信理念。