ip_conntrack將無狀態的在高層有聯絡的單個ip資料報用狀態聯絡了起來，實際上是在更底層破壞了分組交換網的單分組**的原則。
ip_conntrack基於五元組來追蹤乙個流，在流的開頭或者涉及到狀態切換的時候設定一些狀態和cache，屬於同一流的後續分組就可以共享這些狀態和cache，這些狀態和cache用於更高層的邏輯判斷，比如nat，或者netfilter的state這些match。
在純**網路中或者是acl比較簡單的網路節點上，我們希望ip_conntrack可以儲存下面的一些資訊：
1.五元組標識的資料流。這個在標準核心中已經實現，nat模組使用的正是這個資訊。
2.高層filter的結果資訊，如果乙個流的第乙個包被高層drop了，那麼希望ip_conntrack儲存這個結果資訊，後續的包在prerouting這個hook點直接drop，而不必繼續往上層走了。這個在標準的核心中還沒有實現，可能是因為要涉及高層過濾規則和底層的ip_conntrack儲存的資訊之間的同步，比如乙個udp流，開始由於某種事件被drop了，不久的後來又被accept了。處理這種同步非常複雜，特別是在核心中這麼做。
3.ip層的路由結果資訊。由於ip資料報的單包被路由的，如果多個ip資料報被看作了乙個流，那麼流的第乙個資料報的路由結果就可以被ip_conntrack儲存下來，後來的資料報直接根據該儲存的結果直接**，而不必再經過標準的ip路由或者ip路由快取。這個在標準的linux核心中也沒有實現，原因也是資訊同步問題，特別是涉及動態路由協議並且收斂慢的時候。
但是，如果你確定的知道資訊同步問題不會發生，比如配置靜態的filter，配置靜態的路由，那麼上述的2和3還是有必要實現的，幸運的是，這種實現很容易，以路由快取為例，基於2.6.32版本的核心，只需要在struct nf_conn中新增乙個指標dst_entry，儲存乙個流的第乙個包的路由結果資訊，這個資訊應該是第乙個包的postrouting或者output這個hook點上被新增進nf_conn結構體，然後在prerouting中被檢查，如果檢查存在這個dst_entry，則直接**，呼叫dst_output，這裡沒有和filter聯動，簡單點說，不考慮filter，並且配置靜態路由，路由不會改變的情況下，這種方式十分可行，為什麼呢？因為本來ip_conntrack的載入就使得tcp/ip協議棧核心路徑多了一次流匹配，到了ip層還要進行route查詢或者cache查詢，為何不在僅有的一次查詢中完成所有這些呢，當然前提是一切都是靜態的情況下。其實加入這個patch並不會帶來效能的多大提公升，但是它能使得ip_conntrack對效能的危害減輕一些。
最後說一下可惡的nat，nat實則破壞了網際網路的原則，它使網際網路不再互聯。這就不由想起一些專家們的話，internet在設計從來就是先天不足的，現在的internet已經貼滿了補丁，沒有地方再貼了，可是反對意見有的是，internet的發展完全是一幅油畫的創作過程，草稿和定版都位於同一張紙上！
ip conntrack還應該做更多
ip conntrack將無狀態的在高層有聯絡的單個ip資料報用狀態聯絡了起來，實際上是在更底層破壞了分組交換網的單分組 的原則。ip conntrack基於五元組來追蹤乙個流，在流的開頭或者涉及到狀態切換的時候設定一些狀態和cache，屬於同一流的後續分組就可以共享這些狀態和cache，這些狀態和...
程式設計師還應該掌握哪些技能
最近公司在討論如何通過培訓來提高開發人員技能，我覺得除了程式設計工具的熟悉運用，以及對演算法和系統的掌握外，下列的一些技能也是現代開發人員應該要提公升的技能 1.設計模式 熟悉常用的設計模式，並了解你所用的軟體包中提供了哪些設計模式。2.物件導向的程式設計 熟悉物件導向的程式設計思想，掌握物件導向的...
面對海量請求，快取設計還應該考慮哪些問題？
從第乙個快取框架 memcached 誕生以來，快取就廣泛地存在於網際網路應用中。如果你的應用流量很小，那麼使用快取可能並不需要做多餘的考慮。但如果你的應用流量達到了成百上千萬，那麼你就不得不考慮深層次的快取問題 快取穿透 快取擊穿與快取雪崩。快取穿透 快取穿透是指查詢乙個一定不存在的資料，因為這個...