转载的，文章写得很好
近年来，随着宽带业务的蓬勃发展，原来用于圈地的包月制计费方式已经不能满足用户的要求，宽带应用管理计费系统的建设已经成为电信运营商迫切的需求。在这种情况下，各省地市电信运营商都将宽带应用管理计费平台的建设纳入了计划日程。
笔者在参与运营商宽带应用管理计费系统建设过程中，发现普遍存在用户挂死现象，这需要引起运营商的注意，因为这个问题在运营商宽带应用管理计费系统建设中关系重大。
2 PPPoE的认证过程
为了更好地理解挂死现象产生的原因，下面先分析PPPoE认证计费流程。图1所示为典型的电信运营商认证计费系统PPPoE认证计费流程。
|
图1 PPPoE认证计费流程 |
2.1 PPPoE认证的发现阶段
用户打开 PPPoE 虚拟拨号程序，计算机通过在以太网上广播 PADI （ PPPoE Active Discovery Initiation ）分组来发现宽带接入服务器（ BAS ）， PADI 分组一旦到达 BAS ， BAS 回发 PADO(PPPoE Active Discovery Offer) 分组作为响应。此时，可以认为发现阶段已经完成。但是，人们通常把 LCP （ Link Control Protocol ）过程也视为发现阶段的一部分，即计算机作为 PPP 终端发送 LCP 分组来配置和测试链路（在此过程中需要指定认证的压缩方式等参数）， BAS 回送双方确认的信息，同时指定本次计费认证信息的 Session-ID 。需要注意的是，该 Session-ID 在本次连接过程中是惟一的，计费中以这个 ID 号来惟一标识这次连接。至此，发现阶段结束。
2.2 PPPoE认证 的连接阶段
与 BAS 建立链路之后， PPPoE 终端发出认证包请求认证，这种认证包可以采用 PAP （ Password Authentication Protocol ）或者 CHAP （ Challenge Handshake Authentication Protocol ）两种方式，基于对网络安全性的考虑，一般采用 CHAP 方式。 BAS 收到认证报文后，根据系统的设置判断如何处理该报文。 BAS 如果设置为本地认证，那么它就发给内置的认证服务器进行处理；如果定义为 Radius 认证，那么它将这个认证报文转发给系统设置的远程 Radius Server 。远程 Radius Server 一般是某数据库的客户端，该数据库存储了所有用户的基本信息，包括用户名、密码、登录名以及账务信息等。远程 Radius Server 根据登录名从数据库中检索出密码数据进行对比，如果相符，就取出相关的属性值发给 BAS ，这个属性包一般称为授权包。 BAS 根据授权包约束用户的会话，一般从带宽、空闲时长或最大连接时长等方面进行约束。同时， BAS 还要起到 DHCP Server 的作用。在执行完这些功能以后， BAS 在建立起连接的同时，向 Radius Server 发送一个计费开始包。这样，一个连接就建立起来了，用户通过该链路收发数据， BAS 则负责对这些数据流量进行计数。
2.3 PPPoE认证 的 断线阶段
断线其实是一个比较复杂的问题。图 1 所示是正常情况下用户主动断线过程。用户点击 PPPoE 拨号程序的“断开连接”按钮，计算机就通过该程序发送 PADT(PPPoE Active Discovery Terminate) 分组，当 PADT 分组到达 BAS 后， BAS 计算本次会话的流量等信息，并将这些信息封装在一个计费结束报文中发送给计费系统。正常情况下，计费系统根据这些信息产生一条账单，账单信息进入系统结算程序进行结算。但很多时候可能出现非正常断线，如直接关机、断电等。非正常断线需要通过宽带 BAS 的在线监测机制进行判定，例如在 BAS 和用户计算机之间建立一种连接， BAS 定期轮询用户计算机，用户计算机做应答，如果多次收不到应答，则认为用户计算机非正常下线， BAS 根据记录产生一个计费结束报文，发送本次会话信息给计费系统作为账务处理依据。
以上便是 PPPoE 认证计费的整个流程。
3 产生“挂死”现象的原因
在实际应用中我们发现，部分在计费系统中表现为在线的用户实际已经下线，这种现象就是所谓的“挂死”。如果计费系统中“允许账号同时在线的最大用户数”设置为“1”，那么“挂死”的用户在下次登录时将无法上线。
根据PPPoE认证计费流程来分析，用户“挂死”的实质从计费系统角度来看就是：系统未收到计费终止包，无法形成计费记录；用户下线，计费系统相对于用户而言是被动的，如果没有原因促使其做出下线判断，就可能造成用户一直在线的假象。
结合在线测试，我们发现以下因素会引发“挂死”现象。
（1）BAS 不稳定。这是引发“挂死”现象的主要原因。在实际应用中我们发现，一般情况下挂死的用户以某一时间点为分界点，这意味着计费系统在这一段时间没有收到计费 终止包，存在BAS短时间故障，造成当时在线用户全部非正常下线，而BAS未发出任何计费终止包，造成这批用户全部“挂死”。BAS故障导致用户“挂死” 这一结论在我们进行的BAS割接中得到了证实：割接时，所有的割接前在线用户全部挂死！此外，BAS处理能力不够也会产生“挂死”现象。通过测试与对比， 我们发现：在用户规模相同的情况下，性能指标优越的BAS与一般国产的BAS发生“挂死”现象的比例相差甚远。
（2）BAS 和计费系统Radius Server之间网络不稳定。Radius Server协议采用的是UDP，虽然BAS每次会将计费终止包向Radius Server传送3次，且Radius Server和BAS之间采用了实时探测机制，但仍无法保证所有的计费终止包被完整收到。我们通过查看计费终止包统计报告，得知：正常情况 下，Radius Server的丢包率为3%，同一计费终止包3次全丢失的概率约为百万分之二十七，即10 000个用户中每天有1个用户正常挂死。网络异常情况下，显然会大大增加这种概率。加之，目前许多运营商采用分散接入控制方式，计费系统离BAS距离较 远，网络状况比较复杂，从而增大了用户“挂死”的可能性。
（3）计费系统Radius Server处理能力不够。如果Radius Server处理能力不够，可以从系统的资源情况中得到查证，一旦系统资源不够，可能丢弃部分计费终止包。
4 “挂死”现象的解决方案
如果是因BAS 不稳定和/或BAS和计费系统Radius Server之间网络不稳定造成用户“挂死”，则比较难解决。这是因为运营商通常是批量部署BAS的，出于抢占市场考虑，当时主要是解决接入控制问题，对 BAS的性能要求相对较低，更没有进行与计费系统的互通测试。只有通过开发一些更好的检测用户在线的机制来减少“挂死”现象。
如是因Radius Server处理能力不够引起用户“挂死”，则相对而言比较容易解决。现有的计费系统都支持多Radius Server，可以通过增加Radius Server来缓解处理压力。
通过对整个流程和Radius 协议的仔细分析，我们发现RFC 2869扩展的Radius协议中Interim-Accounting机制（也称keep alive功能）可以加以开发利用，以尽量避免“挂死”现象的发生。Interim-Accounting机制是指BAS对于在线用户，每隔一定时间（可 设置，精度为分）向Radius Server发送Interim-Accounting信息，表示用户在线。Interim-Accounting信息包中包含有用户截止到当前的上网信 息（主要指流量信息）。如果BAS开启该功能，就会向计费系统定时发送Interim-Accounting信息，计费系统定义一个刷新间隔，在间隔时间 内未收到该信息，就认为用户下线，并将最后一个Interim-Accounting信息包作为计费终止包来完成用户的下线操作。这样，无论什么原因造成 计费终止包丢失，都可以通过Interim-Accounting信息包来代替，从而有效地避免“挂死”现象的发生。在这种情况下，需避免误将本来在线的 用户强行断线，因为Interim-Accounting信息包同样存在着像计费终止包一样丢失的可能性。一般应将计费系统的刷新间隔设置为BAS发出 Interim-Accounting信息包的周期的3倍，只有系统连续3个Interim-Accounting信息包都没有收到，才将没有计费终止包 的用户强行下线，从而减少错误判断的概率。
当然，上述功能是通过增加系统负荷为代价来实现的。通常情况下，BAS 的负荷理论上增加200%以上，计费系统的负荷也增加200%以上：假设用户平均每次连续上网时间为30 min（通常情况下宽带用户连续上网时间会大于这个数字），BAS按每5 min发出一次Interim-Accounting信息包，计费系统刷新时间为15 min，在启用Interim-Accounting功能以前，在30 min内，BAS和计费系统都只处理1个认证请求报文，1个计费开始报文，1个计费终止报文，而启用后，正常情况下（绝大部分用户都是正常用户），增加了 6个Interim-Accounting信息包，负荷增加了200%。虽然现在计算机的处理能力越来越高，增加的负荷基本不会影响系统的正常运转，但对 于特大的计费系统，这样使用仍然存在风险。
此外，对于极少数的用户“挂死”现象，可以通过限制最大在线空闲时长来减少超长话单的产生，以避免纠纷的出现。