• <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>

            大龍的博客

            常用鏈接

            統計

            最新評論

            TCP/IP協議選項——TCP_KEEPALIVE

            1、KEEPALIVE作用

            KEEPALIVE機制,是TCP協議規定的TCP層(非應用層業務代碼實現的)檢測TCP本端到對方主機的TCP連接的連通性的行為。避免服務器在客戶端出現各種不良狀況時無法感知,而永遠等在這條TCP連接上。

            2、KEEPALIVE代碼示例

            該選項可以設置這個檢測行為的細節,如下代碼所示:

            1. int keepAlive = 1;    // 非0值,開啟keepalive屬性   
            2. int keepIdle = 60;    // 如該連接在60秒內沒有任何數據往來,則進行此TCP層的探測   
            3. int keepInterval = 5; // 探測發包間隔為5秒   
            4. int keepCount = 3;        // 嘗試探測的次數.如果第1次探測包就收到響應了,則后2次的不再發   
            5. setsockopt(sockfd, SOL_SOCKET, SO_KEEPALIVE, (void *)&keepAlive, sizeof(keepAlive));  
            6. setsockopt(sockfd, SOL_TCP, TCP_KEEPIDLE, (void*)&keepIdle, sizeof(keepIdle));  
            7. setsockopt(sockfd, SOL_TCP, TCP_KEEPINTVL, (void *)&keepInterval, sizeof(keepInterval));  
            8. setsockopt(sockfd, SOL_TCP, TCP_KEEPCNT, (void *)&keepCount, sizeof(keepCount));  

            設置該選項后,如果60秒內在此套接口所對應連接的任一方向都沒有數據交換,TCP層就自動給對方發一個保活探測分節(keepalive probe)。這是一個對方必須響應的TCP分節。它會導致以下三種情況:
                對方接收一切正常:以期望的ACK響應。60秒后,TCP將重新開始下一輪探測。
                對方已崩潰且已重新啟動:以RST響應。套接口的待處理錯誤被置為ECONNRESET。
                對方無任何響應:比如客戶端那邊已經斷網,或者客戶端直接死機。以設定的時間間隔嘗試3次,無響應就放棄。套接口的待處理錯誤被置為ETIMEOUT。

            3、KEEPALIVE腳本設置

            全局設置可更改/etc/sysctl.conf,加上:
            net.ipv4.tcp_keepalive_intvl = 5
            net.ipv4.tcp_keepalive_probes = 3
            net.ipv4.tcp_keepalive_time = 60
            在程序中表現為:
            阻塞模型下,當TCP層檢測到對端socket不再可用時,內核無法主動通知應用層出錯,只有應用層主動調用read()或者write()這樣的IO系統調用時,內核才會利用出錯來通知應用層。
            非阻塞模型下,select或者epoll會返回sockfd可讀,應用層對其進行讀取時,read()會報錯。


            一點經驗:
            實際上我們在做服務器程序的時候,對客戶端的保活探測基本上不依賴于這個TCP層的keepalive探測機制。
            而是我們自己做一套應用層的請求應答消息,在應用層實現這樣一個功能。

            posted on 2014-08-18 17:41 大龍 閱讀(1319) 評論(0)  編輯 收藏 引用

            精品久久久久国产免费| 久久久久亚洲精品男人的天堂| 人妻丰满?V无码久久不卡| 无码任你躁久久久久久老妇| 中文精品久久久久人妻不卡| 99久久精品费精品国产| 久久国语露脸国产精品电影| 色综合合久久天天综合绕视看| 理论片午午伦夜理片久久 | 人妻无码中文久久久久专区| 91精品国产9l久久久久| 久久综合色老色| 91精品国产高清久久久久久国产嫩草| 欧美亚洲日本久久精品| 久久超乳爆乳中文字幕| 中文成人无码精品久久久不卡| 国产无套内射久久久国产| 中文字幕无码免费久久| 色播久久人人爽人人爽人人片aV| 久久久精品人妻一区二区三区蜜桃| 久久久久久亚洲精品不卡| 久久国产精品国产自线拍免费 | 久久天堂AV综合合色蜜桃网| 香蕉aa三级久久毛片| 国产成人综合久久精品尤物| 99久久人妻无码精品系列蜜桃| 久久久无码精品亚洲日韩京东传媒 | 欧美麻豆久久久久久中文| 蜜桃麻豆www久久| 久久免费视频观看| 亚洲综合久久综合激情久久| 久久99国产精品久久久| 久久精品国产亚洲一区二区| 欧美亚洲国产精品久久蜜芽| 国产人久久人人人人爽| 国产精品一区二区久久| 99久久国产热无码精品免费| 久久久久久综合一区中文字幕| 久久精品国产99国产电影网| 品成人欧美大片久久国产欧美... 品成人欧美大片久久国产欧美 | 久久久WWW成人免费毛片|