上回说到，令狐冲用NP实现的防火墙由于带机数量不足引发大规模网络故障，被岳不群罚去思过崖封闭开发。
为什么NP实现的防火墙会出现这种限制呢？
这要从防火墙与路由器的转发机制区别谈起。
我们在前面的专题中已经讲过，三层交换机和路由器的转发，是基于目的IP的精确匹配，在目的IP匹配失败时，再进行最长匹配。NP芯片具有外接TCAM的能力，可以在O(1)的时间内，在TCAM内查找到基于32bit (IPv4)或128bit (IPv6)的转发表，如这张图：
但是，防火墙与交换机/路由器的查表机制，有着本质的区别。
交换机和路由器工作在网络层，是基于IP地址的，而防火墙却是工作在四层的设备，是基于流的。
什么叫基于流的呢？
举一个栗子。
如图，100.1.1.100通过端口41316，向服务器200.1.1.100的443端口发起访问，打开一个https页面，会在防火墙上会产生一条会话：
100.1.1.100:41316 -> 200.1.1.100:443 @TCP
其中，100.1.1.100:41316是发起方，200.1.1.100:443是响应方。TCP指的是传输层协议。
一条会话(Session)在防火墙的转发平面上会产生两个表项，这是为什么呢？
因为，回程流量的源IP/目的IP/源端口/目的端口，和发起流量的表项是相反的。在防火墙上称为会话的两翼(wing)。
那么，当100.1.1.100又访问服务器200.1.1.100的另一个页面时，会发起另一个TCP会话：
100.1.1.100:41318 -> 200.1.1.100:443 @TCP
防火墙上又增加了两条表项：
显然，对于交换机和路由器而言，网络中的每个IP只会产生一条表项——指向该IP地址的FIB表，而在防火墙上，由于每个IP会产生多个网络连接，表项数量会大大多于路由器。
同时，我们注意到，路由器和交换机基于IP地址查找，查找键值(key)是32bit (IPv4)或128bit (IPv6)。
但在防火墙中，查找表项为基于五元组的：
SIP——32bit/128bit
DIP——32bit/128bit
SPort——16bit
DPort——16bit
Proto——8bit
这样，即使在IPv4环境中，Key也将长达96bit。在IPv6环境中则可达到320bit(考虑到32bit对齐，需要补齐PAD)。这也将成倍增加TCAM的使用量。
因此，在路由器中，NP外扩TCAM可以实现的4M会话表项，在防火墙中大概只能实现不到1M的会话wing数，折合会话数量不超过50万。以每IP发起200个连接计，NP实现的防火墙带机量不超过2500用户，难以满足大中型企业的要求。
那么，如何让防火墙容纳更多的会话呢？
一种思路是，增加TCAM的容量，但带来的是成本也迅速提升。而且，NP外挂TCAM的规格也受到NP芯片的限制。
令狐冲迅速打消了这个念头。
什么便宜容量大呢？
令狐冲想起来了一样东西——
DRAM，俗称内存。
这个家伙价钱便宜，量又足，每GB成本在百元级别，却可以装下百万级别会话表项。需要做出支持上千万级别会话的防火墙，内存器件成本不会超过1000元。
但是，NP并不能从这个家伙里面快速查找表项。
怎么办呢？
欲知令狐冲如何把防火墙表项放进内存条，请看下回分解。
