波仔
📡 第五章 防火墙功能与防范威胁的对策
📄 一句话概括

「支持 100 万会话」这句话，本质是一道内存算术题。 验它要看三个数：多大内存、多长超时、多少新建速率。

📝 本节和前面几节的关系

05.07 讲完了功能，05.08 这三节讲规格书上的三个数字。 三个数字互相牵连，单看任何一个都会被误导。

一、这个数字从哪来

它是「会话表能装多少条」的上限，而表在内存里。 所以第一条账是内存：每条约 150 字节，100 万条就是 150 MB。

但这 150 MB 只是「表本身」，设备还要留给路由表、日志缓冲、特征库、系统本身。 所以一台标称 100 万会话的设备，内存通常不会只有 256 MB。

第二条账是哈希表的装载因子：哈希表装到 75% 就要扩容，否则冲突链变长、查找变慢。 所以「标称 100 万」实际能用的往往只有 75 万。

这两条合起来说明一件事：「会话数」不是一个孤立指标，它是「内存 × 装载因子」的结果。 拿内存除以 150 再乘 0.75，就能估出真实上限。

二、超时时间是隐藏的乘数

会话数是「同时存在」的条数，而每条存在多久由超时决定。 这条关系就是 D141 那个公式：并发 ＝ 新建速率 × 超时时间。

所以同一台设备，超时改一改，能撑的用户数差好几倍： 超时 60 秒能撑 1.2 万条每秒的新建，超时 3600 秒只能撑 200 条每秒。

这解释了一个常见现象： 「设备买回来够用，用了半年不够用了」——往往是有人为了迁就某个业务，把某类会话的超时从 5 分钟改成了 1 小时。 而这一改，会话表就被那一类连接长期占着。

所以运维上有一条纪律：改超时必须有记录、必须按协议分开设。 「全局改成 1 小时」是最常见也最贵的错误。

三、打满时的现象与排查

现象不是「断网」，是「时通时不通」： 表满 → 新连接要挤掉老连接 → 老连接的下一个包被判非法 → 用户重连又能用一会儿。

这种「看起来像网络抖动」的故障最难查，因为 ping 通、部分网站能开、部分不能。

排查顺序应该是： 一、看会话表的当前使用率与历史峰值。 二、看「新建速率」有没有异常升高（扫描、环路、程序疯狂重连）。 三、看「哪一类会话占得最多」——按目的地址或按服务排序。

第三步最关键：因为「会话表打满」几乎从来不是「用户太多」，而是「某一类连接异常增长」。 找到那一类，往往就找到了根因——可能是一台机器中毒在扫描，也可能是一条策略写错导致流量绕圈。

四、动手 Demo：「支持 100 万会话」这句话怎么验

这段按「每条 152 字节」算 100 万会话要多少内存，再算装载因子 0.75 之后实际可用多少， 最后看超时时间怎么影响它。

per = 152
total = per * 1000000
P(u"  每条 %d 字节 × 1,000,000 ＝ %s 字节 ＝ %.0f MB。"
  % (per, format(total, u","), total / 1048576.0))

实跑输出：

--------------------------------------------------------------------
「支持 100 万会话」这句话怎么验
--------------------------------------------------------------------
**会话数是内存与超时时间共同决定的**，**单看一个标称值没有意义。**

**标称 100 万会话，先算它要多少内存**：

  每条 152 字节 × 1,000,000 ＝ 152,000,000 字节 ＝ 145 MB。

**再看「能不能撑到 100 万」要看两件事**：

  ① 表本身要留余量：哈希桶装载因子到 0.75 就要扩容，
     实际可用约 75 万条。
  ② 老化时间不能太长：100 万条 × 300 秒意味着
     每秒要维持 3333 条的新建与回收。

**所以验「会话数」不能只看规格书**，**要看「多大内存 + 多长超时 + 多少新建速率」三个数一起。**

**顺便算「超出会怎样」**：

  新连接要建会话，表满 → 只能丢新连接或挤掉老连接。
  挤掉老连接 → 老连接的下一个包被判成「非法」，直接断。
**所以会话表打满时，现象不是「慢」，是「时通时不通」。**

150 MB 这个数不大，但它是「纯会话表」：设备还要跑路由、写日志、存特征库， 所以真实内存往往是这个数的三到五倍。

注意「装载因子 0.75」那一条：它意味着「标称值」与「可用值」之间有一个固定的折扣， 而这个折扣不会写在规格书里。 所以看规格书时要按七折算，不要按标称算。

最后那段「打满时是时通时不通」是最实用的一条： 它把「设备资源不足」与「网络故障」这两种现象区分开了。 下次遇到「部分网站打不开、ping 正常」，先看会话表使用率。

30 秒实验

  1. 查一台设备的会话表使用率，看它的历史峰值到过多少。
  2. 看它的 TCP 超时设置，有没有按协议分开设。
  3. 算一下：如果全局超时从 5 分钟改成 1 小时，会话数会变几倍？

常见误区

  1. 以为标称值就是可用值。哈希装载因子会打七折。
  2. 以为会话数只由内存决定。超时时间是通过「同时存在」影响它的。
  3. 以为表满会整体变慢。现象是时通时不通，极易误判为网络故障。
自测三问（点开对答案） 1. 估算真实可用会话数的公式是什么？ —— 内存除以每条字节数（约 150），再乘装载因子 0.75。 2. 超时时间怎么影响会话数？ —— 并发 ＝ 新建速率 × 超时时间，超时翻倍会话数就翻倍。 3. 会话表打满时的典型现象是什么？ —— 时通时不通：老连接被挤掉后其后续包被判非法丢弃，重连又恢复。

下一节：第二个数字——NAT 表能装多少条。

相关笔记