两种防火墙，两种命运——Session Table
我的处理经验
如果你正在处理Session Table，先别急着照搬网上的参数。如果你曾经配置过家用路由器或者公司网络设备，大概率见过“状态检测防火墙”和“包过滤防火墙”这两个选项。它们听起来很像，但内部处理数据包的逻辑天差地别。这种差异直接影响你的网速、延迟，以及设备在高并发下会不会崩。更关键的是，这一切都和一张叫做 Session Table（会话表） 的数据结构有关。
延伸阅读：此处可内链到“Session Table配置案例”相关文章。
包过滤防火墙：不记事的门卫
先看关键判断
包过滤防火墙是最早出现的防火墙类型。它的工作方式特别简单：每个数据包都是独立的，没有任何上下文。防火墙只看这个包本身的头部信息——源 IP、目的 IP、源端口、目的端口、协议类型（比如 TCP 还是 UDP），然后跟预设的规则列表做匹配。规则允许就放行，不允许就丢弃。
想象一个门卫，他手里有一张纸，上面写着“允许穿红色衣服的人进门”。每个要进门的人，他都只看衣服颜色，符合就放行。他不会记住刚才进去了谁，也不会关心这个人进去之后做了什么。这就是包过滤防火墙。
因为不保存任何连接状态，包过滤防火墙不需要维护 Session Table。它的性能瓶颈主要在于规则匹配的速度。规则越多，每个包需要对比的次数就越多。但换一个角度看，没有会话表意味着内存占用极低，CPU 只需要做简单的包头部解析和规则匹配。因此，在纯转发速度上，包过滤防火墙往往非常快，尤其是在规则数量有限时。
想继续深入：此处可内链到“Session Table优化清单”文章。
进阶阅读：此处可内链到“Session Table性能优化”指南。
状态检测防火墙：带记事本的门卫
容易忽略的细节
状态检测防火墙（也叫动态包过滤防火墙）就聪明多了。它不仅仅检查单个数据包，还会记录整个连接的状态。当一个连接建立时，防火墙会创建一条会话记录，存进 Session Table。这张表里记录了连接的源 IP、目的 IP、端口对、协议、连接状态（比如 TCP 的 SYN_SENT、ESTABLISHED、FIN_WAIT 等）以及超时时间。后续属于同一个连接的数据包到达时，防火墙直接查表，只要匹配会话条目就放行，不再重复匹配规则。
用门卫打比方：状态检测防火墙会记住每个进门的人，甚至知道这个人进去是取快递还是送外卖。第二次见到这个人，门卫直接挥手放行，不用再拿出规则纸来看。而且，如果一个人只出不去（比如只发送了 SYN 却没有收到 SYN-ACK），门卫会怀疑不对劲，可能在超时后自动清除这条记录。
这种设计带来了巨大的好处：大大减少了规则匹配的次数。对于一次典型的 TCP 连接，只有第一个 SYN 包需要走一遍规则列表，后续几千个数据包都直接查表放行。这显著提升了规则复杂场景下的转发效率。
相关阅读：此处可内链到“Session Table常见问题”专题。
Session Table 维持带来的性能代价
我的处理经验
但世间没有免费的午餐。状态检测防火墙虽然节省了规则匹配的时间，却额外引入了 Session Table 的维持开销。这些开销主要体现在三方面：
- 内存消耗：每个并发连接都需要在 Session Table 中占一条记录。一条典型的 IPv4 TCP 会话记录大约占用 256~512 字节。当并发连接数达到几十万甚至上百万时，内存占用变得非常可观。低端路由器往往只有几十 MB 内存，一旦 Session Table 满了，新的连接就无法建立，导致丢包甚至断网。
- 表项创建与老化：连接建立时需要创建表项，连接关闭或超时后需要删除。这些操作涉及哈希查找、链表操作、定时器管理。连接建立速率越高（比如每秒几万个新连接），CPU 的负担就越重。如果防火墙的处理能力跟不上，就会出现 SYN 洪水或连接建立失败。
- 状态跟踪的复杂性：对于 TCP，状态检测防火墙需要跟踪连接状态机的转换（SYN → SYN-ACK → ACK → 数据 → FIN 等）。对于 UDP，由于无连接，防火墙只能靠超时和“伪状态”来近似跟踪。这些额外的状态判断消耗 CPU 周期。
相比之下，包过滤防火墙完全不需要这些开销。它的每个数据包都是等价的，处理器只需要做一遍匹配，不做任何状态记录。因此，在极端场景下（比如 DDoS 攻击时大量伪造的连接请求），包过滤防火墙的 CPU 占用可能保持平稳，而状态检测防火墙可能会因为不断创建新会话表项而被拖垮。
什么时候选包过滤，什么时候选状态检测？
先看关键判断
包过滤防火墙的简单性使它非常适合透明模式或者极简规则场景。例如，家用路由器的基本 ACL（访问控制列表）很多时候就是包过滤。如果你只需要阻止某个 IP 或端口，包过滤足够，而且延迟最低。另外，在流量极大、并发连接数极高的骨干网络设备上，包过滤可以靠专用硬件实现极速转发。
状态检测防火墙更适合需要精细化安全策略的环境。比如企业内网需要只允许从内部发起的连接访问外部，拒绝外部主动连接内部。状态检测可以轻松做到：因为出站连接会在表里留下记录，返回包自动匹配，而入站的 SYN 包如果没有对应的出站记录则被丢弃。这是包过滤难以实现的——包过滤必须手动配置允许回包的高位端口规则，反而增加了攻击面。
现代防火墙通常采用混合架构：用硬件或快速路径处理无状态的转发，降级到软件路径做状态检测；或者引入会话表硬件加速（例如 TCAM 或 SRAM）。对普通用户而言，理解 Session Table 的性能含义有助于在购买路由器或云防火墙时做出正确选择：如果你有大量长连接（如大文件传输或流媒体），状态检测优势明显；如果你的业务是大量短连接（如高并发 API 请求），那么 Session Table 的创建速率可能成为瓶颈。
一眼看清差异
我的处理经验
为了更直观，这里把两个维度对比一下：
- 内存占用：包过滤 ≈ 规则表大小（固定）；状态检测 = 规则表 + Session Table（随并发连接数线性增长）。
- CPU 负担：包过滤 ≈ 每个包都要查规则（规则数量是关键）；状态检测 ≈ 首包查规则 + 后续包查表（会话建立速率是关键）。
- 抗攻击能力：包过滤对 SYN Flood 等攻击的抵抗力更强，因为不会花费资源创建会话记录；状态检测容易被大量假连接耗尽 Session Table。
- 应用层意识：包过滤无法理解协议状态，只能靠端口；状态检测可以识别连接阶段，实现更精准的 ACL。
- 典型适用场景：包过滤用于路由器 ACL、简单黑白名单；状态检测用于企业边界防火墙、NAT 网关。
补充参考：此处可内链到“Session Table故障排查实例”。
总结：没有绝对好坏，只有是否匹配场景
配置前的检查
包过滤防火墙上手快、资源省，但安全能力单一；状态检测防火墙聪明、策略灵活，但需要为 Session Table 买单。当你下次看到防火墙参数中写着“并发连接数”或“新建连接速率”时，这些数字反映的就是 Session Table 维持能力的上限。家庭上网不太可能超过几千条会话，选哪种都够用；但如果你在运维几百台服务器的后端，或者搭建高并发业务，那么防火墙的 Session Table 性能可以直接影响用户的丢包率和响应时间。
最后提醒一句：不要只看“状态检测”就认为它一定更好。在某些场景下，简单的包过滤配合应用层代理（比如反向代理或 API 网关）反而是更轻量、更可靠的安全方案。理解 Session Table 背后的权衡，你就能做出更适合自己的选择。
延伸阅读