cache老化时间的思考--以nat为例

晨曦之光 发布于 2012/04/10 15:00
阅读 292
收藏 0

局域网越来越大,于是有人提出了vlan,vlan越来越依赖多而快的端口,于是有人做出了三层交换机,实际上三层交换机仅仅对直接下挂的主机性能有较大的提升,对远端的主机效果要么不大,要么根本没有,说白了三层交换机就是在学以太网交换机的样子,本质上就是加了一个cahce功能,使得ip地址直接与端口保持映射,这样就不必再解包,路由,封包了,因此三层交换机是基于流的,并且只要是基于流的都会有老化机制。在cache的作用下,三层交换机轻松实现快速转发,就像二层交换机一样,拥有学习功能,所谓的学习功能其实就是一个cache功能。
     有必要提一下老化机制,该机制丰富了cache,增加了公平性,但是有的时候行为却不是很严格,比如nat实现中,nat在linux中是基于netfilter的conntrack的,conntrack模块会侦测过来的每一个数据包,如果它已经属于一个流,那么就放过,如果不属于任何流,那么就建立一个新的流,将之放入一个哈希,这里就有了两个问题。
     第一个问题是由于tcp和udp的行为有很大的不同,那么连接管理模块有必要将之分开管理,那么就需要在prerouting的时候知道该数据包是tcp的还是udp的,但是我们知道ip会分片的,所以当时到来的数据包可能仅仅是一个ip片段,我们无法从一个片断看得出该片断是udp还是tcp的,除非该片断是第一个,于是conntrack要做的一件事就是重组分片,然后在forward的时候再将之分片。
     第二个问题就是流的老化时间问题,为了使得内核不频繁的对流cache进行修改和替换,每个连接的每个状态都有个老化时间,这些时间根据协议和协议的状态有所不同,比如tcp的ESTABLISHED的状态的流的老化时间就会特别长,而udp的未回答状态的老化时间会特别短,于是问题出来了,如果我配置错了一个nat,那么当我尝试连接的时候肯定是失败的,因为nat将会把目的地址转为一个错误的地址,此时流已经建立了,虽然可能不通,但是路由存在,访问允许,流建立了,并且在确认路由存在访问允许之后查nat表找到了错误的rule,由于对端还没有回答,所以这个状态的流的老化时间很短,虽然时间老化很短,可毕竟建立了,然后我随即将nat配置正确,可是在刚才那个已经建立的流为老化之前,我还是无法连接,这说明一旦流匹配了,在下面经过nat表的时候就会将nat信息复制进这个流,于是后面的数据包一旦命中这个流,将会一直使用这个nat信息,直到该流老化或者被挤出哈希表;另外一个反面的例子是如果nat是配置正确的,那么在改错了的一会时间内还是可以通信的,原因就是流还没有老化,并且新的nat信息没有被刷新。
     另外,nat依赖conntrack的设计本身也许很脆弱,在出现大量连接的情况下,conntrack的哈希表很快就会满,接下来的连接就无法加入哈希表了,于是nat就会失败。脆弱的本质就是nat几乎完全依赖了一个用于效率优先容量有限的哈希表,而不是公平优先绝对精确的容器,我们在受到cache的恩惠的同时也要主要它会引起的问题,正如cpu的cache有cache一致性一样,任何用到cache的地方都要注意这个一致性,除此之外还必须实现公平性。


原文链接:http://blog.csdn.net/dog250/article/details/5561083
加载中
返回顶部
顶部