并发数说明「能装多少」，新建速率说明「能开多快」。 两者受的资源完全不同：前者受内存限，后者受 CPU 与哈希算法限。
前两节讲「装多少」，这一节讲「开多快」。 这是三个指标里最容易被忽略的一个，而它恰恰是「短连接业务」的生死线。
一、两个指标受什么限
并发会话数：受内存限制。表有多大就能装多少。 每秒新建数：受 CPU 与查找算法限制。每建一条都要算哈希、插链表、写超时队列。
指标 受什么限 不够时会怎样
并发会话数 内存 丢新连接 每秒新建数 CPU 与算法 新连接排队或丢
两者不能互相替代：内存再大，CPU 算不过来照样建不了新会话；CPU 再快，表装不下也会丢。 所以规格书里这两个数是分开列的，也必须分开验。
二、为什么新建比转发贵得多
转发一个已有会话的包，只需要「查一次表、命中、放行」，是纯读操作，而且在硬件里完成。
新建一条会话要做五六件事： 算哈希找位置、插入新条目、初始化序号与状态、挂到超时队列、如果要 NAT 还要分配端口、最后写日志。 每一步都是写操作，而且要在多个数据结构之间保持一致。
代价上的差别可以量出来：转发一个包几微秒，新建一条会话几十微秒，差一到两个数量级。 这就是为什么「大量短连接」会把设备打垮，而「大流量长连接」反而很轻松。
哪些业务是「短连接」： 网页浏览（每个对象一个连接）、DNS 查询、监控探针（每秒几十次探测）、以及扫描。 而视频、备份、数据库长连接，都是「少数长连接」。
三、用一条公式把三个数连起来
Little 定律：并发 ＝ 新建速率 × 存活时间。 三个量知道两个，第三个就定了。
它在选型时的用法是反过来的： 先估「用户数 × 每人每秒新建多少条」，得到 λ；再乘「平均存活时间」，得到需要的并发数。
算一个典型办公网：1000 人、每人每分钟开 2 个连接（λ ≈ 33 条每秒）、每连接活 15 秒， 并发只有 500 条。 而同样 1000 人跑扫描，每人每秒 2 条，并发就是 60 万条。
同一个网络、同一批人，差 1200 倍。 所以「我们有一千人」这句话，完全不足以支撑选型——必须说清「他们用的是什么业务」。
四、动手 Demo：新建速率与并发数，用一条公式连起来
这段先用「每分钟 2 个连接、每个活 15 秒」验证 Little 定律， 再按三种业务强度算 1000 个用户各自要多少并发会话。
lam = 2 / 60.0
T_ = 15
P(u" N ＝ %.4f × %d ＝ %.2f 条。" % (lam, T_, lam * T_))
for rate in (0.033, 0.2, 2.0):
lam2 = users * rate
P(u" 每人 %.3f 条／秒 → λ ＝ %6.1f，N ＝ %7s 条。"
% (rate, lam2, format(int(lam2 * 300), u",")))
实跑输出：
--------------------------------------------------------------------
新建速率与并发数，用一条公式连起来
--------------------------------------------------------------------
**并发连接数、新建速率、会话存活时间，三者只有一个自由度。**
**这条关系叫 Little 定律：并发 ＝ 速率 × 时长。**
N ＝ λ × T
N 是同时在线的会话数，λ 是每秒新建数，T 是平均存活秒数。
**验证一下**（典型网页浏览：每 60 秒开 2 个连接，每连接活 15 秒）：
λ ＝ 2 ÷ 60 ＝ 0.0333 条／秒，T ＝ 15 秒。
N ＝ 0.0333 × 15 ＝ 0.50 条。
**也就是说：一个用户平均只占 0.5 条会话。**
**反过来用它算设备规格**（1000 个用户，超时 300 秒）：
每人 0.033 条／秒 → λ ＝ 33.0，N ＝ 9,900 条。
每人 0.200 条／秒 → λ ＝ 200.0，N ＝ 60,000 条。
每人 2.000 条／秒 → λ ＝ 2000.0，N ＝ 600,000 条。
**同一千个用户，从「刷网页」到「跑扫描」，会话数差 60 倍。**
**所以选型时问「多少人」是不够的，得问「什么业务」。**
**再看超时时间的影响**（λ 固定 200 条／秒）：
超时 60 秒 → N ＝ 12,000 条。
超时 300 秒 → N ＝ 60,000 条。
超时 3600 秒 → N ＝ 720,000 条。
**超时从 5 分钟拉到 1 小时，会话表要大 12 倍**——
**这就是为什么设备默认超时都很短，长连接业务要单独放宽。**
「一个用户平均只占 0.5 条会话」这个数有点反直觉， 但它说明「并发数」远小于「用户数」——因为每条连接只活十几秒，而人不是一直在点。
注意「同一千个用户差 60 倍」那一段：它把「选型要看业务」这句话量化了。 所以规格对比时，先问清「跑什么业务」，再谈「多少人」。
最后「超时从 5 分钟拉到 1 小时，会话表要大 12 倍」要记住： 这是运维里最容易犯的错——为了让一个业务不掉线，把全局超时改大，结果整台设备的容量缩水一个数量级。 正确做法是按协议分开设，只放宽需要的那一类。
30 秒实验
- 估算你所在网络每人每分钟新建多少条连接。
- 用 Little 定律算一下你们 100 人规模需要多少并发。
- 想一想：为什么扫描会把新建速率打满，而看视频不会？
常见误区
- 以为并发数够就没问题。新建速率不够，新连接照样排队或丢。
- 以为新建与转发差不多贵。新建要做五六件写操作，贵一到两个数量级。
- 以为「多少人」能决定选型。同一批人的不同业务能差上千倍。
自测三问（点开对答案）
1. 并发会话数与每秒新建数分别受什么限制？ —— 前者受内存限制，后者受 CPU 与哈希查找算法限制。 2. 为什么新建一条会话比转发一个包贵得多？ —— 新建要算哈希、插表、初始化状态、挂超时队列、可能要分配 NAT 端口，全是写操作。 3. Little 定律的三个量是什么关系？ —— 并发 ＝ 新建速率 × 平均存活时间，知道两个就能定第三个。下一节：功能讲完了，最后三节讲「怎么证明这台设备真的做到了」。
- ☐ （本节完，下一节 05.09.01 ISCA）