亚洲免费在线-亚洲免费在线播放-亚洲免费在线观看-亚洲免费在线观看视频-亚洲免费在线看-亚洲免费在线视频

再次深入到ip_conntrack的conntrack full問題

系統 1963 0
增加nf_conntrack_max固然可以緩解這個問題,或者說減小conntrack表項占據內核內存的時間也可以緩解之,然而這種補救措施都是治標不治本的.

注解:不要過度減小NEW以及TCP的establish的CT狀態的timeout的原因

盡量不要減小NEW狀態時間,因為對于某些惡劣的網絡,一個數據包的來回確實需要很長時間,對于TCP而言,此時RTT還沒有測量呢。如果NEW狀態的conntrack保留時間過短,就會導致大量NEW狀態的連接,而對于很多依賴ctstate的模塊而言,這樣就會有問題,比如iptables的filter表中使用ESTABLISH狀態來放過前向包的返回包就會有問題,此時ip_conntrack很有可能由于NEW狀態時間過短而將返回包作為NEW狀態處理而不是ESTABLISH狀態,如此一來,返回包就無法通過了。如下圖所示:

再次深入到ip_conntrack的conntrack full問題

使用簡單的實驗可以很容易證實上面的圖示,以簡單的udp通信為例,編寫一個udp-echo程序,服務器簡單echo客戶端送達的字符串:
        for(;;)
    {
     n = recvfrom(sd, msg, MAXLINE, 0, pcliaddr, &len);
          sleep(5);
          sendto(sd, msg, n, 0, pcliaddr, len);
    }
  

然后在客戶端上執行echo $sec /proc/sys/net/ipv4/netfilter/ip_conntrack_udp_timeout
其中sec要比服務器端的sleep參數更小即可。
如此udp客戶端將收不到服務器eho回來的字符串,因為客戶端只是放行狀態為establish的入流量,如果ip_conntrack_udp_timeout配置過于短暫,NEW狀態的conntrack過早被釋放,這樣將不會有establish狀態的流量了。對于UDP而言,由于它是不確認無連接允許丟包的,因此影響還不是很大,TCP也有類似的問題,那就是如果你連接一個很遠的且網絡狀況很惡劣的TCP服務器,然后你把ip_conntrack_tcp_timeout_synsent設置很小,這樣就幾乎完不成三次握手了,更進一步,如果你把ip_conntrack_tcp_timeout_established設置過小,那么一旦三次握手建立連接之后,客戶端和服務器之間很久不發包,當establish狀態到期后,conntrack被釋放,此時服務器端主動發來一個包,該包的conntrack狀態會是什么呢?因此給予tcp的establish狀態5天的時間,是可以理解的。需要注意的是,對于tcp而言,由于無法簡單的控制服務器發送syn-ack的延時,因此需要在establish狀態而不是new狀態做文章了(實際上,ip_conntrack的establish狀態映射成了tcp的多個狀態,包括syn-ack,ack,established),試試看,效果和udp的一樣。
前面關于ip_conntrack扯的太遠了,我們的首要問題是conntrack full的問題。實際上,如果深入思考這個conntrack full的問題,就會發現,并不是conntrack容量太小或者表項保留時間過長引發的full。現實中的萬事萬物都不是無限的,對于計算機資源而言,更應該節約使用,不能讓無關人士浪費這種資源,另外既然內核默認了一個表項的存活時間,那肯定是經過測試的經驗值,自有它的道理。因此本質問題在于很多不需要conntrack的包也被conntrack了,這樣就會擠掉很多真正需要conntrack的流量。
那么都是哪些流量需要conntrack呢?常用的就兩個,一個是任何使用ctstate或者state這些match的iptables規則,另外一個就是所有的iptables的nat表中的規則,如果我們事先知道哪些流量需要使用iptables的[ct]state來控制,并且也知道哪些流量需要做NAT,那么余下的流量就都是和conntrack無關的流量了,可以不被ip_conntrack來跟蹤。
幸運的是,Linux的Netfilter在PREROUTING以及OUTPUT這兩個HOOK的conntrack之前安插了一個優先級更高的table,那就是raw,通過它就可以分離出不需要被conntrack的流量。如果你確定只有某個網卡進來的流量才需要做NAT,那么就執行下面的規則:
    iptables -t raw -A PREROUTING ! –I $網卡 -j NOTRACK
iptables –t raw –A OUTPUT –j NOTRACK
  
這樣一來,資源就不會浪費在無關人士身上了,性能也會有所提高,因為凡是NOTRACK的流量,都不會去查詢conntrack的hash表,因為在ip(nf)_conntrack_in的內部的開始有一個判斷:
    if ((*pskb)->nfct)
    return NF_ACCEPT;
  
而NOTRACK這個target的實現也很簡單:
    (*pskb)->nfct = &ip_conntrack_untracked.info[IP_CT_NEW];
  
事實上將一個占位者設置給skb的nfct,這樣可以保持其它代碼的一致性。
可見,必要時同時采取三種方式比較有效:1.增大conntrack_max;2.減少狀態保存時間;3.分離無關流量。然而除了第三種方式,其余兩種方式在操作時必須給自己十足的理由那么做才行,對于1,比必須明白內核內存被占有的方式,對于2,看看本文的前半部分。
    iptables -A FORWARD -m state --state UNTRACKED -j ACCEPT
  

最后有個提問:

對于沒有keepalive的TCP連接而言,試想服務器和客戶端在establish狀態之后5天內都沒有互相通信,5天后的一天,服務器主動發送了一個數據包給客戶端,然而此時防火墻/NAT設備上的conntrack狀態已經過期被刪除,此時該數據包將會被認為是NEW狀態的數據包,被DROP,客戶端永遠收不到這個數據包,進而也不會發送ACK,服務器端不斷重發,不斷被防火墻DROP,當重發次數達到一定次數后,服務器RESET該連接,然而客戶端如何得知,只有客戶端主動發包才能打破這個僵局,然而誰能保證客戶端一定會主動發包?這是不是Linux的ip_conntrack的一種缺陷,設計5天時間的establish狀態是不是一種極限措施,然而誰又能保證5天內兩端不斷通信呢?

再次深入到ip_conntrack的conntrack full問題


更多文章、技術交流、商務合作、聯系博主

微信掃碼或搜索:z360901061

微信掃一掃加我為好友

QQ號聯系: 360901061

您的支持是博主寫作最大的動力,如果您喜歡我的文章,感覺我的文章對您有幫助,請用微信掃描下面二維碼支持博主2元、5元、10元、20元等您想捐的金額吧,狠狠點擊下面給點支持吧,站長非常感激您!手機微信長按不能支付解決辦法:請將微信支付二維碼保存到相冊,切換到微信,然后點擊微信右上角掃一掃功能,選擇支付二維碼完成支付。

【本文對您有幫助就好】

您的支持是博主寫作最大的動力,如果您喜歡我的文章,感覺我的文章對您有幫助,請用微信掃描上面二維碼支持博主2元、5元、10元、自定義金額等您想捐的金額吧,站長會非常 感謝您的哦!!!

發表我的評論
最新評論 總共0條評論
主站蜘蛛池模板: a一级毛片免费高清在线 | 精品偷拍模特露出丝袜在线 | 精品看片 | 黄色影院免费 | 手机看片福利日韩国产 | 亚洲精品丝袜在线一区波多野结衣 | 日韩免费高清 | 国产亚洲情侣久久精品 | 久草热久草视频 | 午夜精品久久久久久久久 | 爱爱一区 | 色网站在线播放 | 成人网18免费网站 | 夜色精品国产一区二区 | 不卡在线观看 | 日日干天天草 | 香蕉一区二区 | 伊人久色 | 久青草视频 | 日韩中文精品亚洲第三区 | 国产精品麻豆高清在线观看 | 日日添日日摸 | 日韩中文字幕在线有码视频网 | 中文字幕亚洲综合久久菠萝蜜 | 国产成人精品精品欧美 | 亚洲视频在线一区二区 | 免费一级欧美大片在线观看 | 国产精品自在线拍 | 精品99re66| 日韩欧美亚洲综合 | 青青青国产观看免费视频 | 日本高清一级做a爱过程免费视频 | 4htv影院永久免费在线地址 | 久99热| 色久综合在线 | 久久艹在线 | 国产亚洲欧美日韩在线看片 | 日韩高清中文字幕 | 老司机免费福利视频无毒午夜 | 久久97久久 | 免费黄色一级网站 |