WiFi网络计费系统的RADIUS对接是一个很容易被低估的技术环节。很多人觉得RADIUS就是一个标准协议，配好IP、端口和共享密钥就完事了。但实际上RADIUS的RFC定义和各家NAS厂商的实际实现之间，存在着一大堆隐性的差异。这些差异在你只有几十个AP、几百个用户的时候几乎感觉不到，但规模一上去就变成定时炸弹。

RFC 2865和2866定义了RADIUS认证和计费的基本框架，但问题是这个框架太"基本"了。比如CoA（Change of Authorization，RFC 3576），这是WiFi网络计费系统用于主动断开用户会话或者修改用户带宽的关键机制，但不同厂商的实现方式差异很大。

Aruba的CoA实现要求DM（Disconnect Message）必须带特定的VSA（Vendor-Specific Attribute），Cisco的CoA实现对Session-Timeout的处理方式跟华为完全不一样，Ruckus的CoA有时候需要先发一次CoA-Request探测端口再发正式的CoA消息。如果你的WiFi网络计费系统没有针对这些差异做适配，就会出现各种诡异的"有时能断开有时断不开"的问题。

一个务实的做法是：在WiFi网络计费系统的RADIUS对接模块里，预先为市面上主流的NAS厂商维护一份VSA字典。当系统从NAS收到的Access-Request里识别出厂商信息以后，自动加载对应的VSA字典和特殊处理逻辑，而不是试图用一套通用逻辑来适配所有厂商。

RADIUS Accounting用的是UDP协议，UDP不保证送达。在实际网络环境中，计费报文丢失的概率比你想象的高得多。WiFi网络计费系统如果只依赖被动接收Accounting报文来做流量统计，那计费数据一定是不准的——丢了几个包就少了几段流量。

解决这个问题有几种思路。一是让WiFi网络计费系统对Accounting报文做中间计费确认——每隔一段时间（比如五分钟）主动向NAS发送一个Interim-Update的请求，确保中间计费数据不丢失。二是在NAS端启用Accounting-On和Accounting-Off消息，当NAS重启或者网络中断恢复的时候，通过这两个消息来通知计费系统重新同步状态。第三种是在WiFi网络计费系统端维护一个"期望报文序列"，如果在一定时间窗口内没有收到对应会话的计费报文，就主动去NAS上拉取。

WiFi网络计费系统里RADIUS认证失败的原因非常多样：用户名错误、密码错误、账户欠费、设备MAC不在白名单、超过了同时在线数限制、NAS本身配置有问题等等。如果系统只返回一个"认证失败"的笼统提示，运维那边每次排查问题都要翻RADIUS日志，效率极低。

比较好的做法是在系统内对认证失败原因做精细化的分类和记录。每一种失败原因都有一个独立的错误码和描述，运维人员在管理界面可以直接看到"该用户在08:15认证失败，原因：账户余额不足"。这种精细化的失败分类在用户基数大的时候能显著降低运维的排查成本。

当你的WiFi网络计费系统需要对接几十台甚至上百台NAS设备的时候，单节点的RADIUS服务显然不够。这时候就需要RADIUS代理和负载均衡——多台RADIUS服务器组成一个集群，所有NAS的认证和计费请求通过代理层分发到不同的后端节点。

这里的一个重要设计点是会话保持。同一个用户的连续认证请求（包括初始认证和后续的重认证）应该尽量路由到同一个后端节点处理，因为用户的状态信息通常缓存在内存中。如果每次请求都随机分发到一个新节点，缓存命中率会大幅下降，导致响应延迟增加。WiFi网络计费系统的RADIUS代理层需要支持基于用户名的会话保持策略，比如用用户名的哈希值来决定路由目标。RADIUS对接说起来是一个标准协议对接的问题，但实际做起来牵扯到NAS兼容性、报文可靠性、失败诊断、负载均衡等好几个层面的事情。任何一个层面处理不到位，都会在上线之后变成运维的持续负担。与其上线以后到处打补丁，不如在对接阶段多做测试多记录差异，把每家厂商的RADIUS行为特征沉淀成一份适配手册，以后扩容或者替换设备的时候直接参考。尤其是那些在测试环境里很难复现但在生产环境里频繁出现的边缘情况，比如NAS固件版本升级以后RADIUS字段格式发生变化、跨厂商的AC+AP组合下计费报文的上报频率不一致等，这些都应该记录在适配手册里。一份好的适配手册至少应该包含这些信息：厂商和型号、固件版本、测试过的RADIUS功能清单、已知的兼容性问题、推荐的配置参数、以及对应的Workaround方案。有了这份手册，以后无论是更换设备、新增门店还是给新入职的运维同事做培训，都有了可重复使用的参考依据。