長連接和Keepalive
默認的Keepalive超時需要7,200,000 milliseconds,即2小時,探測次數(shù)為5次。它的功效和用戶自己實現(xiàn)的心跳機制是一樣的。開啟Keepalive功能需要消耗額外的寬帶和流量,盡管這微不足道,但在按流量計費的環(huán)境下增加了費用,另一方面,Keepalive設(shè)置不合理時可能會因為短暫的網(wǎng)絡(luò)波動而斷開健康的TCP連接。
keepalive并不是TCP規(guī)范的一部分。在Host Requirements RFC羅列有不使用它的三個理由:(1)在短暫的故障期間,它們可能引起一個良好連接(good connection)被釋放(dropped),(2)它們消費了不必要的寬帶,(3)在以數(shù)據(jù)包計費的互聯(lián)網(wǎng)上它們(額外)花費金錢。然而,在許多的實現(xiàn)中提供了存活定時器。
一些服務(wù)器應(yīng)用程序可能代表客戶端占用資源,它們需要知道客戶端主機是否崩潰。存活定時器可以為這些應(yīng)用程序提供探測服務(wù)。Telnet服務(wù)器和Rlogin服務(wù)器的許多版本都默認提供存活選項。
個人計算機用戶使用TCP/IP協(xié)議通過Telnet登錄一臺主機,這是能夠說明需要使用存活定時器的一個常用例子。如果某個用戶在使用結(jié)束時只是關(guān)掉了電源,而沒有注銷(log off),那么他就留下了一個半打開(half-open)的連接。如果客戶端消失,留給了服務(wù)器端半打開的連接,并且服務(wù)器又在等待客戶端的數(shù)據(jù),那么等待將永遠持續(xù)下去。存活特征的目的就是在服務(wù)器端檢測這種半打開連接。
也可以在客戶端設(shè)置存活器選項,且沒有不允許這樣做的理由,但通常設(shè)置在服務(wù)器。如果連接兩端都需要探測對方是否消失,那么就可以在兩端同時設(shè)置(比如NFS)。
keepalive工作原理:
若在一個給定連接上,兩小時之內(nèi)無任何活動,服務(wù)器便向客戶端發(fā)送一個探測段。(我們將在下面的例子中看到探測段的樣子。)客戶端主機必須是下列四種狀態(tài)之一:
1) 客戶端主機依舊活躍(up)運行,并且從服務(wù)器可到達。從客戶端TCP的正常響應(yīng),服務(wù)器知道對方仍然活躍。服務(wù)器的TCP為接下來的兩小時復(fù)位存活定時器,如果在這兩個小時到期之前,連接上發(fā)生應(yīng)用程序的通信,則定時器重新為往下的兩小時復(fù)位,并且接著交換數(shù)據(jù)。
2) 客戶端已經(jīng)崩潰,或者已經(jīng)關(guān)閉(down),或者正在重啟過程中。在這兩種情況下,它的TCP都不會響應(yīng)。服務(wù)器沒有收到對其發(fā)出探測的響應(yīng),并且在75秒之后超時。服務(wù)器將總共發(fā)送10個這樣的探測,每個探測75秒。如果沒有收到一個響應(yīng),它就認為客戶端主機已經(jīng)關(guān)閉并終止連接。
3) 客戶端曾經(jīng)崩潰,但已經(jīng)重啟。這種情況下,服務(wù)器將會收到對其存活探測的響應(yīng),但該響應(yīng)是一個復(fù)位,從而引起服務(wù)器對連接的終止。
4) 客戶端主機活躍運行,但從服務(wù)器不可到達。這與狀態(tài)2類似,因為TCP無法區(qū)別它們兩個。它所能表明的僅是未收到對其探測的回復(fù)。
服務(wù)器不必擔(dān)心客戶端主機被關(guān)閉然后重啟的情況(這里指的是操作員執(zhí)行的正常關(guān)閉,而不是主機的崩潰)。當系統(tǒng)被操作員關(guān)閉時,所有的應(yīng)用程序進程(也就是客戶端進程)都將被終止,客戶端TCP會在連接上發(fā)送一個FIN。收到這個FIN后,服務(wù)器TCP向服務(wù)器進程報告一個文件結(jié)束,以允許服務(wù)器檢測這種狀態(tài)。
在第一種狀態(tài)下,服務(wù)器應(yīng)用程序不知道存活探測是否發(fā)生。凡事都是由TCP層處理的,存活探測對應(yīng)用程序透明,直到后面2,3,4三種狀態(tài)發(fā)生。在這三種狀態(tài)下,通過服務(wù)器的TCP,返回給服務(wù)器應(yīng)用程序錯誤信息。(通常服務(wù)器向網(wǎng)絡(luò)發(fā)出一個讀請求,等待客戶端的數(shù)據(jù)。如果存活特征返回一個錯誤信息,則將該信息作為讀操作的返回值返回給服務(wù)器。)在狀態(tài)2,錯誤信息類似于“連接超時”。狀態(tài)3則為“連接被對方復(fù)位”。第四種狀態(tài)看起來像連接超時,或者根據(jù)是否收到與該連接相關(guān)的ICMP錯誤信息,而可能返回其它的錯誤信息。
linux內(nèi)核包含對keepalive的支持。其中使用了三個參數(shù):tcp_keepalive_time(開啟keepalive的閑置時 長)tcp_keepalive_intvl(keepalive探測包的發(fā)送間隔)和tcp_keepalive_probes (如果對方不予應(yīng)答,探測包的發(fā)送次數(shù));在liunx中,keepalive是一個開關(guān)選項,可以通過函數(shù)來使能。具體地說,可以使用以下代碼:
setsockopt(rs, SOL_SOCKET, SO_KEEPALIVE, (void *)&keepAlive, sizeof(keepAlive));
當tcp檢測到對端socket不再可用時(不能發(fā)出探測包,或探測包沒有收到ACK的響應(yīng)包),select會返回socket可讀,并且在recv時返回-1,同時置上errno為ETIMEDOUT。此時TCP的狀態(tài)是斷開的。
keepalive參數(shù)設(shè)置代碼如下:
BOOL bKeepAlive = TRUE;
int nRet = ::setsockopt(socket_handle, SOL_SOCKET, SO_KEEPALIVE, (char*)&bKeepAlive, sizeof(bKeepAlive));
if (nRet == SOCKET_ERROR)
{
return FALSE;
}
// 設(shè)置KeepAlive參數(shù)
tcp_keepalive alive_in = {0};
tcp_keepalive alive_out = {0};
alive_in.keepalivetime = 5000; // 開始首次KeepAlive探測前的TCP空閉時間
alive_in.keepaliveinterval = 1000; // 兩次KeepAlive探測間的時間間隔
alive_in.onoff = TRUE;
unsigned long ulBytesReturn = 0;
nRet = WSAIoctl(socket_handle, SIO_KEEPALIVE_VALS, &alive_in, sizeof(alive_in),
&alive_out, sizeof(alive_out), &ulBytesReturn, NULL, NULL);
if (nRet == SOCKET_ERROR)
{
return FALSE;
}
開啟Keepalive選項之后,對于使用IOCP模型的服務(wù)器端程序來說,一旦檢測到連接斷開,GetQueuedCompletionStatus函數(shù)將立即返回FALSE,使得服務(wù)器端能及時清除該連接、釋放該連接相關(guān)的資源。對于使用select模型的客戶端來說,連接斷開被探測到時,以recv目的阻塞在socket上的select方法將立即返回SOCKET_ERROR,從而得知連接已失效,客戶端程序便有機會及時執(zhí)行清除工作、提醒用戶或重新連接。
TCP連接非正常斷開的檢測(KeepAlive探測)
此處的”非正常斷開”指TCP連接不是以優(yōu)雅的方式斷開,如網(wǎng)線故障等物理鏈路的原因,還有突然主機斷電等原因
有兩種方法可以檢測:1.TCP連接雙方定時發(fā)握手消息 2.利用TCP協(xié)議棧中的KeepAlive探測
在windows下使用,要包含MSTcpIP.h的頭文件。點擊下面的鏈接即可下載這個文件
MSTcpIP
備注:長連接雖好,但是比較好用但是占用系統(tǒng)資源比較大。個人建議如無特殊需要,用自己的心跳包機制最好
posted on 2010-02-28 16:04 Benjamin 閱讀(19692) 評論(2) 編輯 收藏 引用 所屬分類: VC