原文出處:
http://msdn.microsoft.com/msdnmag/issues/1000/Winsock/通常要開發(fā)網(wǎng)絡(luò)應(yīng)用程序并不是一件輕松的事情,不過,實(shí)際上只要掌握幾個(gè)關(guān)鍵的原則也就可以了——?jiǎng)?chuàng)建和連接一個(gè)套接字,嘗試進(jìn)行連接,然后收發(fā)數(shù)據(jù)。真正難的是要寫出一個(gè)可以接納少則一個(gè),多則數(shù)千個(gè)連接的網(wǎng)絡(luò)應(yīng)用程序。本文將討論如何通過Winsock2在Windows NT 和 Windows 2000上開發(fā)高擴(kuò)展能力的Winsock應(yīng)用程序。文章主要的焦點(diǎn)在客戶機(jī)/服務(wù)器模型的服務(wù)器這一方,當(dāng)然,其中的許多要點(diǎn)對(duì)模型的雙方都適用。
API與響應(yīng)規(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í)的操作而言特別有用。不過,像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ù)量的工作者線程來處理這些通知。線程數(shù)量取決于應(yīng)用程序的特定需要。理想的情況是,線程數(shù)量等于處理器的數(shù)量,不過這也要求任何線程都不應(yīng)該執(zhí)行諸如同步讀寫、等待事件通知等阻塞型的操作,以免線程阻塞。每個(gè)線程都將分到一定的CPU時(shí)間,在此期間該線程可以運(yùn)行,然后另一個(gè)線程將分到一個(gè)時(shí)間片并開始執(zhí)行。如果某個(gè)線程執(zhí)行了阻塞型的操作,操作系統(tǒng)將剝奪其未使用的剩余時(shí)間片并讓其它線程開始執(zhí)行。也就是說,前一個(gè)線程沒有充分使用其時(shí)間片,當(dāng)發(fā)生這樣的情況時(shí),應(yīng)用程序應(yīng)該準(zhǔn)備其它線程來充分利用這些時(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)起來。方法是再次調(diào)用CreateIoCompletionPort ()函數(shù),第一個(gè)參數(shù)FileHandle設(shè)為套接字的句柄,第二個(gè)參數(shù)ExistingCompletionPort 設(shè)為剛剛創(chuàng)建的那個(gè)完成端口的句柄。
以下代碼創(chuàng)建了一個(gè)套接字,并把它和前面創(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

}




}

這時(shí)就完成了套接字與完成端口的關(guān)聯(lián)操作。在這個(gè)套接字上進(jìn)行的任何重疊操作都將通過完成端口發(fā)出完成通知。注意,CreateIoCompletionPort()函數(shù)中的第三個(gè)參數(shù)用來設(shè)置一個(gè)與該套接字相關(guān)的“完成鍵(completion key)”(譯者注:完成鍵可以是任何數(shù)據(jù)類型)。每當(dāng)完成通知到來時(shí),應(yīng)用程序可以讀取相應(yīng)的完成鍵,因此,完成鍵可用來給套接字傳遞一些背景信息。
在創(chuàng)建了完成端口、將一個(gè)或多個(gè)套接字與之相關(guān)聯(lián)之后,我們就要?jiǎng)?chuàng)建若干個(gè)線程來處理完成通知。這些線程不斷循環(huán)調(diào)用GetQueuedCompletionStatus ()函數(shù)并返回完成通知。
下面,我們先來看看應(yīng)用程序如何跟蹤這些重疊操作。當(dāng)應(yīng)用程序調(diào)用一個(gè)重疊操作函數(shù)時(shí),要把指向一個(gè)overlapped結(jié)構(gòu)的指針包括在其參數(shù)中。當(dāng)操作完成后,我們可以通過GetQueuedCompletionStatus()函數(shù)中拿回這個(gè)指針。不過,單是根據(jù)這個(gè)指針?biāo)赶虻膐verlapped結(jié)構(gòu),應(yīng)用程序并不能分辨究竟完成的是哪個(gè)操作。要實(shí)現(xiàn)對(duì)操作的跟蹤,你可以自己定義一個(gè)OVERLAPPED結(jié)構(gòu),在其中加入所需的跟蹤信息。
無論何時(shí)調(diào)用重疊操作函數(shù)時(shí),總是會(huì)通過其lpOverlapped參數(shù)傳遞一個(gè)OVERLAPPEDPLUS結(jié)構(gòu)(例如WSASend、 WSARecv等函數(shù))。這就允許你為每一個(gè)重疊調(diào)用操作設(shè)置某些操作狀態(tài)信息,當(dāng)操作結(jié)束后,你可以通過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

下面讓我們來看看工作者線程的情況。
工作線程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í)(也就是說,返回值是SOCKET_ERROR,并且錯(cuò)誤原因不是WSA_IO_PENDING),那么完成端口將不會(huì)收到任何完成通知。如果重疊操作調(diào)用成功,或者發(fā)生原因是WSA_IO_PENDING的錯(cuò)誤時(shí),完成端口將總是能夠收到完成通知。
Windows NT和Windows 2000的套接字架構(gòu)
對(duì)于開發(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é)議沒有一種風(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>
誰來負(fù)責(zé)管理緩沖區(qū)?
正如上面所說的,應(yīng)用程序通過Winsock來和傳輸協(xié)議驅(qū)動(dòng)程序交談,而AFD.SYS負(fù)責(zé)為應(yīng)用程序進(jìn)行緩沖區(qū)管理。也就是說,當(dāng)應(yīng)用程序調(diào)用send()或WSASend()函數(shù)來發(fā)送數(shù)據(jù)時(shí),AFD.SYS將把數(shù)據(jù)拷貝進(jìn)它自己的內(nèi)部緩沖區(qū)(取決于SO_SNDBUF設(shè)定值),然后send()或WSASend()函數(shù)立即返回。也可以這么說,AFD.SYS在后臺(tái)負(fù)責(zé)把數(shù)據(jù)發(fā)送出去。不過,如果應(yīng)用程序要求發(fā)出的數(shù)據(jù)超過了SO_SNDBUF設(shè)定的緩沖區(qū)大小,那么WSASend()函數(shù)會(huì)阻塞,直至所有數(shù)據(jù)發(fā)送完畢。
從遠(yuǎn)程客戶端接收數(shù)據(jù)的情況也類似。只要不用從應(yīng)用程序那里接收大量的數(shù)據(jù),而且沒有超出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()模式編寫的時(shí)候。不過程序員要小心的是,盡管可以通過setsockopt()這個(gè)API來把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)崩潰。
舉例來說,一個(gè)應(yīng)用程序通過設(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ì)方全部收到的簡潔的方法,實(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è)更要緊的問題是,在每個(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ū)拷貝,因此你本來想避免緩沖區(qū)拷貝的陰謀不會(huì)得逞。
現(xiàn)在我們應(yīng)該清楚了,關(guān)閉緩沖區(qū)對(duì)于多數(shù)應(yīng)用程序而言并不是什么好主意。只要要應(yīng)用程序注意隨時(shí)在某個(gè)連接上保持幾個(gè)WSARecvs重疊調(diào)用,那么通常沒有必要關(guān)閉接收緩沖區(qū)。如果AFD.SYS總是有由應(yīng)用程序提供的緩沖區(qū)可用,那么它將沒有必要使用內(nèi)部緩沖區(qū)。
高性能的服務(wù)器應(yīng)用程序可以關(guān)閉發(fā)送緩沖區(qū),同時(shí)不會(huì)損失性能。不過,這樣的應(yīng)用程序必須十分小心,保證它總是發(fā)出多個(gè)重疊發(fā)送調(diào)用,而不是等待某個(gè)重疊發(fā)送結(jié)束了才發(fā)出下一個(gè)。如果應(yīng)用程序是按一個(gè)發(fā)完再發(fā)下一個(gè)的順序來操作,那浪費(fèi)掉兩次發(fā)送中間的空檔時(shí)間,總之是要保證傳輸驅(qū)動(dòng)程序在發(fā)送完一個(gè)緩沖區(qū)后,立刻可以轉(zhuǎn)向另一個(gè)緩沖區(qū)。
資源的限制條件
在設(shè)計(jì)任何服務(wù)器應(yīng)用程序時(shí),其強(qiáng)健性是主要的目標(biāo)。也就是說,
你的應(yīng)用程序要能夠應(yīng)對(duì)任何突發(fā)的問題,例如并發(fā)客戶請(qǐng)求數(shù)達(dá)到峰值、可用內(nèi)存臨時(shí)出現(xiàn)不足、以及其它短時(shí)間的現(xiàn)象。這就要求程序的設(shè)計(jì)者注意Windows NT和2000系統(tǒng)下的資源限制條件的問題,從容地處理突發(fā)性事件。
你可以直接控制的、最基本的資源就是網(wǎng)絡(luò)帶寬。通常,使用用戶數(shù)據(jù)報(bào)協(xié)議(UDP)的應(yīng)用程序都可能會(huì)比較注意帶寬方面的限制,以最大限度地減少包的丟失。然而,在使用TCP連接時(shí),服務(wù)器必須十分小心地控制好,防止網(wǎng)絡(luò)帶寬過載超過一定的時(shí)間,否則將需要重發(fā)大量的包或造成大量連接中斷。關(guān)于帶寬管理的方法應(yīng)根據(jù)不同的應(yīng)用程序而定,這超出了本文討論的范圍。
虛擬內(nèi)存的使用也必須很小心地管理。通過謹(jǐn)慎地申請(qǐng)和釋放內(nèi)存,或者應(yīng)用lookaside lists(一種高速緩存)技術(shù)來重新使用已分配的內(nèi)存,將有助于控制服務(wù)器應(yīng)用程序的內(nèi)存開銷(原文為“讓服務(wù)器應(yīng)用程序留下的腳印小一點(diǎn)”),避免操作系統(tǒng)頻繁地將應(yīng)用程序申請(qǐng)的物理內(nèi)存交換到虛擬內(nèi)存中(原文為“讓操作系統(tǒng)能夠總是把更多的應(yīng)用程序地址空間更多地保留在內(nèi)存中”)。你也可以通過SetWorkingSetSize()這個(gè)Win32 API讓操作系統(tǒng)分配給你的應(yīng)用程序更多的物理內(nèi)存。
在使用Winsock時(shí)還可能碰到另外兩個(gè)非直接的資源不足情況。一個(gè)是被鎖定的內(nèi)存頁面的極限。如果你把AFD.SYS的緩沖關(guān)閉,當(dāng)應(yīng)用程序收發(fā)數(shù)據(jù)時(shí),應(yīng)用程序緩沖區(qū)的所有頁面將被鎖定到物理內(nèi)存中。這是因?yàn)閮?nèi)核驅(qū)動(dòng)程序需要訪問這些內(nèi)存,在此期間這些頁面不能交換出去。如果操作系統(tǒng)需要給其它應(yīng)用程序分配一些可分頁的物理內(nèi)存,而又沒有足夠的內(nèi)存時(shí)就會(huì)發(fā)生問題。我們的目標(biāo)是要防止寫出一個(gè)病態(tài)的、鎖定所有物理內(nèi)存、讓系統(tǒng)崩潰的程序。也就是說,你的程序鎖定內(nèi)存時(shí),不要超出系統(tǒng)規(guī)定的內(nèi)存分頁極限。
在Windows NT和2000系統(tǒng)上,所有應(yīng)用程序總共可以鎖定的內(nèi)存大約是物理內(nèi)存的1/8(不過這只是一個(gè)大概的估計(jì),不是你計(jì)算內(nèi)存的依據(jù))。如果你的應(yīng)用程序不注意這一點(diǎn),當(dāng)你的發(fā)出太多的重疊收發(fā)調(diào)用,而且I/O沒來得及完成時(shí),就可能偶爾發(fā)生ERROR_INSUFFICIENT_RESOURCES的錯(cuò)誤。在這種情況下你要避免過度鎖定內(nèi)存。同時(shí)要注意,系統(tǒng)會(huì)鎖定包含你的緩沖區(qū)所在的整個(gè)內(nèi)存頁面,因此緩沖區(qū)靠近頁邊界時(shí)是有代價(jià)的(譯者理解,緩沖區(qū)如果正好超過頁面邊界,那怕是1個(gè)字節(jié),超出的這個(gè)字節(jié)所在的頁面也會(huì)被鎖定)。
另外一個(gè)限制是你的程序可能會(huì)遇到系統(tǒng)未分頁池資源不足的情況。所謂未分頁池是一塊永遠(yuǎn)不被交換出去的內(nèi)存區(qū)域,這塊內(nèi)存用來存儲(chǔ)一些供各種內(nèi)核組件訪問的數(shù)據(jù),其中有的內(nèi)核組件是不能訪問那些被交換出去的頁面空間的。Windows NT和2000的驅(qū)動(dòng)程序能夠從這個(gè)特定的未分頁池分配內(nèi)存。
當(dāng)應(yīng)用程序創(chuàng)建一個(gè)套接字(或者是類似的打開某個(gè)文件)時(shí),內(nèi)核會(huì)從未分頁池中分配一定數(shù)量的內(nèi)存,而且在綁定、連接套接字時(shí),內(nèi)核又會(huì)從未分頁池中再分配一些內(nèi)存。當(dāng)你注意觀察這種行為時(shí)你將發(fā)現(xiàn),如果你發(fā)出某些I/O請(qǐng)求時(shí)(例如收發(fā)數(shù)據(jù)),你會(huì)從未分頁池里再分配多一些內(nèi)存(比如要追蹤某個(gè)待決的I/O操作,你可能需要給這個(gè)操作添加一個(gè)自定義結(jié)構(gòu),如前文所提及的)。最后這就可能會(huì)造成一定的問題,操作系統(tǒng)會(huì)限制未分頁內(nèi)存的用量。
在Windows NT和2000這兩種操作系統(tǒng)上,給每個(gè)連接分配的未分頁內(nèi)存的具體數(shù)量是不同的,未來版本的Windows很可能也不同。為了使應(yīng)用程序的生命期更長,你就不應(yīng)該計(jì)算對(duì)未分頁池內(nèi)存的具體需求量。
你的程序必須防止消耗到未分頁池的極限。當(dāng)系統(tǒng)中未分頁池剩余空間太小時(shí),某些與你的應(yīng)用程序毫無關(guān)系的內(nèi)核驅(qū)動(dòng)就會(huì)發(fā)瘋,甚至造成系統(tǒng)崩潰,特別是當(dāng)系統(tǒng)中有第三方設(shè)備或驅(qū)動(dòng)程序時(shí),更容易發(fā)生這樣的慘劇(而且無法預(yù)測)。同時(shí)你還要記住,同一臺(tái)電腦上還可能運(yùn)行有其它同樣消耗未分頁池的其它應(yīng)用程序,因此在設(shè)計(jì)你的應(yīng)用程序時(shí),對(duì)資源量的預(yù)估要特別保守和謹(jǐ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ò)帶寬不足的問題。之后,請(qǐng)確認(rèn)你沒有同時(shí)發(fā)出太多的收發(fā)調(diào)用。最后,如果還是收到資源不足的錯(cuò)誤,那就很可能是遇到了未分頁內(nèi)存池不足的問題了。要釋放未分頁內(nèi)存池空間,請(qǐng)關(guān)閉應(yīng)用程序中相當(dāng)部分的連接,等待系統(tǒng)自行渡過和修正這個(gè)瞬時(shí)的錯(cuò)誤。
接受連接請(qǐng)求
服務(wù)器要做的最普通的事情之一就是接受來自客戶端的連接請(qǐng)求。在套接字上使用重疊I/O接受連接的惟一API就是AcceptEx()函數(shù)。有趣的是,通常的同步接受函數(shù)accept()的返回值是一個(gè)新的套接字,而AcceptEx()函數(shù)則需要另外一個(gè)套接字作為它的參數(shù)之一。這是因?yàn)锳cceptEx()是一個(gè)重疊操作,所以你需要事先創(chuàng)建一個(gè)套接字(但不要綁定或連接它),并把這個(gè)套接字通過參數(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)用程序來分析交通狀況,并調(diào)整AcceptEx守候的數(shù)量,而不是固定在某個(gè)數(shù)量上。
對(duì)于Windows2000,Winsock提供了一些機(jī)制,幫助你判定AcceptEx的數(shù)量是否足夠。這就是,在創(chuàng)建監(jiān)聽套接字時(shí)創(chuàng)建一個(gè)事件,通過WSAEventSelect()這個(gè)API并注冊(cè)FD_ACCEPT事件通知來把套接字和這個(gè)事件關(guān)聯(lián)起來。一旦系統(tǒng)收到一個(gè)連接請(qǐng)求,如果系統(tǒng)中沒有AcceptEx()正在等待接受連接,那么上面的事件將收到一個(gè)信號(hào)。通過這個(gè)事件,你就可以判斷你有沒有發(fā)出足夠的AcceptEx(),或者檢測出一個(gè)非正常的客戶請(qǐng)求(下文述)。這種機(jī)制對(duì)Windows NT 4.0不適用。
使用AcceptEx()的一大好處是,你可以通過一次調(diào)用就完成接受客戶端連接請(qǐng)求和接受數(shù)據(jù)(通過傳送lpOutputBuffer參數(shù))兩件事情。也就是說,如果客戶端在發(fā)出連接的同時(shí)傳輸數(shù)據(jù),你的AcceptEx()調(diào)用在連接創(chuàng)建并接收了客戶端數(shù)據(jù)后就可以立刻返回。這樣可能是很有用的,但是也可能會(huì)引發(fā)問題,因?yàn)锳cceptEx()必須等全部客戶端數(shù)據(jù)都收到了才返回。具體來說,如果你在發(fā)出AcceptEx()調(diào)用的同時(shí)傳遞了lpOutputBuffer參數(shù),那么AcceptEx()不再是一項(xiàng)原子型的操作,而是分成了兩步:接受客戶連接,等待接收數(shù)據(jù)。當(dāng)缺少一種機(jī)制來通知你的應(yīng)用程序所發(fā)生的這種情況:“連接已經(jīng)建立了,正在等待客戶端數(shù)據(jù)”,這將意味著有可能出現(xiàn)客戶端只發(fā)出連接請(qǐng)求,但是不發(fā)送數(shù)據(jù)。如果你的服務(wù)器收到太多這種類型的連接時(shí),它將拒絕連接更多的合法客戶端請(qǐng)求。這就是黑客進(jìn)行“拒絕服務(wù)”攻擊的常見手法。
要預(yù)防此類攻擊,接受連接的線程應(yīng)該不時(shí)地通過調(diào)用getsockopt()函數(shù)(選項(xiàng)參數(shù)為SO_CONNECT_TIME)來檢查AcceptEx()里守候的套接字。getsockopt()函數(shù)的選項(xiàng)值將被設(shè)置為套接字被連接的時(shí)間,或者設(shè)置為-1(代表套接字尚未建立連接)。這時(shí),WSAEventSelect()的特性就可以很好地利用來做這種檢查。如果發(fā)現(xiàn)連接已經(jīng)建立,但是很久都沒有收到數(shù)據(jù)的情況,那么就應(yīng)該終止連接,方法就是關(guān)閉作為參數(shù)提供給AcceptEx()的那個(gè)套接字。注意,在多數(shù)非緊急情況下,如果套接字已經(jīng)傳遞給AcceptEx()并開始守候,但還未建立連接,那么你的應(yīng)用程序不應(yīng)該關(guān)閉它們。這是因?yàn)榧词龟P(guān)閉了這些套接字,出于提高系統(tǒng)性能的考慮,在連接進(jìn)入之前,或者監(jiān)聽套接字自身被關(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ú)立的線程專門調(diào)用AcceptEx(),而不參與其它I/O處理。你也可以利用這個(gè)線程來執(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)的,可通過與mswsock.lib編譯連接進(jìn)行調(diào)用,或者通過WSAIoctl() (選項(xiàng)參數(shù)為SIO_GET_EXTENSION_FUNCTION_POINTER)動(dòng)態(tài)獲得函數(shù)的指針。
如果在沒有事先獲得函數(shù)指針的情況下直接調(diào)用函數(shù)(也就是說,編譯時(shí)靜態(tài)連接mswsock.lib,在程序中直接調(diào)用函數(shù)),那么性能將很受影響。因?yàn)锳cceptEx()被置于Winsock2架構(gòu)之外,每次調(diào)用時(shí)它都被迫通過WSAIoctl()取得函數(shù)指針。要避免這種性能損失,需要使用這些API的應(yīng)用程序應(yīng)該通過調(diào)用WSAIoctl()直接從底層的提供者那里取得函數(shù)的指針。
參見下圖套接字架構(gòu):
TransmitFile 和 TransmitPackets
Winsock 提供兩個(gè)專門為文件和內(nèi)存數(shù)據(jù)傳輸進(jìn)行了優(yōu)化的函數(shù)。其中TransmitFile()這個(gè)API函數(shù)在Windows NT 4.0 和 Windows 2000上都可以使用,而TransmitPackets()則將在未來版本的Windows中實(shí)現(xiàn)。
TransmitFile()用來把文件內(nèi)容通過Winsock進(jìn)行傳輸。通常發(fā)送文件的做法是,先調(diào)用CreateFile()打開一個(gè)文件,然后不斷循環(huán)調(diào)用ReadFile() 和WSASend ()直至數(shù)據(jù)發(fā)送完畢。但是這種方法很沒有效率,因?yàn)槊看握{(diào)用ReadFile() 和 WSASend ()都會(huì)涉及一次從用戶模式到內(nèi)核模式的轉(zhuǎn)換。如果換成TransmitFile(),那么只需要給它一個(gè)已打開文件的句柄和要發(fā)送的字節(jié)數(shù),而所涉及的模式轉(zhuǎn)換操作將只在調(diào)用CreateFile()打開文件時(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ū)(分別通過常量TF_ELEMENT_FILE 和TF_ELEMENT_MEMORY指定);
cLength字段:指定將從數(shù)據(jù)源發(fā)送的字節(jié)數(shù)(如果是文件,這個(gè)字段值為0表示發(fā)送整個(gè)文件);
結(jié)構(gòu)中的無名聯(lián)合體:包含文件句柄的內(nèi)存緩沖區(qū)(以及可能的偏移量)。
使用這兩個(gè)API的另一個(gè)好處,是可以通過指定TF_REUSE_SOCKET和TF_DISCONNECT標(biāo)志來重用套接字句柄。每當(dāng)API完成數(shù)據(jù)的傳輸工作后,就會(huì)在傳輸層級(jí)別斷開連接,這樣這個(gè)套接字就又可以重新提供給AcceptEx()使用。采用這種優(yōu)化的方法編程,將減輕那個(gè)專門做接受操作的線程創(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é)中,我們討論了開發(fā)高性能的、大響應(yīng)規(guī)模的應(yīng)用程序所需的函數(shù)、方法和可能遇到的資源瓶頸問題。這些對(duì)你意味著什么呢?其實(shí),這取決于你如何構(gòu)造你的服務(wù)器和客戶端。當(dāng)你能夠在服務(wù)器和客戶端設(shè)計(jì)上進(jìn)行更好地控制時(shí),那么你越能夠避開瓶頸問題。
來看一個(gè)示范的環(huán)境。我們要設(shè)計(jì)一個(gè)服務(wù)器來響應(yīng)客戶端的連接、發(fā)送請(qǐng)求、接收數(shù)據(jù)以及斷開連接。那么,服務(wù)器將需要?jiǎng)?chuàng)建一個(gè)監(jiān)聽套接字,把它與某個(gè)完成端口進(jìn)行關(guān)聯(lián),為每顆CPU創(chuàng)建一個(gè)工作線程。再創(chuàng)建一個(gè)線程專門用來發(fā)出AcceptEx()。我們知道客戶端會(huì)在發(fā)出連接請(qǐng)求后立刻傳送數(shù)據(jù),所以如果我們準(zhǔn)備好接收緩沖區(qū)會(huì)使事情變得更為容易。當(dāng)然,不要忘記不時(shí)地輪詢AcceptEx()調(diào)用中使用的套接字(使用SO_CONNECT_TIME選項(xiàng)參數(shù))來確保沒有惡意超時(shí)的連接。
該設(shè)計(jì)中有一個(gè)重要的問題要考慮,我們應(yīng)該允許多少個(gè)AcceptEx()進(jìn)行守候。這是因?yàn)椋堪l(fā)出一個(gè)AcceptEx()時(shí)我們都同時(shí)需要為它提供一個(gè)接收緩沖區(qū),那么內(nèi)存中將會(huì)出現(xiàn)很多被鎖定的頁面(前文說過了,每個(gè)重疊操作都會(huì)消耗一小部分未分頁內(nèi)存池,同時(shí)還會(huì)鎖定所有涉及的緩沖區(qū))。這個(gè)問題很難回答,沒有一個(gè)確切的答案。最好的方法是把這個(gè)值做成可以調(diào)整的,通過反復(fù)做性能測試,你就可以得出在典型應(yīng)用環(huán)境中最佳的值。
好了,當(dāng)你測算清楚后,下面就是發(fā)送數(shù)據(jù)的問題了,考慮的重點(diǎn)是你希望服務(wù)器同時(shí)處理多少個(gè)并發(fā)的連接。通常情況下,服務(wù)器應(yīng)該限制并發(fā)連接的數(shù)量以及等候處理的發(fā)送調(diào)用。因?yàn)椴l(fā)連接數(shù)量越多,所消耗的未分頁內(nèi)存池也越多;等候處理的發(fā)送調(diào)用越多,被鎖定的內(nèi)存頁面也越多(小心別超過了極限)。這同樣也需要反復(fù)測試才知道答案。
對(duì)于上述環(huán)境,通常不需要關(guān)閉單個(gè)套接字的緩沖區(qū),因?yàn)橹辉贏cceptEx()中有一次接收數(shù)據(jù)的操作,而要保證給每個(gè)到來的連接提供接收緩沖區(qū)并不是太難的事情。但是,如果客戶機(jī)與服務(wù)器交互的方式變一變,客戶機(jī)在發(fā)送了一次數(shù)據(jù)之后,還需要發(fā)送更多的數(shù)據(jù),在這種情況下關(guān)閉接收緩沖就不太妙了,除非你想辦法保證在每個(gè)連接上都發(fā)出了重疊接收調(diào)用來接收更多的數(shù)據(jù)。
結(jié)論
開發(fā)大響應(yīng)規(guī)模的Winsock服務(wù)器并不是很可怕,其實(shí)也就是設(shè)置一個(gè)監(jiān)聽套接字、接受連接請(qǐng)求和進(jìn)行重疊收發(fā)調(diào)用。通過設(shè)置合理的進(jìn)行守候的重疊調(diào)用的數(shù)量,防止出現(xiàn)未分頁內(nèi)存池被耗盡,這才是最主要的挑戰(zhàn)。按照我們前面討論的一些原則,你就可以開發(fā)出大響應(yīng)規(guī)模的服務(wù)器應(yīng)用程序。