增加nf_conntrack_max固然可以緩解這個問題，或者說減小conntrack表項(xiàng)占據(jù)內(nèi)核內(nèi)存的時間也可以緩解之，然而這種補(bǔ)救措施都是治標(biāo)不治本的.

注解：不要過度減小NEW以及TCP的establish的CT狀態(tài)的timeout的原因

盡量不要減小NEW狀態(tài)時間，因?yàn)閷τ谀承毫拥木W(wǎng)絡(luò)，一個數(shù)據(jù)包的來回確實(shí)需要很長時間，對于TCP而言，此時RTT還沒有測量呢。如果NEW狀態(tài)的conntrack保留時間過短，就會導(dǎo)致大量NEW狀態(tài)的連接，而對于很多依賴ctstate的模塊而言，這樣就會有問題，比如iptables的filter表中使用ESTABLISH狀態(tài)來放過前向包的返回包就會有問題，此時ip_conntrack很有可能由于NEW狀態(tài)時間過短而將返回包作為NEW狀態(tài)處理而不是ESTABLISH狀態(tài)，如此一來，返回包就無法通過了。如下圖所示：

使用簡單的實(shí)驗(yàn)可以很容易證實(shí)上面的圖示，以簡單的udp通信為例，編寫一個udp-echo程序，服務(wù)器簡單echo客戶端送達(dá)的字符串：

        for(;;)
    {
     n = recvfrom(sd, msg, MAXLINE, 0, pcliaddr, &len);
          sleep(5);
          sendto(sd, msg, n, 0, pcliaddr, len);
    }
  

然后在客戶端上執(zhí)行echo $sec /proc/sys/net/ipv4/netfilter/ip_conntrack_udp_timeout
其中sec要比服務(wù)器端的sleep參數(shù)更小即可。
如此udp客戶端將收不到服務(wù)器eho回來的字符串，因?yàn)榭蛻舳酥皇欠判袪顟B(tài)為establish的入流量，如果ip_conntrack_udp_timeout配置過于短暫，NEW狀態(tài)的conntrack過早被釋放，這樣將不會有establish狀態(tài)的流量了。對于UDP而言，由于它是不確認(rèn)無連接允許丟包的，因此影響還不是很大，TCP也有類似的問題，那就是如果你連接一個很遠(yuǎn)的且網(wǎng)絡(luò)狀況很惡劣的TCP服務(wù)器，然后你把ip_conntrack_tcp_timeout_synsent設(shè)置很小，這樣就幾乎完不成三次握手了，更進(jìn)一步，如果你把ip_conntrack_tcp_timeout_established設(shè)置過小，那么一旦三次握手建立連接之后，客戶端和服務(wù)器之間很久不發(fā)包，當(dāng)establish狀態(tài)到期后，conntrack被釋放，此時服務(wù)器端主動發(fā)來一個包，該包的conntrack狀態(tài)會是什么呢？因此給予tcp的establish狀態(tài)5天的時間，是可以理解的。需要注意的是，對于tcp而言，由于無法簡單的控制服務(wù)器發(fā)送syn-ack的延時，因此需要在establish狀態(tài)而不是new狀態(tài)做文章了(實(shí)際上，ip_conntrack的establish狀態(tài)映射成了tcp的多個狀態(tài)，包括syn-ack，ack，established)，試試看，效果和udp的一樣。
前面關(guān)于ip_conntrack扯的太遠(yuǎn)了，我們的首要問題是conntrack full的問題。實(shí)際上，如果深入思考這個conntrack full的問題，就會發(fā)現(xiàn)，并不是conntrack容量太小或者表項(xiàng)保留時間過長引發(fā)的full。現(xiàn)實(shí)中的萬事萬物都不是無限的，對于計算機(jī)資源而言，更應(yīng)該節(jié)約使用，不能讓無關(guān)人士浪費(fèi)這種資源，另外既然內(nèi)核默認(rèn)了一個表項(xiàng)的存活時間，那肯定是經(jīng)過測試的經(jīng)驗(yàn)值，自有它的道理。因此本質(zhì)問題在于很多不需要conntrack的包也被conntrack了，這樣就會擠掉很多真正需要conntrack的流量。
那么都是哪些流量需要conntrack呢？常用的就兩個，一個是任何使用ctstate或者state這些match的iptables規(guī)則，另外一個就是所有的iptables的nat表中的規(guī)則，如果我們事先知道哪些流量需要使用iptables的[ct]state來控制，并且也知道哪些流量需要做NAT，那么余下的流量就都是和conntrack無關(guān)的流量了，可以不被ip_conntrack來跟蹤。
幸運(yùn)的是，Linux的Netfilter在PREROUTING以及OUTPUT這兩個HOOK的conntrack之前安插了一個優(yōu)先級更高的table，那就是raw，通過它就可以分離出不需要被conntrack的流量。如果你確定只有某個網(wǎng)卡進(jìn)來的流量才需要做NAT，那么就執(zhí)行下面的規(guī)則：

    iptables -t raw -A PREROUTING ! –I $網(wǎng)卡 -j NOTRACK
iptables –t raw –A OUTPUT –j NOTRACK
  

這樣一來，資源就不會浪費(fèi)在無關(guān)人士身上了，性能也會有所提高，因?yàn)榉彩荖OTRACK的流量，都不會去查詢conntrack的hash表，因?yàn)樵趇p(nf)_conntrack_in的內(nèi)部的開始有一個判斷：

    if ((*pskb)->nfct)
    return NF_ACCEPT;
  

而NOTRACK這個target的實(shí)現(xiàn)也很簡單：

    (*pskb)->nfct = &ip_conntrack_untracked.info[IP_CT_NEW];
  

事實(shí)上將一個占位者設(shè)置給skb的nfct，這樣可以保持其它代碼的一致性。
可見，必要時同時采取三種方式比較有效：1.增大conntrack_max;2.減少狀態(tài)保存時間;3.分離無關(guān)流量。然而除了第三種方式，其余兩種方式在操作時必須給自己十足的理由那么做才行，對于1，比必須明白內(nèi)核內(nèi)存被占有的方式，對于2，看看本文的前半部分。

    iptables -A FORWARD -m state --state UNTRACKED -j ACCEPT
  

最后有個提問：

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

再次深入到ip_conntrack的conntrack full問題