ip conntrack還應該做更多

2021-08-26 10:35:57 字數 1371 閱讀 1014

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 誕生以來,快取就廣泛地存在於網際網路應用中。如果你的應用流量很小,那麼使用快取可能並不需要做多餘的考慮。但如果你的應用流量達到了成百上千萬,那麼你就不得不考慮深層次的快取問題 快取穿透 快取擊穿與快取雪崩。快取穿透 快取穿透是指查詢乙個一定不存在的資料,因為這個...