IOCP構(gòu)架之所以公認高效，核心就在于異步IO。在網(wǎng)上紛紛為之膜拜之余，很少看到對穩(wěn)定性或性能優(yōu)化的觀點。仔細想想，任何技術(shù)都有有利的一面，自然也有有弊的一面，這才符合辯證法思想。?
我把自己在編寫IOCP構(gòu)架時重點處理的幾個地方交代一下，如果你想認真寫好一個穩(wěn)定的IOCP服務(wù)端，建議重新規(guī)劃以下幾個細節(jié)。?

1)不要修改套接字默認的收發(fā)緩沖區(qū)大小，即8192字節(jié)=8K=2分頁。?

2)總所周知，x86頁面置換最少需要1分頁，所以不管IOCP的重疊IO涉及多少字節(jié)，OS至少需要加鎖/解鎖1分頁，在使用異步WSARecv/WSASend時，只要重疊緩沖區(qū)WSABuf的長度大于0，那么在投遞異步操作時，系統(tǒng)至少會鎖定1分頁的非頁面內(nèi)存，而系統(tǒng)的非頁面緩沖池是有大小限制的，如果你的IOCP消耗了太多非分頁內(nèi)存。輕則同服務(wù)器其他網(wǎng)絡(luò)進程無法使用網(wǎng)絡(luò)，重則可能會導(dǎo)致系統(tǒng)藍屏或其他崩潰。而對于你的IOCP服務(wù)端通訊，常見的現(xiàn)象是客戶端無法與服務(wù)端進行連接，或者收發(fā)包時出現(xiàn) 10055 。?

3)正是由于情況2的出現(xiàn)可能性，所以在投遞WSARecv/WSASend時，絕對不要貪圖簡單，直接進行投遞，正確的做法應(yīng)該為每個套接字建立至少2個緩沖隊列，一收一發(fā)。?

4)對于同一個客戶端套接字，在同一時間最好只有一個WSARecv/WSASend，如果你想提高IOCP網(wǎng)絡(luò)吞吐量，可能會在同一個套接字上同時投遞多個WSARecv/WSASend，那么你將會面臨下面幾個情況必須處理：?

a)IO線程之間的WSARecv/WSASend操作頻繁加鎖/解鎖，因為你無法保證線程1在GQCS時，線程2不會對相同套接字GQCS。?

b)收發(fā)出現(xiàn)亂序，仔細想一下，正是因為你對同一套接字同時投遞多個WSARecv/WSASend導(dǎo)致的，有你忙的了。?

c)短時間內(nèi)大量WSARecv/WSASend異步操作消耗太多非分頁內(nèi)存，也許在你下次投遞收發(fā)操作時，OS會毫不留情給你一個10055錯誤。?

5）現(xiàn)在你應(yīng)該明白服務(wù)端的穩(wěn)定是一個前提，需要比高吞吐量更要優(yōu)先考慮，那么對于情況4建議的緩沖隊列，絕對應(yīng)該是你首先需要考慮的。?

6)合理限制客戶端套接字的流量（包速），即你需要規(guī)劃完整合理的Qos，否則一旦惡意連接試圖以大流量正常業(yè)務(wù)包攻擊你的IOCP時，你會發(fā)現(xiàn)你的IOCP構(gòu)架是多么脆弱。?

7)為了減少情況6的出現(xiàn)，建議你在客戶端/服務(wù)端通訊時增加壓縮(加密)/解壓縮(解密)功能，最好加入時間戳或GUID校驗，避免出現(xiàn)同樣的業(yè)務(wù)收發(fā)相同的包，最終導(dǎo)致攻擊者只需要截取一個正常業(yè)務(wù)包，就能干出情況6的事情。?

也許你會覺得如此實現(xiàn)太影響IOCP吞吐量，確實如此，收/發(fā)緩沖隊列、Qos、加密解密都會降低IO吞吐量。希望你在決定之前，先衡量一下你未來的IOCP服務(wù)端菊花是否夠緊，否則有一天你會高呼：OMG，是誰又把我那可憐而又脆弱的IOCP爆菊了？

總結(jié)

以上是生活随笔為你收集整理的IOCP不可忽视的细节的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。