• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>

            Benjamin

            靜以修身,儉以養(yǎng)德,非澹薄無(wú)以明志,非寧?kù)o無(wú)以致遠(yuǎn)。
            隨筆 - 397, 文章 - 0, 評(píng)論 - 196, 引用 - 0
            數(shù)據(jù)加載中……

            長(zhǎng)連接和Keepalive

            TCP協(xié)議中有長(zhǎng)連接和短連接之分。短連接在數(shù)據(jù)包發(fā)送完成后就會(huì)自己斷開(kāi),長(zhǎng)連接在發(fā)包完畢后,會(huì)在一定的時(shí)間內(nèi)保持連接,即我們通常所說(shuō)的Keepalive(存活定時(shí)器)功能。
            默認(rèn)的Keepalive超時(shí)需要7,200,000 milliseconds,即2小時(shí),探測(cè)次數(shù)為5次。它的功效和用戶(hù)自己實(shí)現(xiàn)的心跳機(jī)制是一樣的。開(kāi)啟Keepalive功能需要消耗額外的寬帶和流量,盡管這微不足道,但在按流量計(jì)費(fèi)的環(huán)境下增加了費(fèi)用,另一方面,Keepalive設(shè)置不合理時(shí)可能會(huì)因?yàn)槎虝旱木W(wǎng)絡(luò)波動(dòng)而斷開(kāi)健康的TCP連接。

            keepalive并不是TCP規(guī)范的一部分。在Host Requirements RFC羅列有不使用它的三個(gè)理由:(1)在短暫的故障期間,它們可能引起一個(gè)良好連接(good connection)被釋放(dropped),(2)它們消費(fèi)了不必要的寬帶,(3)在以數(shù)據(jù)包計(jì)費(fèi)的互聯(lián)網(wǎng)上它們(額外)花費(fèi)金錢(qián)。然而,在許多的實(shí)現(xiàn)中提供了存活定時(shí)器。

            一些服務(wù)器應(yīng)用程序可能代表客戶(hù)端占用資源,它們需要知道客戶(hù)端主機(jī)是否崩潰。存活定時(shí)器可以為這些應(yīng)用程序提供探測(cè)服務(wù)。Telnet服務(wù)器和Rlogin服務(wù)器的許多版本都默認(rèn)提供存活選項(xiàng)。

            個(gè)人計(jì)算機(jī)用戶(hù)使用TCP/IP協(xié)議通過(guò)Telnet登錄一臺(tái)主機(jī),這是能夠說(shuō)明需要使用存活定時(shí)器的一個(gè)常用例子。如果某個(gè)用戶(hù)在使用結(jié)束時(shí)只是關(guān)掉了電源,而沒(méi)有注銷(xiāo)(log off),那么他就留下了一個(gè)半打開(kāi)(half-open)的連接。如果客戶(hù)端消失,留給了服務(wù)器端半打開(kāi)的連接,并且服務(wù)器又在等待客戶(hù)端的數(shù)據(jù),那么等待將永遠(yuǎn)持續(xù)下去。存活特征的目的就是在服務(wù)器端檢測(cè)這種半打開(kāi)連接。

            也可以在客戶(hù)端設(shè)置存活器選項(xiàng),且沒(méi)有不允許這樣做的理由,但通常設(shè)置在服務(wù)器。如果連接兩端都需要探測(cè)對(duì)方是否消失,那么就可以在兩端同時(shí)設(shè)置(比如NFS)。



            keepalive工作原理:

            若在一個(gè)給定連接上,兩小時(shí)之內(nèi)無(wú)任何活動(dòng),服務(wù)器便向客戶(hù)端發(fā)送一個(gè)探測(cè)段。(我們將在下面的例子中看到探測(cè)段的樣子。)客戶(hù)端主機(jī)必須是下列四種狀態(tài)之一:

            1) 客戶(hù)端主機(jī)依舊活躍(up)運(yùn)行,并且從服務(wù)器可到達(dá)。從客戶(hù)端TCP的正常響應(yīng),服務(wù)器知道對(duì)方仍然活躍。服務(wù)器的TCP為接下來(lái)的兩小時(shí)復(fù)位存活定時(shí)器,如果在這兩個(gè)小時(shí)到期之前,連接上發(fā)生應(yīng)用程序的通信,則定時(shí)器重新為往下的兩小時(shí)復(fù)位,并且接著交換數(shù)據(jù)。

            2) 客戶(hù)端已經(jīng)崩潰,或者已經(jīng)關(guān)閉(down),或者正在重啟過(guò)程中。在這兩種情況下,它的TCP都不會(huì)響應(yīng)。服務(wù)器沒(méi)有收到對(duì)其發(fā)出探測(cè)的響應(yīng),并且在75秒之后超時(shí)。服務(wù)器將總共發(fā)送10個(gè)這樣的探測(cè),每個(gè)探測(cè)75秒。如果沒(méi)有收到一個(gè)響應(yīng),它就認(rèn)為客戶(hù)端主機(jī)已經(jīng)關(guān)閉并終止連接。

            3) 客戶(hù)端曾經(jīng)崩潰,但已經(jīng)重啟。這種情況下,服務(wù)器將會(huì)收到對(duì)其存活探測(cè)的響應(yīng),但該響應(yīng)是一個(gè)復(fù)位,從而引起服務(wù)器對(duì)連接的終止。

            4) 客戶(hù)端主機(jī)活躍運(yùn)行,但從服務(wù)器不可到達(dá)。這與狀態(tài)2類(lèi)似,因?yàn)?span lang=EN-US>TCP無(wú)法區(qū)別它們兩個(gè)。它所能表明的僅是未收到對(duì)其探測(cè)的回復(fù)。

             

            服務(wù)器不必?fù)?dān)心客戶(hù)端主機(jī)被關(guān)閉然后重啟的情況(這里指的是操作員執(zhí)行的正常關(guān)閉,而不是主機(jī)的崩潰)。當(dāng)系統(tǒng)被操作員關(guān)閉時(shí),所有的應(yīng)用程序進(jìn)程(也就是客戶(hù)端進(jìn)程)都將被終止,客戶(hù)端TCP會(huì)在連接上發(fā)送一個(gè)FIN。收到這個(gè)FIN后,服務(wù)器TCP向服務(wù)器進(jìn)程報(bào)告一個(gè)文件結(jié)束,以允許服務(wù)器檢測(cè)這種狀態(tài)。

            在第一種狀態(tài)下,服務(wù)器應(yīng)用程序不知道存活探測(cè)是否發(fā)生。凡事都是由TCP層處理的,存活探測(cè)對(duì)應(yīng)用程序透明,直到后面234三種狀態(tài)發(fā)生。在這三種狀態(tài)下,通過(guò)服務(wù)器的TCP,返回給服務(wù)器應(yīng)用程序錯(cuò)誤信息。(通常服務(wù)器向網(wǎng)絡(luò)發(fā)出一個(gè)讀請(qǐng)求,等待客戶(hù)端的數(shù)據(jù)。如果存活特征返回一個(gè)錯(cuò)誤信息,則將該信息作為讀操作的返回值返回給服務(wù)器。)在狀態(tài)2,錯(cuò)誤信息類(lèi)似于“連接超時(shí)”。狀態(tài)3則為“連接被對(duì)方復(fù)位”。第四種狀態(tài)看起來(lái)像連接超時(shí),或者根據(jù)是否收到與該連接相關(guān)的ICMP錯(cuò)誤信息,而可能返回其它的錯(cuò)誤信息。

            linux內(nèi)核包含對(duì)keepalive的支持。其中使用了三個(gè)參數(shù):tcp_keepalive_time(開(kāi)啟keepalive的閑置時(shí) 長(zhǎng))tcp_keepalive_intvlkeepalive探測(cè)包的發(fā)送間隔)和tcp_keepalive_probes (如果對(duì)方不予應(yīng)答,探測(cè)包的發(fā)送次數(shù));在liunx中,keepalive是一個(gè)開(kāi)關(guān)選項(xiàng),可以通過(guò)函數(shù)來(lái)使能。具體地說(shuō),可以使用以下代碼:
            setsockopt(rs, SOL_SOCKET, SO_KEEPALIVE, (void *)&keepAlive, sizeof(keepAlive));

            當(dāng)tcp檢測(cè)到對(duì)端socket不再可用時(shí)(不能發(fā)出探測(cè)包,或探測(cè)包沒(méi)有收到ACK的響應(yīng)包),select會(huì)返回socket可讀,并且在recv時(shí)返回-1,同時(shí)置上errnoETIMEDOUT。此時(shí)TCP的狀態(tài)是斷開(kāi)的。



            keepalive參數(shù)設(shè)置代碼如下:
            // 開(kāi)啟KeepAlive
            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;                // 開(kāi)始首次KeepAlive探測(cè)前的TCP空閉時(shí)間
            alive_in.keepaliveinterval        = 1000;                // 兩次KeepAlive探測(cè)間的時(shí)間間隔
            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;
            }

            開(kāi)啟Keepalive選項(xiàng)之后,對(duì)于使用IOCP模型的服務(wù)器端程序來(lái)說(shuō),一旦檢測(cè)到連接斷開(kāi),GetQueuedCompletionStatus函數(shù)將立即返回FALSE,使得服務(wù)器端能及時(shí)清除該連接、釋放該連接相關(guān)的資源。對(duì)于使用select模型的客戶(hù)端來(lái)說(shuō),連接斷開(kāi)被探測(cè)到時(shí),以recv目的阻塞在socket上的select方法將立即返回SOCKET_ERROR,從而得知連接已失效,客戶(hù)端程序便有機(jī)會(huì)及時(shí)執(zhí)行清除工作、提醒用戶(hù)或重新連接。

            TCP連接非正常斷開(kāi)的檢測(cè)(KeepAlive探測(cè))

            此處的”非正常斷開(kāi)”指TCP連接不是以?xún)?yōu)雅的方式斷開(kāi),如網(wǎng)線(xiàn)故障等物理鏈路的原因,還有突然主機(jī)斷電等原因

            有兩種方法可以檢測(cè):1.TCP連接雙方定時(shí)發(fā)握手消息 2.利用TCP協(xié)議棧中的KeepAlive探測(cè)

            第二種方法簡(jiǎn)單可靠,只需對(duì)TCP連接兩個(gè)Socket設(shè)定KeepAlive探測(cè)。


            在windows下使用,要包含MSTcpIP.h的頭文件。點(diǎn)擊下面的鏈接即可下載這個(gè)文件
              MSTcpIP

            備注:長(zhǎng)連接雖好,但是比較好用但是占用系統(tǒng)資源比較大。個(gè)人建議如無(wú)特殊需要,用自己的心跳包機(jī)制最好

            posted on 2010-02-28 16:04 Benjamin 閱讀(19693) 評(píng)論(2)  編輯 收藏 引用 所屬分類(lèi): VC

            評(píng)論

            # re: 長(zhǎng)連接和Keepalive  回復(fù)  更多評(píng)論   

            你好, 請(qǐng)問(wèn)一下 我現(xiàn)在 通過(guò)web訪(fǎng)問(wèn) apache 然后 apache去交互另外一個(gè)server(可能是腳本).需要登錄驗(yàn)證 然后返回DataInfo.這樣apache接受到信息后 就與另一個(gè)server斷開(kāi)了鏈接。這個(gè)server有時(shí)候會(huì)返回一些必要的信息到apache,但是開(kāi)始交互的TCP協(xié)議交互完就斷開(kāi)了。
            我先用keepalive 綁定 apache與 交互的另一個(gè)server(可能是接口)一直長(zhǎng)連接 來(lái)實(shí)現(xiàn)。
            不知道這個(gè)可以實(shí)現(xiàn)嗎?
            2011-08-26 17:45 | veniced

            # re: 長(zhǎng)連接和Keepalive  回復(fù)  更多評(píng)論   

            @veniced
            可以.
            2012-06-11 10:59 | BYHH
            久久久久亚洲av无码专区| 久久涩综合| 中文字幕精品久久| 国产午夜精品久久久久九九电影| 久久综合香蕉国产蜜臀AV| 国内精品久久久久影院老司| 日本一区精品久久久久影院| 久久国产乱子伦免费精品| 国产精品99久久久精品无码| 97视频久久久| 人妻无码精品久久亚瑟影视| 久久伊人色| 蜜臀久久99精品久久久久久| 久久精品国产一区二区电影| 亚洲国产精品无码久久久不卡 | 欧美激情精品久久久久久久| 久久久99精品成人片中文字幕| 91亚洲国产成人久久精品网址| 香港aa三级久久三级| 国内精品久久久久久久涩爱| 91亚洲国产成人久久精品网址| 国产免费福利体检区久久| 久久久久国产视频电影| 午夜视频久久久久一区| 久久久久久久97| 久久这里只有精品18| 久久最近最新中文字幕大全| 国产三级久久久精品麻豆三级| 99久久99久久精品国产| 久久影视综合亚洲| 久久婷婷五月综合97色直播| 久久棈精品久久久久久噜噜| 久久99国产精品99久久| 国产农村妇女毛片精品久久| 久久婷婷国产剧情内射白浆 | 精品久久久久久亚洲| 99久久精品免费| 久久久久久精品免费看SSS| 成人妇女免费播放久久久| 国内精品久久久久久久coent| 7777精品伊人久久久大香线蕉|