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

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

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

使用簡單的實驗可以很容易證實上面的圖示，以簡單的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問題