一：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：指針數據，消息均不可信理念。