园区WiFi认证早高峰洪峰怎么扛住

园区里大多数时间认证压力是均匀的，但有几个瞬间是尖峰。早上上班，几百个员工同时进楼、同时连WiFi、同时弹Portal、同时输密码或者扫码；大型会议散场，整个会议室的人同时掏出手机；年会、招聘会、园区活动结束，几千人同时断网重连。这些瞬间对认证系统是真正的压力测试。平时跑得好好的认证系统，到了八点五十分可能就开始卡，用户侧看到的就是Portal加载不出来、认证转圈、二维码刷不出来。

认证洪峰和网络带宽压力不是一回事。带宽压力是用户连上之后跑流量，洪峰是用户在认证的那几秒钟集中请求认证网关、Portal服务器、RADIUS服务器、AD域控制器。这几个后端在那一瞬间要同时处理成百上千个并发认证请求，任何一个组件瓶颈，整个认证链路就堵了。

先看认证链路里的几个关键环节。用户连上WiFi之后，AP把用户流量转发到AC，AC根据SSID配置把未认证流量重定向到Portal服务器。用户打开Portal页面，Portal服务器把页面推给用户。用户输入账号密码，Portal把请求转发给RADIUS服务器，RADIUS去查AD域或者本地数据库，验证完返回Access-Accept或者Access-Reject。AC收到接受报文，把这个用户从隔离区放行到正常网络。这条链路里，Portal服务器、RADIUS服务器、AD域控制器，任何一个扛不住并发，整条链路就慢。

早高峰为什么会集中？因为员工都是八点半到九点之间进楼，手机连WiFi是自动的，Portal页面一弹出来大家就同时操作。这种洪峰不是流量洪峰，是连接洪峰。后端服务器平时可能只跑了百分之十的CPU，早高峰瞬间冲到百分之百。所以认证系统的容量设计不能按平均并发算，要按峰值并发算。

怎么扛这个峰值，分几层来做。

第一层是AC和接入层的优化。AC本身是无状态的转发设备，压力不大，主要是AP和交换机要够。但AP在洪峰瞬间要处理大量用户的关联请求，单台AP带的用户数不能堆太多。办公室里一台AP覆盖二三十个用户是合理的，走廊上一台AP覆盖整个楼层几百个用户，早高峰的时候这台AP就是瓶颈。AP部署密度要按峰值用户数算，不能按平均人数算。

第二层是Portal服务器。Portal页面是静态资源，压力主要在并发连接数和页面加载速度上。Portal服务器前面可以加一层缓存或者CDN（注意是内网CDN，不是公网），把静态页面缓存住，不用每个请求都打到应用服务器。Portal页面本身要轻量化，这一点前面讲过，加载越快，服务器占用连接的时间越短，能扛的并发越多。如果Portal服务器只有一台，要准备双机或者至少做会话保持，不要单点。

第三层是RADIUS认证服务器。RADIUS是整个认证链路里最重的环节，每个用户认证都要走它。RADIUS要部署多台做负载均衡，AC把认证请求按轮询或者一致性哈希分到不同RADIUS节点上。RADIUS节点之间不需要共享会话，因为认证是一次性请求，每个用户每次认证独立发一次请求，天然适合分布式。

第四层是后端用户目录，也就是AD域或者LDAP。RADIUS验账号密码的时候，最终要去查AD域。AD域是企业的核心目录，平时给办公电脑登录、邮箱登录、OA登录提供服务，早高峰员工连WiFi的时候，又多了几百上千个认证请求打过来。AD域服务器要评估能不能扛这个并发。如果AD域本身压力已经很大，RADIUS可以做本地缓存：把最近认证成功的账号密码哈希在本地缓存一段时间（比如一小时），期间员工再认证，RADIUS直接本地验，不用每次都打AD。这样既减轻AD压力，又加快认证响应。密码改了之后缓存失效，走全量验证。

第五层是超时和降级策略。洪峰的时候，后端真的扛不住，不能让用户一直转圈。认证网关要配合理的超时时间：RADIUS请求超过三秒没响应，就返回"认证服务繁忙，请稍后重试"，不要让用户等十秒。AC端的用户隔离区要保持可访问Portal的状态，不要把Portal也挡在隔离区外面，不然用户连错误提示都看不到。

还有一个被忽略的优化是MAC无感知的覆盖率。如果员工手机第一次认证之后，系统记住了MAC，第二天员工到楼下连WiFi，AC直接根据MAC放行，根本不用弹Portal、不用走RADIUS。这一下就把第二次、第三次认证的后端压力全消掉了。所以早高峰真正打后端的，主要是第一次连的设备、换了手机的设备、没记住MAC的设备。把MAC无感知的窗口配长一点（比如七天或者三十天），员工在这个周期内每天连网都不用走认证流程，洪峰自然就小了。

洪峰的另一个来源是活动结束。年会散场的时候，几千人同时在一个区域，AP负载瞬间飙升，认证请求也跟着来。这种情况提前知道时间点，可以临时加开认证服务器、临时扩AP容量。园区里有大型活动之前，IT要提前做容量预案，不要等到活动当天才发现Portal打不开。

容量设计还要留余量。按峰值并发的两倍来规划服务器和AP，而不是按峰值刚好够。因为你不知道哪天会有新情况：新员工入职、新租户进场、新设备上线，都会慢慢加压力。洪峰测试也要做，在上线之前用压测工具模拟几百上千个并发认证，看看链路哪里先卡住，提前扩容。

园区WiFi认证不是配好账号就能跑的东西，它是一个有峰值、有瓶颈、需要容量规划的后端服务。把接入层、Portal层、RADIUS层、AD层分开看，每层都留够余量，把MAC无感知用好，把超时降级配好，早高峰那几分钟才不会变成用户集体投诉的时刻。