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

            大龍的博客

            常用鏈接

            統(tǒng)計

            最新評論

            tcp_tw_recycle和tcp_timestamps導(dǎo)致connect失敗問題 --- 轉(zhuǎn)

             
               近來線上陸續(xù)出現(xiàn)了一些connect失敗的問題,經(jīng)過分析試驗,最終確認和proc參數(shù)tcp_tw_recycle/tcp_timestamps相關(guān);
            1. 現(xiàn)象
                第一個現(xiàn)象:模塊A通過NAT網(wǎng)關(guān)訪問服務(wù)S成功,而模塊B通過NAT網(wǎng)關(guān)訪問服務(wù)S經(jīng)常性出現(xiàn)connect失敗,抓包發(fā)現(xiàn):服務(wù)S端已經(jīng)收到了syn包,但沒有回復(fù)synack;另外,模塊A關(guān)閉了tcp timestamp,而模塊B開啟了tcp timestamp;
                第二個現(xiàn)象:不同主機上的模塊C(開啟timestamp),通過NAT網(wǎng)關(guān)(1個出口ip)訪問同一服務(wù)S,主機C1 connect成功,而主機C2 connect失敗;

            2. 分析
                根據(jù)現(xiàn)象上述問題明顯和tcp timestmap有關(guān);查看linux 2.6.32內(nèi)核源碼,發(fā)現(xiàn)tcp_tw_recycle/tcp_timestamps都開啟的條件下,60s內(nèi)同一源ip主機的socket connect請求中的timestamp必須是遞增的。
                源碼函數(shù):tcp_v4_conn_request(),該函數(shù)是tcp層三次握手syn包的處理函數(shù)(服務(wù)端);
                源碼片段
                   if (tmp_opt.saw_tstamp &&
                        tcp_death_row.sysctl_tw_recycle &&
                        (dst = inet_csk_route_req(sk, req)) != NULL &&
                        (peer = rt_get_peer((struct rtable *)dst)) != NULL &&
                        peer->v4daddr == saddr) {
                        if (get_seconds() < peer->tcp_ts_stamp + TCP_PAWS_MSL &&
                            (s32)(peer->tcp_ts - req->ts_recent) >
                                        TCP_PAWS_WINDOW) {
                            NET_INC_STATS_BH(sock_net(sk), LINUX_MIB_PAWSPASSIVEREJECTED);
                            goto drop_and_release;
                        }
                    }
                    tmp_opt.saw_tstamp:該socket支持tcp_timestamp
                    sysctl_tw_recycle:本機系統(tǒng)開啟tcp_tw_recycle選項
                    TCP_PAWS_MSL:60s,該條件判斷表示該源ip的上次tcp通訊發(fā)生在60s內(nèi)
                    TCP_PAWS_WINDOW:1,該條件判斷表示該源ip的上次tcp通訊的timestamp 大于 本次tcp


                分析:主機client1和 client2通過NAT網(wǎng)關(guān)(1個ip地址)訪問serverN,由于timestamp時間為系統(tǒng)啟動到當前的時間,因此,client1和 client2的timestamp不相同;根據(jù)上述syn包處理源碼,在tcp_tw_recycle和tcp_timestamps同時開啟的條件 下,timestamp大的主機訪問serverN成功,而timestmap小的主機訪問失敗;

                參數(shù):/proc/sys/net/ipv4/tcp_timestamps - 控制timestamp選項開啟/關(guān)閉
                      /proc/sys/net/ipv4/tcp_tw_recycle - 減少timewait socket釋放的超時時間

            3. 解決方法
                echo 0 > /proc/sys/net/ipv4/tcp_tw_recycle;
                tcp_tw_recycle默認是關(guān)閉的,有不少服務(wù)器,為了提高性能,開啟了該選項;
                為了解決上述問題,個人建議關(guān)閉tcp_tw_recycle選項,而不是timestamp;因為 在tcp timestamp關(guān)閉的條件下,開啟tcp_tw_recycle是不起作用的;而tcp timestamp可以獨立開啟并起作用。
                源碼函數(shù):  tcp_time_wait()
                源碼片段:
                    if (tcp_death_row.sysctl_tw_recycle && tp->rx_opt.ts_recent_stamp)
                        recycle_ok = icsk->icsk_af_ops->remember_stamp(sk);
                    ......
                   
                    if (timeo < rto)
                        timeo = rto;

                    if (recycle_ok) {
                        tw->tw_timeout = rto;
                    } else {
                        tw->tw_timeout = TCP_TIMEWAIT_LEN;
                        if (state == TCP_TIME_WAIT)
                            timeo = TCP_TIMEWAIT_LEN;
                    }

                    inet_twsk_schedule(tw, &tcp_death_row, timeo,
                               TCP_TIMEWAIT_LEN);

                timestamp和tw_recycle同時開啟的條件下,timewait狀態(tài)socket釋放的超時時間和rto相關(guān);否則,超時時間為TCP_TIMEWAIT_LEN,即60s;

                內(nèi)核說明文檔 對該參數(shù)的介紹如下
                tcp_tw_recycle - BOOLEAN
                Enable fast recycling TIME-WAIT sockets. Default value is 0.
                It should not be changed without advice/request of technical
                experts.

            posted on 2013-02-17 18:58 大龍 閱讀(364) 評論(0)  編輯 收藏 引用


            只有注冊用戶登錄后才能發(fā)表評論。
            網(wǎng)站導(dǎo)航: 博客園   IT新聞   BlogJava   博問   Chat2DB   管理


            久久久久久久亚洲精品| 久久天天躁狠狠躁夜夜不卡| 亚洲av成人无码久久精品 | 久久精品黄AA片一区二区三区| 国内精品久久久久久野外| 久久99精品久久久久久不卡| 777午夜精品久久av蜜臀| 亚洲国产二区三区久久| 久久精品亚洲AV久久久无码| 日本精品久久久中文字幕 | 亚洲国产成人久久笫一页| 久久精品国产亚洲欧美| 亚洲综合精品香蕉久久网| 久久久精品波多野结衣| 国产精品久久久久久久久| 97久久国产综合精品女不卡| 久久精品成人免费观看97| 久久久91精品国产一区二区三区 | 亚洲中文字幕久久精品无码APP| 精品久久一区二区三区| 97精品国产97久久久久久免费 | 色婷婷久久综合中文久久蜜桃av| 精品免费久久久久国产一区| 91精品国产乱码久久久久久| 久久久无码精品亚洲日韩蜜臀浪潮| 国产精品欧美久久久久无广告| 亚洲国产精品无码久久久蜜芽 | 亚洲精品综合久久| 无码人妻久久一区二区三区蜜桃| 久久亚洲国产午夜精品理论片| 久久综合精品国产二区无码| 亚洲国产精品久久久天堂| 久久人人添人人爽添人人片牛牛 | 伊人久久无码精品中文字幕| 精品一久久香蕉国产线看播放| 色噜噜狠狠先锋影音久久| 日韩亚洲欧美久久久www综合网 | 18禁黄久久久AAA片| 亚洲七七久久精品中文国产| 综合久久一区二区三区 | 久久亚洲精品中文字幕|