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