WiFi认证系统在机场航站楼瞬时大并发怎么扛住

机场航站楼的 WiFi 是所有公共场景里对认证系统压力最大的一类。普通写字楼里，人是慢慢流动的，早高峰一批人进来，之后零零散散；机场不一样，一趟航班落地，几百个旅客同时站起来开手机、连 WiFi、查航班动态、给家人报平安，认证请求在几分钟内集中打过来，接着又是下一个航班。这种瞬时大并发，对 WiFi认证系统 的考验和常驻办公网完全不是一个量级。

机场场景的用户结构本身就决定了它的压力形态。候机楼里大部分是临时旅客，不是固定用户，他们不会反复连、不会记住账号密码，连上来主要就是为了收个验证码、上几分钟网。旅客来自全国各地，手机号归属地多样，短信通道要能覆盖全国；里面还混着国际旅客，他们的认证方式又是另一套要求。这些用户的共同特点是：单次在线时间短、并发高度集中、对认证速度极其敏感——旅客拖着行李站在登机口旁边，不会耐心等一个转圈的认证页面。

瞬时并发和平均在线是两个概念。航站楼里同一时刻在线的旅客可能有几千人，但这个数字是慢慢累积、慢慢回落的；真正压垮认证系统的，是一趟航班到达之后那三五分钟内，几百个终端同时发起认证请求。一套 Portal 系统在设计上每秒可以处理数千次认证，Radius 侧也有对应能力，但能不能在这种突发流量下稳住，要看部署方式和容量余量。按平均在线去规划容量，在机场场景一定不够，必须按高峰瞬时并发来算。

认证方式要选最不折腾旅客的。旅客在机场没有耐心输入一长串账号密码，双因子、802.1X 这类对终端有要求的方式在这里完全不现实。最通用的做法是短信验证码：旅客连上 SSID，Portal 页面自动弹出，输入手机号收个码，填进去就上网。这个流程对旅客设备零要求，任何智能手机都能跑。对国际旅客，如果现场有相应安排，可以结合前台登记、临时授权码或者多语言 Portal 提供替代方案，但国内旅客的主路径就是短信认证。

Portal 页面的加载速度在这种场景里被放大。旅客网络体验的第一印象，就是连上 WiFi 之后认证页面多久弹出来、填验证码的时候响应快不快。如果页面本身要加载好几秒，高峰期几百人同时拉这个页面，服务器和带宽都要扛得住。Portal 页面要做得轻量，不要堆大图片和复杂脚本，认证表单之外的内容尽量少；页面资源尽量做缓存和 CDN 分发，不要每次认证都从服务器重新拉。页面快一秒，高峰时整体体验就好一个档次。

短信通道要按峰值容量规划。每条短信验证码都要通过运营商通道发出去，高峰期每秒要发多少条，通道能不能承载，是机场场景特有的问题。短信通道不是无限的，普通商务套餐平时够用来着，航班集中到达时可能就堵了。部署时要和短信服务商确认峰值发送能力，必要时开通更高的并发额度，或者准备备用通道。验证码短信发不出去，旅客就反复点重新发送，形成更猛的二次冲击，恶性循环。

旅客的网络访问范围要控制好。航站楼里开放 WiFi，不代表旅客可以无限制用网。高峰期如果不做带宽管理，几个旅客下载大视频，整个候机楼的出口带宽就被吃光，其他人连网页都打不开。机场场景通常给每个用户做一个合理的带宽上限，保证查航班、收发消息、视频通话基本流畅，同时把大流量下载、视频流媒体限制在不影响整体体验的范围。这个策略要在认证成功之后由系统自动下发，不需要旅客做任何设置。

认证日志在这种人流密集场所尤其重要。旅客上网要符合实名和日志留存的要求，认证系统记录的手机号、认证时间、在线时长、IP 地址，按合规要求留存。一旦发生涉及网络安全的事件，或者旅客投诉网络问题，这些日志是追溯依据。机场人员流动极大，日志链路任何环节出缺口，事后想补都补不回来，所以上线前就要验证日志记录是完整的、时间是准确的。

高峰时段的系统冗余不能省。航站楼一旦网络出问题，影响的是几百上千旅客的体验，还可能涉及航班信息查询这类刚需业务。认证系统在这种场景通常要考虑高可用部署，主节点出问题的时候备节点能接上来，不至于整栋楼旅客同时上不了网。这种冗余配置平时看不到价值，真正故障时就是区分"小波动"和"大面积事故"的关键。

旅客连网的故障处理要和航空公司、地服的流程配合好。高峰期大量旅客同时连不上网，电话很快会被打到服务台。现场工作人员需要有一份简单的指引：连不上 WiFi 先做哪几步，什么时候联系 IT。认证系统后台也要在高峰期有人盯实时状态，发现认证成功率掉下来，在旅客大规模投诉之前就介入。

机场航站楼的 WiFi 认证，本质上是在一个人流高度流动、并发高度集中、用户极度没有耐心的环境里，把认证这件事做到几乎无感。它不需要很复杂的高级认证功能，考验的是系统在瞬时压力下稳不稳、认证流程短不短、页面快不快、短信通道跟不跟得上。把这几件事按高峰场景规划好，旅客的体验就是"连上就走"，而不是"站在登机口转圈"。