IOCP本质论
一直以來就想寫一篇關于IOCP本質的文章，也在網上零星的有一些介紹其本質的概念，可是沒有一篇從整理來分析并講解的文章，借著這次開發將近完畢，還有自己的服務器設計開發的書籍也要加快進度，這次也算一節內容了。
下面開始吧：
1：先來闡述一下IOCP的流程
下圖是創建流程：
下圖為工作線程流程：
?
IOCP內部工作隊列圖：
?
?
用完成端口開發大響應規模的Winsock應用程序[轉]
2008-10-11?21:47
前面的部分和本博客前面一篇文章基本一致，從MSDN翻譯而來，而后面一部分就沒有翻譯了，還好有先人為我們做好，這里非常感謝這位作者，如果您看到這篇文章系你翻譯，請聯系我，我將立刻署名。另外對于關鍵的一些地方我將加部分批注。
接受連接請求?
服務器要做的最普通的事情之一就是接受來自客戶端的連接請求。在套接字上使用重疊I/O接受連接的惟一API就是AcceptEx()函數【注一】。有趣的是，通常的同步接受函數accept()的返回值是一個新的套接字，而AcceptEx()函數則需要另外一個套接字作為它的參數之一。這是因為AcceptEx()是一個重疊操作，所以你需要事先創建一個套接字(但不要綁定或連接它)，并把這個套接字通過參數傳給AcceptEx()。以下是一小段典型的使用AcceptEx()的偽代碼：
引用
do?{
-等待上一個?AcceptEx?完成
-創建一個新套接字并與完成端口進行關聯
-設置背景結構等等
-發出一個?AcceptEx?請求
}while(TRUE);
作為一個高響應能力的服務器，它必須發出足夠的AcceptEx調用，守候著，一旦出現客戶端連接請求就立刻響應。至于發出多少個AcceptEx才夠，就取決于你的服務器程序所期待的通信交通類型。比如，如果進入連接率高的情況(因為連接持續時間較短，或者出現交通高峰)，那么所需要守候的AcceptEx當然要比那些偶爾進入的客戶端連接的情況要多。聰明的做法是，由應用程序來分析交通狀況，并調整AcceptEx守候的數量，而不是固定在某個數量上。
對于Windows2000，Winsock提供了一些機制，幫助你判定AcceptEx的數量是否足夠。這就是，在創建監聽套接字時創建一個事件，通過WSAEventSelect()這個API并注冊FD_ACCEPT事件通知來把套接字和這個事件關聯起來【注二】。一旦系統收到一個連接請求，如果系統中沒有AcceptEx()正在等待接受連接，那么上面的事件將收到一個信號。通過這個事件，你就可以判斷你有沒有發出足夠的AcceptEx()，或者檢測出一個非正常的客戶請求(下文述)。這種機制對Windows?NT?4.0不適用。
使用AcceptEx()的一大好處是，你可以通過一次調用就完成接受客戶端連接請求和接受數據(通過傳送lpOutputBuffer參數)兩件事情。也就是說，如果客戶端在發出連接的同時傳輸數據，你的AcceptEx()調用在連接創建并接收了客戶端數據后就可以立刻返回。這樣可能是很有用的，但是也可能會引發問題，因為AcceptEx()必須等全部客戶端數據都收到了才返回。具體來說，如果你在發出AcceptEx()調用的同時傳遞了lpOutputBuffer參數，那么AcceptEx()不再是一項原子型的操作，而是分成了兩步：接受客戶連接，等待接收數據。當缺少一種機制來通知你的應用程序所發生的這種情況：“連接已經建立了，正在等待客戶端數據”，這將意味著有可能出現客戶端只發出連接請求，但是不發送數據。如果你的服務器收到太多這種類型的連接時，它將拒絕連接更多的合法客戶端請求。這就是黑客進行“拒絕服務”攻擊的常見手法。
要預防此類攻擊，接受連接的線程應該不時地通過調用getsockopt()函數(選項參數為SO_CONNECT_TIME)來檢查AcceptEx()里守候的套接字。getsockopt()函數的選項值將被設置為套接字被連接的時間，或者設置為-1(代表套接字尚未建立連接)。這時，WSAEventSelect()的特性就可以很好地利用來做這種檢查。如果發現連接已經建立，但是很久都沒有收到數據的情況，那么就應該終止連接，方法就是關閉作為參數提供給AcceptEx()的那個套接字。注意，在多數非緊急情況下，如果套接字已經傳遞給AcceptEx()并開始守候，但還未建立連接，那么你的應用程序不應該關閉它們。這是因為即使關閉了這些套接字，出于提高系統性能的考慮，在連接進入之前，或者監聽套接字自身被關閉之前，相應的內核模式的數據結構也不會被干凈地清除。
發出AcceptEx()調用的線程，似乎與那個進行完成端口關聯操作、處理其它I/O完成通知的線程是同一個，但是，別忘記線程里應該盡力避免執行阻塞型的操作。Winsock2分層結構的一個副作用是調用socket()或WSASocket()?API的上層架構可能很重要(譯者不太明白原文意思，抱歉)。每個AcceptEx()調用都需要創建一個新套接字，所以最好有一個獨立的線程專門調用AcceptEx()，而不參與其它I/O處理。你也可以利用這個線程來執行其它任務，比如事件記錄。
有關AcceptEx()的最后一個注意事項：要實現這些API，并不需要其它提供商提供的Winsock2實現。這一點對微軟特有的其它API也同樣適用，比如TransmitFile()和GetAcceptExSockAddrs()，以及其它可能會被加入到新版Windows的API.?在Windows?NT和2000上，這些API是在微軟的底層提供者DLL(mswsock.dll)中實現的，可通過與mswsock.lib編譯連接進行調用，或者通過WSAIoctl()?(選項參數為SIO_GET_EXTENSION_FUNCTION_POINTER)動態獲得函數的指針。
如果在沒有事先獲得函數指針的情況下直接調用函數(也就是說，編譯時靜態連接mswsock.lib，在程序中直接調用函數)，那么性能將很受影響。因為AcceptEx()被置于Winsock2架構之外，每次調用時它都被迫通過WSAIoctl()取得函數指針。要避免這種性能損失，需要使用這些API的應用程序應該通過調用WSAIoctl()直接從底層的提供者那里取得函數的指針。
參見Figure?3?套接字架構：
引用
application
||
\||/
\/
winsock?2.0?dll?(ws2_32.dll)
||
\||/
\/
layered/Base?Providers
RSVP?|?Proxy?|?Default?Microsoft?Providers?(mswsock.dll/msafd.dll)
||
\||/
\/
Windows?Sockets?kernel-mode?driver?(afd.sys)
||
\||/
\/
Tramsport?Protocols
TCP/IP?|?ATM?|?Other
TransmitFile?和?TransmitPackets?
Winsock?提供兩個專門為文件和內存數據傳輸進行了優化的函數。其中TransmitFile()這個API函數在Windows?NT?4.0?和?Windows?2000上都可以使用，而TransmitPackets()則將在未來版本的Windows中實現。
TransmitFile()用來把文件內容通過Winsock進行傳輸。通常發送文件的做法是，先調用CreateFile()打開一個文件，然后不斷循環調用ReadFile()?和WSASend?()直至數據發送完畢。但是這種方法很沒有效率，因為每次調用ReadFile()?和?WSASend?()都會涉及一次從用戶模式到內核模式的轉換。如果換成TransmitFile()，那么只需要給它一個已打開文件的句柄和要發送的字節數，而所涉及的模式轉換操作將只在調用CreateFile()打開文件時發生一次，然后TransmitFile()時再發生一次。這樣效率就高多了。
TransmitPackets()比TransmitFile()更進一步，它允許用戶只調用一次就可以發送指定的多個文件和內存緩沖區。函數原型如下：
BOOL?TransmitPackets(
SOCKET?hSocket, ?
LPTRANSMIT_PACKET_ELEMENT?lpPacketArray,
DWORD?nElementCount,
DWORD?nSendSize,
LPOVERLAPPED?lpOverlapped,
DWORD?dwFlags ?
);?
其中，lpPacketArray是一個結構的數組，其中的每個元素既可以是一個文件句柄或者內存緩沖區，該結構定義如下：
typedef?struct?_TRANSMIT_PACKETS_ELEMENT?{?
DWORD?dwElFlags;?
DWORD?cLength;?
union?{
struct?{
LARGE_INTEGER ?nFileOffset;
HANDLEhFile;
};
PVOID ?pBuffer;
};
}?TRANSMIT_FILE_BUFFERS;
其中各字段是自描述型的(self?explanatory)。
dwElFlags字段：指定當前元素是一個文件句柄還是內存緩沖區(分別通過常量TF_ELEMENT_FILE?和TF_ELEMENT_MEMORY指定)；
cLength字段：指定將從數據源發送的字節數(如果是文件，這個字段值為0表示發送整個文件)；
結構中的無名聯合體：包含文件句柄的內存緩沖區(以及可能的偏移量)。
使用這兩個API的另一個好處，是可以通過指定TF_REUSE_SOCKET和TF_DISCONNECT標志來重用套接字句柄。每當API完成數據的傳輸工作后，就會在傳輸層級別斷開連接，這樣這個套接字就又可以重新提供給AcceptEx()使用。采用這種優化的方法編程，將減輕那個專門做接受操作的線程創建套接字的壓力(前文述及)。
這兩個API也都有一個共同的弱點：Windows?NT?Workstation?或?Windows?2000?專業版中，函數每次只能處理兩個調用請求，只有在Windows?NT、Windows?2000服務器版、Windows?2000高級服務器版或?Windows?2000?Data?Center中才獲得完全支持。
放在一起看看
以上各節中，我們討論了開發高性能的、大響應規模的應用程序所需的函數、方法和可能遇到的資源瓶頸問題。這些對你意味著什么呢？其實，這取決于你如何構造你的服務器和客戶端。當你能夠在服務器和客戶端設計上進行更好地控制時，那么你越能夠避開瓶頸問題。
來看一個示范的環境。我們要設計一個服務器來響應客戶端的連接、發送請求、接收數據以及斷開連接。
那么，
服務器將需要創建一個監聽套接字，
把它與某個完成端口進行關聯，
為每顆CPU創建一個工作線程。
再創建一個線程專門用來發出AcceptEx()。
我們知道客戶端會在發出連接請求后立刻傳送數據，
所以如果我們準備好接收緩沖區會使事情變得更為容易。
當然，不要忘記不時地輪詢AcceptEx()調用中使用的套接字(使用SO_CONNECT_TIME選項參數)來確保沒有惡意超時的連接。
該設計中有一個重要的問題要考慮，我們應該允許多少個AcceptEx()進行守候。
這是因為，每發出一個AcceptEx()時我們都同時需要為它提供一個接收緩沖區，那么內存中將會出現很多被鎖定的頁面(前文說過了，每個重疊操作都會消耗一小部分未分頁內存池，同時還會鎖定所有涉及的緩沖區)。這個問題很難回答，沒有一個確切的答案。最好的方法是把這個值做成可以調整的，通過反復做性能測試，你就可以得出在典型應用環境中最佳的值。
好了，當你測算清楚后，下面就是發送數據的問題了，考慮的重點是你希望服務器同時處理多少個并發的連接。通常情況下，服務器應該限制并發連接的數量以及等候處理的發送調用。因為并發連接數量越多，所消耗的未分頁內存池也越多；等候處理的發送調用越多，被鎖定的內存頁面也越多(小心別超過了極限)。這同樣也需要反復測試才知道答案。
對于上述環境，通常不需要關閉單個套接字的緩沖區，因為只在AcceptEx()中有一次接收數據的操作，而要保證給每個到來的連接提供接收緩沖區并不是太難的事情。但是，如果客戶機與服務器交互的方式變一變，客戶機在發送了一次數據之后，還需要發送更多的數據，在這種情況下關閉接收緩沖就不太妙了，除非你想辦法保證在每個連接上都發出了重疊接收調用來接收更多的數據。
結論
引用
開發大響應規模的Winsock服務器并不是很可怕，其實也就是設置一個監聽套接字、接受連接請求和進行重疊收發調用。通過設置合理的進行守候的重疊調用的數量，防止出現未分頁內存池被耗盡，這才是最主要的挑戰。按照我們前面討論的一些原則，你就可以開發出大響應規模的服務器應用程序。
?
?
?
總結
