用完成端口開發(fā)大響應規(guī)模的Winsock應用程序
原文出處：http://msdn.microsoft.com/msdnmag/issues/1000/Winsock/
通常要開發(fā)網(wǎng)絡(luò)應用程序并不是一件輕松的事情，不過，實際上只要掌握幾個關(guān)鍵的原則也就可以了——創(chuàng)建和連接一個套接字，嘗試進行連接，然后收發(fā)數(shù)據(jù)。真正難的是要寫出一個可以接納少則一個，多則數(shù)千個連接的網(wǎng)絡(luò)應用程序。本文將討論如何通過Winsock2在Windows NT 和 Windows 2000上開發(fā)高擴展能力的Winsock應用程序。文章主要的焦點在客戶機/服務(wù)器模型的服務(wù)器這一方，當然，其中的許多要點對模型的雙方都適用。
API與響應規(guī)模
通過Win32的重疊I/O機制，應用程序可以提請一項I/O操作，重疊的操作請求在后臺完成，而同一時間提請操作的線程去做其他的事情。等重疊操作完成后線程收到有關(guān)的通知。這種機制對那些耗時的操作而言特別有用。不過，像Windows 3.1上的WSAAsyncSelect()及Unix下的select()那樣的函數(shù)雖然易于使用，但是它們不能滿足響應規(guī)模的需要。而完成端口機制是針對操作系統(tǒng)內(nèi)部進行了優(yōu)化，在Windows NT 和 Windows 2000上，使用了完成端口的重疊I/O機制才能夠真正擴大系統(tǒng)的響應規(guī)模。
完成端口
一個完成端口其實就是一個通知隊列，由操作系統(tǒng)把已經(jīng)完成的重疊I/O請求的通知放入其中。當某項I/O操作一旦完成，某個可以對該操作結(jié)果進行處理的工作者線程就會收到一則通知。而套接字在被創(chuàng)建后，可以在任何時候與某個完成端口進行關(guān)聯(lián)。
通常情況下，我們會在應用程序中創(chuàng)建一定數(shù)量的工作者線程來處理這些通知。線程數(shù)量取決于應用程序的特定需要。理想的情況是，線程數(shù)量等于處理器的數(shù)量，不過這也要求任何線程都不應該執(zhí)行諸如同步讀寫、等待事件通知等阻塞型的操作，以免線程阻塞。每個線程都將分到一定的CPU時間，在此期間該線程可以運行，然后另一個線程將分到一個時間片并開始執(zhí)行。如果某個線程執(zhí)行了阻塞型的操作，操作系統(tǒng)將剝奪其未使用的剩余時間片并讓其它線程開始執(zhí)行。也就是說，前一個線程沒有充分使用其時間片，當發(fā)生這樣的情況時，應用程序應該準備其它線程來充分利用這些時間片。
完成端口的使用分為兩步。首先創(chuàng)建完成端口，如以下代碼所示：
HANDLE hIocp;
hIocp = CreateIoCompletionPort(
INVALID_HANDLE_VALUE,
NULL,
(ULONG_PTR)0,
0);
if (hIocp == NULL) {
// Error
}
完成端口創(chuàng)建后，要把將使用該完成端口的套接字與之關(guān)聯(lián)起來。方法是再次調(diào)用CreateIoCompletionPort ()函數(shù)，第一個參數(shù)FileHandle設(shè)為套接字的句柄，第二個參數(shù)ExistingCompletionPort 設(shè)為剛剛創(chuàng)建的那個完成端口的句柄。
以下代碼創(chuàng)建了一個套接字，并把它和前面創(chuàng)建的完成端口關(guān)聯(lián)起來：
SOCKET s;
s = socket(AF_INET, SOCK_STREAM, 0);
if (s == INVALID_SOCKET) {
// Error
if (CreateIoCompletionPort((HANDLE)s,
hIocp,
(ULONG_PTR)0,
0) == NULL)
{
// Error
}
...
}
這時就完成了套接字與完成端口的關(guān)聯(lián)操作。在這個套接字上進行的任何重疊操作都將通過完成端口發(fā)出完成通知。注意，CreateIoCompletionPort()函數(shù)中的第三個參數(shù)用來設(shè)置一個與該套接字相關(guān)的“完成鍵(completion key)”(譯者注：完成鍵可以是任何數(shù)據(jù)類型)。每當完成通知到來時，應用程序可以讀取相應的完成鍵，因此，完成鍵可用來給套接字傳遞一些背景信息。
在創(chuàng)建了完成端口、將一個或多個套接字與之相關(guān)聯(lián)之后，我們就要創(chuàng)建若干個線程來處理完成通知。這些線程不斷循環(huán)調(diào)用GetQueuedCompletionStatus ()函數(shù)并返回完成通知。
下面，我們先來看看應用程序如何跟蹤這些重疊操作。當應用程序調(diào)用一個重疊操作函數(shù)時，要把指向一個overlapped結(jié)構(gòu)的指針包括在其參數(shù)中。當操作完成后，我們可以通過GetQueuedCompletionStatus()函數(shù)中拿回這個指針。不過，單是根據(jù)這個指針所指向的overlapped 結(jié)構(gòu)，應用程序并不能分辨究竟完成的是哪個操作。要實現(xiàn)對操作的跟蹤，你可以自己定義一個OVERLAPPED結(jié)構(gòu)，在其中加入所需的跟蹤信息。
無論何時調(diào)用重疊操作函數(shù)時，總是會通過其lpOverlapped參數(shù)傳遞一個OVERLAPPEDPLUS結(jié)構(gòu)(例如WSASend、 WSARecv等函數(shù))。這就允許你為每一個重疊調(diào)用操作設(shè)置某些操作狀態(tài)信息，當操作結(jié)束后，你可以通過 GetQueuedCompletionStatus()函數(shù)獲得你自定義結(jié)構(gòu)的指針。注意OVERLAPPED字段不要求一定是這個擴展后的結(jié)構(gòu)的第一個字段。當?shù)玫搅酥赶騉VERLAPPED結(jié)構(gòu)的指針以后，可以用CONTAINING_RECORD宏取出其中指向擴展結(jié)構(gòu)的指針。
OVERLAPPED 結(jié)構(gòu)的定義如下：
typedef struct _OVERLAPPEDPLUS {
OVERLAPPED ol;
SOCKET s, sclient;
int OpCode;
WSABUF wbuf;
DWORD dwBytes, dwFlags;
// 其它有用的信息
} OVERLAPPEDPLUS;
#define OP_READ 0
#define OP_WRITE 1
#define OP_ACCEPT 2
下面讓我們來看看工作者線程的情況。
工作線程WorkerThread代碼：
DWORD WINAPI WorkerThread(LPVOID lpParam)
{
ULONG_PTR *PerHandleKey;
OVERLAPPED *Overlap;
OVERLAPPEDPLUS *OverlapPlus,
*newolp;
DWORD dwBytesXfered;
while (1)
{
ret = GetQueuedCompletionStatus(
hIocp,
&dwBytesXfered,
(PULONG_PTR)&PerHandleKey,
&Overlap,
INFINITE);
if (ret == 0)
{
// Operation failed
continue;
}
OverlapPlus = CONTAINING_RECORD(Overlap, OVERLAPPEDPLUS, ol);
switch (OverlapPlus->OpCode)
{
case OP_ACCEPT:
// Client socket is contained in OverlapPlus.sclient
// Add client to completion port
CreateIoCompletionPort(
(HANDLE)OverlapPlus->sclient,
hIocp,
(ULONG_PTR)0,
0);
// Need a new OVERLAPPEDPLUS structure
// for the newly accepted socket. Perhaps
// keep a look aside list of free structures.
newolp = AllocateOverlappedPlus();
if (!newolp)
{
// Error
}
newolp->s = OverlapPlus->sclient;
newolp->OpCode = OP_READ;
// This function prepares the data to be sent
PrepareSendBuffer(&newolp->wbuf);
ret = WSASend(
newolp->s,
&newolp->wbuf,
1,
&newolp->dwBytes,
0,
&newolp.ol,
NULL);
if (ret == SOCKET_ERROR)
{
if (WSAGetLastError() != WSA_IO_PENDING)
{
// Error
}
}
// Put structure in look aside list for later use
FreeOverlappedPlus(OverlapPlus);
// Signal accept thread to issue another AcceptEx
SetEvent(hAcceptThread);
break;
case OP_READ:
// Process the data read
// ...
// Repost the read if necessary, reusing the same
// receive buffer as before
memset(&OverlapPlus->ol, 0, sizeof(OVERLAPPED));
ret = WSARecv(
OverlapPlus->s,
&OverlapPlus->wbuf,
1,
&OverlapPlus->dwBytes,
&OverlapPlus->dwFlags,
&OverlapPlus->ol,
NULL);
if (ret == SOCKET_ERROR)
{
if (WSAGetLastError() != WSA_IO_PENDING)
{
// Error
}
}
break;
case OP_WRITE:
// Process the data sent, etc.
break;
} // switch
} // while
} // WorkerThread
其中每句柄鍵(PerHandleKey)變量的內(nèi)容，是在把完成端口與套接字進行關(guān)聯(lián)時所設(shè)置的完成鍵參數(shù)；Overlap參數(shù)返回的是一個指向發(fā)出重疊操作時所使用的那個OVERLAPPEDPLUS結(jié)構(gòu)的指針。
要記住，如果重疊操作調(diào)用失敗時(也就是說，返回值是SOCKET_ERROR，并且錯誤原因不是WSA_IO_PENDING)，那么完成端口將不會收到任何完成通知。如果重疊操作調(diào)用成功，或者發(fā)生原因是WSA_IO_PENDING的錯誤時，完成端口將總是能夠收到完成通知。
Windows NT和Windows 2000的套接字架構(gòu)
對于開發(fā)大響應規(guī)模的Winsock應用程序而言，對Windows NT和Windows 2000的套接字架構(gòu)有基本的了解是很有幫助的。下圖是Windows 2000中的Winsock架構(gòu)：
與其它類型操作系統(tǒng)不同，Windows NT和Windows 2000的傳輸協(xié)議沒有一種風格像套接字那樣的、可以和應用程序直接交談的界面，而是采用了一種更為底層的API，叫做傳輸驅(qū)動程序界面(Transport Driver Interface,TDI)。Winsock的核心模式驅(qū)動程序負責連接和緩沖區(qū)管理，以便向應用程序提供套接字仿真(在AFD.SYS文件中實現(xiàn))，同時負責與底層傳輸驅(qū)動程序?qū)υ挕?/p>
誰來負責管理緩沖區(qū)？
正如上面所說的，應用程序通過Winsock來和傳輸協(xié)議驅(qū)動程序交談，而AFD.SYS負責為應用程序進行緩沖區(qū)管理。也就是說，當應用程序調(diào)用 send()或WSASend()函數(shù)來發(fā)送數(shù)據(jù)時，AFD.SYS將把數(shù)據(jù)拷貝進它自己的內(nèi)部緩沖區(qū)(取決于SO_SNDBUF設(shè)定值)，然后send ()或WSASend()函數(shù)立即返回。也可以這么說，AFD.SYS在后臺負責把數(shù)據(jù)發(fā)送出去。不過，如果應用程序要求發(fā)出的數(shù)據(jù)超過了 SO_SNDBUF設(shè)定的緩沖區(qū)大小，那么WSASend()函數(shù)會阻塞，直至所有數(shù)據(jù)發(fā)送完畢。
從遠程客戶端接收數(shù)據(jù)的情況也類似。只要不用從應用程序那里接收大量的數(shù)據(jù)，而且沒有超出SO_RCVBUF設(shè)定的值，AFD.SYS將把數(shù)據(jù)先拷貝到其內(nèi)部緩沖區(qū)中。當應用程序調(diào)用recv()或WSARecv()函數(shù)時，數(shù)據(jù)將從內(nèi)部緩沖拷貝到應用程序提供的緩沖區(qū)。
多數(shù)情況下，這樣的架構(gòu)運行良好，特別在是應用程序采用傳統(tǒng)的套接字下非重疊的send()和receive()模式編寫的時候。不過程序員要小心的是，盡管可以通過setsockopt()這個API來把SO_SNDBUF和SO_RCVBUF選項值設(shè)成0(關(guān)閉內(nèi)部緩沖區(qū))，但是程序員必須十分清楚把 AFD.SYS的內(nèi)部緩沖區(qū)關(guān)掉會造成什么后果，避免收發(fā)數(shù)據(jù)時有關(guān)的緩沖區(qū)拷貝可能引起的系統(tǒng)崩潰。
舉例來說，一個應用程序通過設(shè)定SO_SNDBUF為0把緩沖區(qū)關(guān)閉，然后發(fā)出一個阻塞send()調(diào)用。在這樣的情況下，系統(tǒng)內(nèi)核會把應用程序的緩沖區(qū)鎖定，直到接收方確認收到了整個緩沖區(qū)后send()調(diào)用才返回。似乎這是一種判定你的數(shù)據(jù)是否已經(jīng)為對方全部收到的簡潔的方法，實際上卻并非如此。想想看，即使遠端TCP 通知數(shù)據(jù)已經(jīng)收到，其實也根本不代表數(shù)據(jù)已經(jīng)成功送給客戶端應用程序，比如對方可能發(fā)生資源不足的情況，導致AFD.SYS不能把數(shù)據(jù)拷貝給應用程序。另一個更要緊的問題是，在每個線程中每次只能進行一次發(fā)送調(diào)用，效率極其低下。
把SO_RCVBUF設(shè)為0，關(guān)閉AFD.SYS的接收緩沖區(qū)也不能讓性能得到提升，這只會迫使接收到的數(shù)據(jù)在比Winsock更低的層次進行緩沖，當你發(fā)出receive調(diào)用時，同樣要進行緩沖區(qū)拷貝，因此你本來想避免緩沖區(qū)拷貝的陰謀不會得逞。
現(xiàn)在我們應該清楚了，關(guān)閉緩沖區(qū)對于多數(shù)應用程序而言并不是什么好主意。只要要應用程序注意隨時在某個連接上保持幾個WSARecvs重疊調(diào)用，那么通常沒有必要關(guān)閉接收緩沖區(qū)。如果AFD.SYS總是有由應用程序提供的緩沖區(qū)可用，那么它將沒有必要使用內(nèi)部緩沖區(qū)。
高性能的服務(wù)器應用程序可以關(guān)閉發(fā)送緩沖區(qū)，同時不會損失性能。不過，這樣的應用程序必須十分小心，保證它總是發(fā)出多個重疊發(fā)送調(diào)用，而不是等待某個重疊發(fā)送結(jié)束了才發(fā)出下一個。如果應用程序是按一個發(fā)完再發(fā)下一個的順序來操作，那浪費掉兩次發(fā)送中間的空檔時間，總之是要保證傳輸驅(qū)動程序在發(fā)送完一個緩沖區(qū)后，立刻可以轉(zhuǎn)向另一個緩沖區(qū)。
資源的限制條件
在設(shè)計任何服務(wù)器應用程序時，其強健性是主要的目標。也就是說，
你的應用程序要能夠應對任何突發(fā)的問題，例如并發(fā)客戶請求數(shù)達到峰值、可用內(nèi)存臨時出現(xiàn)不足、以及其它短時間的現(xiàn)象。這就要求程序的設(shè)計者注意Windows NT和2000系統(tǒng)下的資源限制條件的問題，從容地處理突發(fā)性事件。
你可以直接控制的、最基本的資源就是網(wǎng)絡(luò)帶寬。通常，使用用戶數(shù)據(jù)報協(xié)議(UDP)的應用程序都可能會比較注意帶寬方面的限制，以最大限度地減少包的丟失。然而，在使用TCP連接時，服務(wù)器必須十分小心地控制好，防止網(wǎng)絡(luò)帶寬過載超過一定的時間，否則將需要重發(fā)大量的包或造成大量連接中斷。關(guān)于帶寬管理的方法應根據(jù)不同的應用程序而定，這超出了本文討論的范圍。
虛擬內(nèi)存的使用也必須很小心地管理。通過謹慎地申請和釋放內(nèi)存，或者應用lookaside lists(一種高速緩存)技術(shù)來重新使用已分配的內(nèi)存，將有助于控制服務(wù)器應用程序的內(nèi)存開銷(原文為“讓服務(wù)器應用程序留下的腳印小一點”)，避免操作系統(tǒng)頻繁地將應用程序申請的物理內(nèi)存交換到虛擬內(nèi)存中(原文為“讓操作系統(tǒng)能夠總是把更多的應用程序地址空間更多地保留在內(nèi)存中”)。你也可以通過 SetWorkingSetSize()這個Win32 API讓操作系統(tǒng)分配給你的應用程序更多的物理內(nèi)存。
在使用Winsock時還可能碰到另外兩個非直接的資源不足情況。一個是被鎖定的內(nèi)存頁面的極限。如果你把AFD.SYS的緩沖關(guān)閉，當應用程序收發(fā)數(shù)據(jù)時，應用程序緩沖區(qū)的所有頁面將被鎖定到物理內(nèi)存中。這是因為內(nèi)核驅(qū)動程序需要訪問這些內(nèi)存，在此期間這些頁面不能交換出去。如果操作系統(tǒng)需要給其它應用程序分配一些可分頁的物理內(nèi)存，而又沒有足夠的內(nèi)存時就會發(fā)生問題。我們的目標是要防止寫出一個病態(tài)的、鎖定所有物理內(nèi)存、讓系統(tǒng)崩潰的程序。也就是說，你的程序鎖定內(nèi)存時，不要超出系統(tǒng)規(guī)定的內(nèi)存分頁極限。
在Windows NT和2000系統(tǒng)上，所有應用程序總共可以鎖定的內(nèi)存大約是物理內(nèi)存的1/8(不過這只是一個大概的估計，不是你計算內(nèi)存的依據(jù))。如果你的應用程序不注意這一點，當你的發(fā)出太多的重疊收發(fā)調(diào)用，而且I/O沒來得及完成時，就可能偶爾發(fā)生ERROR_INSUFFICIENT_RESOURCES的錯誤。在這種情況下你要避免過度鎖定內(nèi)存。同時要注意，系統(tǒng)會鎖定包含你的緩沖區(qū)所在的整個內(nèi)存頁面，因此緩沖區(qū)靠近頁邊界時是有代價的(譯者理解，緩沖區(qū)如果正好超過頁面邊界，那怕是1個字節(jié)，超出的這個字節(jié)所在的頁面也會被鎖定)。
另外一個限制是你的程序可能會遇到系統(tǒng)未分頁池資源不足的情況。所謂未分頁池是一塊永遠不被交換出去的內(nèi)存區(qū)域，這塊內(nèi)存用來存儲一些供各種內(nèi)核組件訪問的數(shù)據(jù)，其中有的內(nèi)核組件是不能訪問那些被交換出去的頁面空間的。Windows NT和2000的驅(qū)動程序能夠從這個特定的未分頁池分配內(nèi)存。
當應用程序創(chuàng)建一個套接字(或者是類似的打開某個文件)時，內(nèi)核會從未分頁池中分配一定數(shù)量的內(nèi)存，而且在綁定、連接套接字時，內(nèi)核又會從未分頁池中再分配一些內(nèi)存。當你注意觀察這種行為時你將發(fā)現(xiàn)，如果你發(fā)出某些I/O請求時(例如收發(fā)數(shù)據(jù))，你會從未分頁池里再分配多一些內(nèi)存(比如要追蹤某個待決的 I/O操作，你可能需要給這個操作添加一個自定義結(jié)構(gòu)，如前文所提及的)。最后這就可能會造成一定的問題，操作系統(tǒng)會限制未分頁內(nèi)存的用量。
在Windows NT和2000這兩種操作系統(tǒng)上，給每個連接分配的未分頁內(nèi)存的具體數(shù)量是不同的，未來版本的Windows很可能也不同。為了使應用程序的生命期更長，你就不應該計算對未分頁池內(nèi)存的具體需求量。
你的程序必須防止消耗到未分頁池的極限。當系統(tǒng)中未分頁池剩余空間太小時，某些與你的應用程序毫無關(guān)系的內(nèi)核驅(qū)動就會發(fā)瘋，甚至造成系統(tǒng)崩潰，特別是當系統(tǒng)中有第三方設(shè)備或驅(qū)動程序時，更容易發(fā)生這樣的慘劇(而且無法預測)。同時你還要記住，同一臺電腦上還可能運行有其它同樣消耗未分頁池的其它應用程序，因此在設(shè)計你的應用程序時，對資源量的預估要特別保守和謹慎。
處理資源不足的問題是十分復雜的，因為發(fā)生上述情況時你不會收到特別的錯誤代碼，通常你只能收到一般性的WSAENOBUFS或者ERROR_INSUFFICIENT_RESOURCES 錯誤。要處理這些錯誤，首先，把你的應用程序工作配置調(diào)整到合理的最大值(譯者注：所謂工作配置，是指應用程序各部分運行中所需的內(nèi)存用量，請參考 http://msdn.microsoft.com/msdnmag/issues/1000/Bugslayer/Bugslayer1000.asp ，關(guān)于內(nèi)存優(yōu)化，譯者另有譯文)，如果錯誤繼續(xù)出現(xiàn)，那么注意檢查是否是網(wǎng)絡(luò)帶寬不足的問題。之后，請確認你沒有同時發(fā)出太多的收發(fā)調(diào)用。最后，如果還是收到資源不足的錯誤，那就很可能是遇到了未分頁內(nèi)存池不足的問題了。要釋放未分頁內(nèi)存池空間，請關(guān)閉應用程序中相當部分的連接，等待系統(tǒng)自行渡過和修正這個瞬時的錯誤。
接受連接請求
服務(wù)器要做的最普通的事情之一就是接受來自客戶端的連接請求。在套接字上使用重疊I/O接受連接的惟一API就是AcceptEx()函數(shù)。有趣的是，通常的同步接受函數(shù)accept()的返回值是一個新的套接字，而AcceptEx()函數(shù)則需要另外一個套接字作為它的參數(shù)之一。這是因為 AcceptEx()是一個重疊操作，所以你需要事先創(chuàng)建一個套接字(但不要綁定或連接它)，并把這個套接字通過參數(shù)傳給AcceptEx()。以下是一小段典型的使用AcceptEx()的偽代碼：
do {
-等待上一個 AcceptEx 完成
-創(chuàng)建一個新套接字并與完成端口進行關(guān)聯(lián)
-設(shè)置背景結(jié)構(gòu)等等
-發(fā)出一個 AcceptEx 請求
}while(TRUE);作為一個高響應能力的服務(wù)器，它必須發(fā)出足夠的AcceptEx調(diào)用，守候著，一旦出現(xiàn)客戶端連接請求就立刻響應。至于發(fā)出多少個AcceptEx才夠，就取決于你的服務(wù)器程序所期待的通信交通類型。比如，如果進入連接率高的情況(因為連接持續(xù)時間較短，或者出現(xiàn)交通高峰)，那么所需要守候的 AcceptEx當然要比那些偶爾進入的客戶端連接的情況要多。聰明的做法是，由應用程序來分析交通狀況，并調(diào)整AcceptEx守候的數(shù)量，而不是固定在某個數(shù)量上。
對于Windows2000，Winsock提供了一些機制，幫助你判定AcceptEx的數(shù)量是否足夠。這就是，在創(chuàng)建監(jiān)聽套接字時創(chuàng)建一個事件，通過WSAEventSelect()這個API并注冊FD_ACCEPT事件通知來把套接字和這個事件關(guān)聯(lián)起來。一旦系統(tǒng)收到一個連接請求，如果系統(tǒng)中沒有AcceptEx()正在等待接受連接，那么上面的事件將收到一個信號。通過這個事件，你就可以判斷你有沒有發(fā)出足夠的 AcceptEx()，或者檢測出一個非正常的客戶請求(下文述)。這種機制對Windows NT 4.0不適用。
使用AcceptEx()的一大好處是，你可以通過一次調(diào)用就完成接受客戶端連接請求和接受數(shù)據(jù)(通過傳送lpOutputBuffer參數(shù))兩件事情。也就是說，如果客戶端在發(fā)出連接的同時傳輸數(shù)據(jù)，你的AcceptEx()調(diào)用在連接創(chuàng)建并接收了客戶端數(shù)據(jù)后就可以立刻返回。這樣可能是很有用的，但是也可能會引發(fā)問題，因為AcceptEx()必須等全部客戶端數(shù)據(jù)都收到了才返回。具體來說，如果你在發(fā)出AcceptEx()調(diào)用的同時傳遞了lpOutputBuffer參數(shù)，那么AcceptEx()不再是一項原子型的操作，而是分成了兩步：接受客戶連接，等待接收數(shù)據(jù)。當缺少一種機制來通知你的應用程序所發(fā)生的這種情況：“連接已經(jīng)建立了，正在等待客戶端數(shù)據(jù)”，這將意味著有可能出現(xiàn)客戶端只發(fā)出連接請求，但是不發(fā)送數(shù)據(jù)。如果你的服務(wù)器收到太多這種類型的連接時，它將拒絕連接更多的合法客戶端請求。這就是黑客進行“拒絕服務(wù)”攻擊的常見手法。
要預防此類攻擊，接受連接的線程應該不時地通過調(diào)用getsockopt()函數(shù)(選項參數(shù)為 SO_CONNECT_TIME)來檢查AcceptEx()里守候的套接字。getsockopt()函數(shù)的選項值將被設(shè)置為套接字被連接的時間，或者設(shè)置為-1(代表套接字尚未建立連接)。這時，WSAEventSelect()的特性就可以很好地利用來做這種檢查。如果發(fā)現(xiàn)連接已經(jīng)建立，但是很久都沒有收到數(shù)據(jù)的情況，那么就應該終止連接，方法就是關(guān)閉作為參數(shù)提供給AcceptEx()的那個套接字。注意，在多數(shù)非緊急情況下，如果套接字已經(jīng)傳遞給AcceptEx()并開始守候，但還未建立連接，那么你的應用程序不應該關(guān)閉它們。這是因為即使關(guān)閉了這些套接字，出于提高系統(tǒng)性能的考慮，在連接進入之前，或者監(jiān)聽套接字自身被關(guān)閉之前，相應的內(nèi)核模式的數(shù)據(jù)結(jié)構(gòu)也不會被干凈地清除。
發(fā)出AcceptEx()調(diào)用的線程，似乎與那個進行完成端口關(guān)聯(lián)操作、處理其它I/O完成通知的線程是同一個，但是，別忘記線程里應該盡力避免執(zhí)行阻塞型的操作。Winsock2分層結(jié)構(gòu)的一個副作用是調(diào)用socket()或WSASocket() API的上層架構(gòu)可能很重要(譯者不太明白原文意思，抱歉)。每個AcceptEx()調(diào)用都需要創(chuàng)建一個新套接字，所以最好有一個獨立的線程專門調(diào)用AcceptEx()，而不參與其它I/O處理。你也可以利用這個線程來執(zhí)行其它任務(wù)，比如事件記錄。
有關(guān)AcceptEx()的最后一個注意事項：要實現(xiàn)這些API，并不需要其它提供商提供的Winsock2實現(xiàn)。這一點對微軟特有的其它API也同樣適用，比如TransmitFile()和GetAcceptExSockAddrs()，以及其它可能會被加入到新版Windows的API. 在Windows NT和2000上，這些API是在微軟的底層提供者DLL(mswsock.dll)中實現(xiàn)的，可通過與mswsock.lib編譯連接進行調(diào)用，或者通過WSAIoctl() (選項參數(shù)為SIO_GET_EXTENSION_FUNCTION_POINTER)動態(tài)獲得函數(shù)的指針。
如果在沒有事先獲得函數(shù)指針的情況下直接調(diào)用函數(shù)(也就是說，編譯時靜態(tài)連接mswsock.lib，在程序中直接調(diào)用函數(shù))，那么性能將很受影響。因為 AcceptEx()被置于Winsock2架構(gòu)之外，每次調(diào)用時它都被迫通過WSAIoctl()取得函數(shù)指針。要避免這種性能損失，需要使用這些 API的應用程序應該通過調(diào)用WSAIoctl()直接從底層的提供者那里取得函數(shù)的指針。
參見下圖套接字架構(gòu)：
TransmitFile 和 TransmitPackets
Winsock 提供兩個專門為文件和內(nèi)存數(shù)據(jù)傳輸進行了優(yōu)化的函數(shù)。其中TransmitFile()這個API函數(shù)在Windows NT 4.0 和 Windows 2000上都可以使用，而TransmitPackets()則將在未來版本的Windows中實現(xiàn)。
TransmitFile ()用來把文件內(nèi)容通過Winsock進行傳輸。通常發(fā)送文件的做法是，先調(diào)用CreateFile()打開一個文件，然后不斷循環(huán)調(diào)用ReadFile () 和WSASend ()直至數(shù)據(jù)發(fā)送完畢。但是這種方法很沒有效率，因為每次調(diào)用ReadFile() 和 WSASend ()都會涉及一次從用戶模式到內(nèi)核模式的轉(zhuǎn)換。如果換成TransmitFile()，那么只需要給它一個已打開文件的句柄和要發(fā)送的字節(jié)數(shù)，而所涉及的模式轉(zhuǎn)換操作將只在調(diào)用CreateFile()打開文件時發(fā)生一次，然后TransmitFile()時再發(fā)生一次。這樣效率就高多了。
TransmitPackets()比TransmitFile()更進一步，它允許用戶只調(diào)用一次就可以發(fā)送指定的多個文件和內(nèi)存緩沖區(qū)。函數(shù)原型如下：
BOOL TransmitPackets(
SOCKET hSocket,
LPTRANSMIT_PACKET_ELEMENT lpPacketArray,
DWORD nElementCount,
DWORD nSendSize,
LPOVERLAPPED lpOverlapped,
DWORD dwFlags
);
其中，lpPacketArray是一個結(jié)構(gòu)的數(shù)組，其中的每個元素既可以是一個文件句柄或者內(nèi)存緩沖區(qū)，該結(jié)構(gòu)定義如下：
typedef struct _TRANSMIT_PACKETS_ELEMENT {
DWORD dwElFlags;
DWORD cLength;
union {
struct {
LARGE_INTEGER nFileOffset;
HANDLE hFile;
};
PVOID pBuffer;
};
} TRANSMIT_FILE_BUFFERS;
其中各字段是自描述型的(self explanatory)。
dwElFlags字段：指定當前元素是一個文件句柄還是內(nèi)存緩沖區(qū)(分別通過常量TF_ELEMENT_FILE 和TF_ELEMENT_MEMORY指定)；
cLength字段：指定將從數(shù)據(jù)源發(fā)送的字節(jié)數(shù)(如果是文件，這個字段值為0表示發(fā)送整個文件)；
結(jié)構(gòu)中的無名聯(lián)合體：包含文件句柄的內(nèi)存緩沖區(qū)(以及可能的偏移量)。
使用這兩個API的另一個好處，是可以通過指定TF_REUSE_SOCKET和TF_DISCONNECT標志來重用套接字句柄。每當API完成數(shù)據(jù)的傳輸工作后，就會在傳輸層級別斷開連接，這樣這個套接字就又可以重新提供給AcceptEx()使用。采用這種優(yōu)化的方法編程，將減輕那個專門做接受操作的線程創(chuàng)建套接字的壓力(前文述及)。
這兩個API也都有一個共同的弱點：Windows NT Workstation 或 Windows 2000 專業(yè)版中，函數(shù)每次只能處理兩個調(diào)用請求，只有在Windows NT、Windows 2000服務(wù)器版、Windows 2000高級服務(wù)器版或 Windows 2000 Data Center中才獲得完全支持。
放在一起看看
以上各節(jié)中，我們討論了開發(fā)高性能的、大響應規(guī)模的應用程序所需的函數(shù)、方法和可能遇到的資源瓶頸問題。這些對你意味著什么呢？其實，這取決于你如何構(gòu)造你的服務(wù)器和客戶端。當你能夠在服務(wù)器和客戶端設(shè)計上進行更好地控制時，那么你越能夠避開瓶頸問題。
來看一個示范的環(huán)境。我們要設(shè)計一個服務(wù)器來響應客戶端的連接、發(fā)送請求、接收數(shù)據(jù)以及斷開連接。那么，服務(wù)器將需要創(chuàng)建一個監(jiān)聽套接字，把它與某個完成端口進行關(guān)聯(lián)，為每顆CPU創(chuàng)建一個工作線程。再創(chuàng)建一個線程專門用來發(fā)出AcceptEx()。我們知道客戶端會在發(fā)出連接請求后立刻傳送數(shù)據(jù)，所以如果我們準備好接收緩沖區(qū)會使事情變得更為容易。當然，不要忘記不時地輪詢AcceptEx()調(diào)用中使用的套接字(使用SO_CONNECT_TIME選項參數(shù))來確保沒有惡意超時的連接。
該設(shè)計中有一個重要的問題要考慮，我們應該允許多少個AcceptEx()進行守候。這是因為，每發(fā)出一個AcceptEx()時我們都同時需要為它提供一個接收緩沖區(qū)，那么內(nèi)存中將會出現(xiàn)很多被鎖定的頁面(前文說過了，每個重疊操作都會消耗一小部分未分頁內(nèi)存池，同時還會鎖定所有涉及的緩沖區(qū))。這個問題很難回答，沒有一個確切的答案。最好的方法是把這個值做成可以調(diào)整的，通過反復做性能測試，你就可以得出在典型應用環(huán)境中最佳的值。
好了，當你測算清楚后，下面就是發(fā)送數(shù)據(jù)的問題了，考慮的重點是你希望服務(wù)器同時處理多少個并發(fā)的連接。通常情況下，服務(wù)器應該限制并發(fā)連接的數(shù)量以及等候處理的發(fā)送調(diào)用。因為并發(fā)連接數(shù)量越多，所消耗的未分頁內(nèi)存池也越多；等候處理的發(fā)送調(diào)用越多，被鎖定的內(nèi)存頁面也越多(小心別超過了極限)。這同樣也需要反復測試才知道答案。
對于上述環(huán)境，通常不需要關(guān)閉單個套接字的緩沖區(qū)，因為只在AcceptEx()中有一次接收數(shù)據(jù)的操作，而要保證給每個到來的連接提供接收緩沖區(qū)并不是太難的事情。但是，如果客戶機與服務(wù)器交互的方式變一變，客戶機在發(fā)送了一次數(shù)據(jù)之后，還需要發(fā)送更多的數(shù)據(jù)，在這種情況下關(guān)閉接收緩沖就不太妙了，除非你想辦法保證在每個連接上都發(fā)出了重疊接收調(diào)用來接收更多的數(shù)據(jù)。
結(jié)論
開發(fā)大響應規(guī)模的Winsock服務(wù)器并不是很可怕，其實也就是設(shè)置一個監(jiān)聽套接字、接受連接請求和進行重疊收發(fā)調(diào)用。通過設(shè)置合理的進行守候的重疊調(diào)用的數(shù)量，防止出現(xiàn)未分頁內(nèi)存池被耗盡，這才是最主要的挑戰(zhàn)。按照我們前面討論的一些原則，你就可以開發(fā)出大響應規(guī)模的服務(wù)器應用程序。