做网络和运维这些年被问得最多的往往不是“策略怎么写”而是“防火墙到底该买多大的”。每次看采购清单那一串参数里真正决定选型的通常只有两个数字并发连接数、吞吐量。一个回答“防火墙能同时管住多少条业务连接”一个回答“这些连接上的数据它跑不跑得动”。但麻烦的地方在于每个厂商标参数的规则不一样同一个数字在不同场景下的含金量也完全不同。这篇文章我把这两个指标从原理到落地拆开讲包括我自己做选型、验收和排障时的一些实测方法和经验给正在做防火墙选型、或者已经被“连接数爆了”这类问题折磨过的同行做个参考。1. 并发连接数先搞懂它到底在统计什么1.1 从连接生命周期看会话表任何一台状态检测防火墙内部都维护着一张会话表。表里每一条记录对应的是网络通信中的五元组源IP、源端口、目的IP、目的端口、协议。为什么防火墙需要这张表因为它要判断哪些数据包是“内部主动发起连接的回应”哪些是“外部主动摸进来的非法流量”。TCP握手时的SYN、SYN-ACK、ACK传输中的数据包断开时的FIN包每一步都会让防火墙去更新对应会话表项的状态。“并发连接数”这个指标实际上就是这张会话表最多能装下多少条条目。举个例子一台PC打开一个门户网站浏览器经常为了加载图片、脚本、样式表和服务器建立几十条并行TCP连接每条连接都在会话表里占一个位置。如果这台PC还在走NAT上网那么出去时源地址和源端口都要被映射成公网地址和公网端口会话表项同样只增不减。所以很多人以为“并发连接数等于在线人数”这在今天的高并发应用环境下早就站不住脚了。还要注意一点并发连接数高不等于吞吐量大。两者描述的是完全不同的资源瓶颈。可能出现连接数非常多但流量很小的情况比如大批设备只在后台做心跳上报每条连接每隔几秒发一个几十字节的小包也可能出现吞吐很高但连接数不多的情况比如在线视频点播用户数量不多但每个人都在拉大流量。所以这两个参数必须放在一起权衡单看任何一个都没法决定设备大小。1.2 常见协议对会话表的不同占用方式TCP协议必须先建连再传数据所以每次通信都会形成一条完整的会话记录占一个表项。UDP虽然被说成“无连接”但NAT和状态检测防火墙同样会为UDP流量维护“伪连接”靠四元组去追踪回包该往哪送超时后再清除。ICMP也类似防火墙按ICMP ID维护会话。也就是说只要经过状态检测几乎所有业务流量都会消耗会话表资源。很多厂商标称的并发连接数默认指的是TCP会话数量但在实际运行中UDP、ICMP也会被算进来。有的设备管理界面会分别显示TCP连接数、UDP连接数和ICMP连接数有的则是统一合计。看技术参数时最好先确认这个数字是“纯TCP”还是“所有协议加起来的总额”。如果厂商手册里没写清楚我建议在测试环境里开全协议跑一次压测对比一下单TCP和全协议的结果心里才踏实。还有一个容易被忽略的点启用了NAT、端口映射、负载均衡、SSL解密这些功能后一条业务连接可能在防火墙上产生不止一个表项。比如做源NAT转发时内外网地址映射各有一条记录做目的NAT映射到内部服务器时又是一套匹配逻辑。如果你环境里NAT策略很多实际会话表占用会明显高于“纯路由模式”。估算容量时别漏掉这个倍率。2. 并发连接数怎么估算不能只乘在线用户数2.1 一条业务连接背后的“连接倍数”提到并发连接数估算我听过最多的话是“我们公司500人买5万并发的防火墙够了吧”。这个说法太乐观了。一个员工电脑上同时开着浏览器、微信、邮件客户端、企业通信软件浏览器里还挂着几十个标签页。每次打开页面HTTP会与服务器建立多条并行连接视频网站更会把音频流、视频流、字幕、埋点统计分配到不同域名下同时拉取。真实测算下来一个在线用户平均能产生二三十条并发连接重度使用者突破五十条也不是没可能这还不算手机、平板、会议室设备。一个500人规模的公司假设同时在线的有400人办公网络本身的并发连接数起步就是8000到12000。如果再叠加视频会议、云办公、远程桌面这些高会话应用突破20000是非常正常的。所以我在帮朋友公司看防火墙配置时第一件事不是看带宽而是数一下内部终端和应用类型再决定并发连接数应该选多大。2.2 按业务场景给出估算经验值我自己习惯把场景分成三类来估算纯办公网络在线用户数乘以20到40作为基础并发值。如果公司重度使用视频会议、云办公乘数往上靠如果只是普通网页加邮件可以取下限。办公加少量对外服务办公部分照旧估算对外服务部分按终端请求数来算一台Web服务器正常流量可能有5000到8000并发促销或者突发流量场景轻松破两万。数据中心防火墙对话的往往不是人而是服务器之间不断发起的调用。数据库、分布式中间件、微服务网关之间的连接数极其夸张一台物理机可能就占一两万会话一个机柜十几台机器跑下来会话表到二十万级很常见。这种情况不能按用户数估必须按服务器的会话密度计算。我整理了一个粗略参考表适合选型时先打个底场景在线规模日常峰值并发参考建议选型下限20-50人办公室在线50人3000-60003万-5万200-500人企业在线300人左右2万-5万10万-20万1000人以上总部在线800人以上10万-20万30万-50万数据中心出口服务器集群20万起步100万以上表格只是参考但它能说明一个趋势并发连接数不是线性的“人数乘几倍”就能解决的公司规模越大、应用越复杂人均会话数反而越高。2.3 给“峰值并发”留多少余量才合理并发连接数一旦被打满后果是实实在在的丢包和新连接建立失败。预留余量这事没有标准答案我的习惯是把日常峰值再乘1.5到2倍作为采购目标。比如日常观测到的峰值并发是6万那采购目标就瞄着10万以上。因为月底结算、全员视频会议、系统批量推送这类突发事件会话数比日常翻一倍很常见。更麻烦的是会话数打满时防火墙会触发“会话老化加速”机制把一些原本还在活跃状态的连接提前踢走表现为业务时不时断一下重连。这种体验问题比吞吐慢更恶心因为用户感知特别明显。所以从成本角度讲并发连接数这块多留点余量是性价比非常高的选择。3. 吞吐量融合路由、NAT和应用检测的真实速率3.1 标称吞吐为什么会打不过标称带宽吞吐量的单位是bps指的是防火墙单位时间内能处理并转发的数据量。很多人把防火墙吞吐量直接等同于出口带宽办了500M专线就买一台500M吞吐的防火墙。这个思路不够严谨。防火墙做的事比交换机复杂得多收到包要查会话表、匹配安全策略、做NAT转换、跑应用识别、算哈希开了内容安全引擎还要做深度报文检测。每一步都在消耗CPU和内存资源。厂商标注的吞吐量通常是在最大包长、双向流量压测下得出的数字而且一般没有开启全套高级安全功能甚至不一定开了NAT。你接上真实业务后所有策略、日志、审计默认全开性能掉一半甚至更多都不奇怪。所以我一直跟朋友强调别只看参数页上好看的标称值一定要搞清楚这个值是在什么条件下测出来的。标称一万兆吞吐的盒子开启入侵防御和应用识别后可能连一半性能都跑不到但这不一定是设备质量有问题而是你买的时候没看“功能开启后”的吞吐指标。3.2 小包转发率是检验防火墙真实处理能力的关键大包转发对设备比较友好瓶颈主要在端口带宽和总线速度。但现实网络里有大量小包DNS查询、游戏心跳、监控数据采集、物联网上报这些包体很小封装头占比极大单位时间内要处理的包数量会高得吓人。这也是专业设备参数里除了吞吐量还要标注“包转发率”的原因。一台宣称1Gbps吞吐的防火墙如果标称的64字节小包转发率很低真实环境下可能连300M到400M的有效转发都跑不到。小包场景最典型的案例就是安防视频监控。很多摄像头默认MTU比较小IPC回传的1080P视频流会被拆成大量小包一个NVR背后几十上百路摄像头小包风暴能把很多中低端防火墙直接打懵。做园区网、厂区网这类环境选型时不要只盯着出口带宽和并发连接数必须问厂商要64字节包转发率的数据。如果厂商销售支支吾吾不想给多半是这块数据拿不出手。3.3 双向吞吐不要被单向测试数据忽悠很多防火墙的技术手册里会标注“吞吐量X Gbps”但仔细看测试条件可能写的是“单向”。单向测试是只从一个方向灌流量双向测试是同时从两个方向打流。真实世界中双向才是常态办公环境下载上传同时存在视频会议更是高上下行负载。在做总部与分支机构的加密隧道互联时还要格外注意流量过隧道时的吞吐衰减。隧道加解密本身就是CPU密集计算封包和拆包还要多一层处理所以隧道模式下的吞吐可能只有同设备纯转发模式的几分之一。选型时如果网点之间大量使用加密隧道不能只看普通转发吞吐要和厂商确认“隧道模式下的吞吐量”。遇到不标这一项的设备我的做法是直接问销售要一份实测数据没有实测数据就直接降低期望值来处理。4. 从选型到验收怎么把这些指标落到实际采购中4.1 不同规模网络的参考配置说了这么多原理给一份实战选型参考。以企业出口防火墙为例场景日常并发建议最大并发连接数建议吞吐量不开高级安全功能备注20-50人办公室3000-50003万-5万500M-1Gbps低配x86设备够用200-500人中型企业2万-5万10万-20万2Gbps-5Gbps要开IPS时建议再高半档1000人以上总部10万以上30万-50万10Gbps以上优选硬件加速型号数据中心出口20万以上100万以上20Gbps以上尽量避开纯虚拟实例直接扛大流量这个表的前提是业务类型以常规办公和数据中心流量为主。如果场景里包含大量小包转发、视频监控、或者高强度加密隧道那吞吐量还要再往上提。记住一个原则并发连接数决定设备“抗不抗造”吞吐量决定设备“跑得快不快”两个都别省。4.2 用工具自测防火墙的底线设备买回来后验收环节不能省。我最常用的办法是把防火墙串到测试环境或业务旁路先全放通策略跑一轮纯转发吞吐再开启高级安全策略跑一轮看性能衰减比例。手头没有专用测试仪也没关系两台PC加上开源打流工具就够用。Linux环境下最顺手的是iperf3。具体操作可以这样来在防火墙两侧各部署一台服务器网卡最好万兆系统用Ubuntu或CentOS都行。接收端执行iperf3 -s监听端口。发送端执行iperf3 -c 对端IP -P 10 -t 60用10个线程持续打60秒记录吞吐值。把防火墙两侧的发送端都跑一遍测出两个方向的数值。在防火墙上开启IPS、防病毒等策略重复一次记录衰减幅度。测出来的数据自己留档。以后如果业务变慢、设备老化再跑一次对比就能很快判断是策略问题还是设备性能问题。这个方法不复杂但比翻厂商说明书有用得多。4.3 好用的基线监控习惯设备上线不是终点日常监控才是避免指标打爆的关键。我的做法是在防火墙上开启SNMP或厂商提供的SDK接口接入Zabbix、Prometheus这类监控平台把当前并发会话数、每秒新建会话数、CPU使用率、内存使用率、各接口进出流量全部做成曲线。然后设两个告警阈值并发连接数达到设备最大值的70%就告警。吞吐量持续5分钟超过设备标称吞吐的60%记录关注事件。阈值设定的逻辑是并发连接数是硬资源一旦打满基本等于故障所以阈值放低吞吐量是柔性资源短时间冲高问题不大可以适当放宽。另外每秒新建连接数这个指标也要盯它反映的是设备处理“新会话”的能力和并发连接数是两个维度。5. 常见问题与排查技巧实录5.1 并发连接数打满了怎么办这个场景我碰到过不止一次。现象是办公室突然集体反映网页打不开、系统卡顿防火墙事件日志里出现“会话表满”或者“新连接被拒绝”的记录。遇到这种问题先别急着怀疑设备按顺序排查登录防火墙管理界面看当前活跃会话数、新建会话速率以及会话表占用比例。按源地址排序找出占用会话数最多的IP确认是不是内网某台机器异常。按目的地址排序看大量连接是否指向同一个外网地址。如果指向同一个地址可能是木马外联也可能是正常的集中式业务调用。如果是正常业务导致的全员开会、系统集中推送那就考虑缩会话老化时间或者直接扩容。如果是个别机器中毒立即隔离该IP再清理木马。这里有个小技巧多数防火墙支持把“会话排名Top N”导出成CSV文件里面包含源IP、目的IP、会话数。导出来用办公软件排序很快就能锁定嫌疑设备。比在管理界面上一页页翻快得多。5.2 吞吐量掉得厉害时先看看是不是功能叠加吞吐量衰减最典型的根源是安全功能叠加。IPS、防病毒、URL过滤、SSL解密每开一个所有流量都要被多扫描一遍CPU自然吃紧。排查这类问题时把功能逐个关闭对比每个功能对吞吐的影响。ACL和纯NAT一般影响较小深度包检测类的引擎影响最大。如果设备硬件有限但又必须开安全检测就把检测重点放到HTTP、SMTP、文件传输这一类高风险流量上视频流和备份流尽量放行或者降低检查强度。让不同流量走不同强度的安全策略是平衡安全性和性能的常见做法。全部流量一视同仁地做深度检查硬件再强也扛不住。5.3 永远留一份“性能基准报告”我每次会在防火墙上线、策略大调整之后把当前会话数基线、各接口吞吐基线、开启策略后的性能衰减率记录下来整理成文档存档。遇到性能投诉时直接拿历史基线对比很快能判断是网络变化还是设备性能退化。这个方法虽然朴素但在日常排障中非常管用比到处翻告警日志高效得多。一路做下来我的体会是一台防火墙的参数表再漂亮也比不上上线时认真做一轮基线测试来得可靠。并发连接数和吞吐量这两个指标就像发动机的排量和马力数据本身不会说谎但脱离使用场景谈数据很容易被参数带偏。把刚需场景摸清楚再拿实测数据去验证选型这件事才能真正做到心里有数。