接受連接請求
服務器要做的最普通的事情之一就是接受來自客戶端的連接請求。在套接字上使用重疊I/O接受連接的惟一API就是AcceptEx()函數【注一】。有趣的是，通常的同步接受函數accept()的返回值是一個新的套接字，而AcceptEx()函數則需要另外一個套接字作爲它的參數之一。這是因爲AcceptEx()是一個重疊操作，所以你需要事先創建一個套接字(但不要綁定或連接它)，並把這個套接字通過參數傳給AcceptEx()。以下是一小段典型的使用AcceptEx()的僞代碼：
引用
do {
-等待上一個 AcceptEx 完成
-創建一個新套接字並與完成端口進行關聯
-設置背景結構等等
-發出一個 AcceptEx 請求
}while(TRUE);
-等待上一個 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
||
/||/
//
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;
HANDLE hFile;
};
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服務器並不是很可怕，其實也就是設置一個監聽套接字、接受連接請求和進行重疊收發調用。通過設置合理的進行守候的重疊調用的數量，防止出現未分頁內存池被耗盡，這纔是最主要的挑戰。按照我們前面討論的一些原則，你就可以開發出大響應規模的服務器應用程序。
