PPPoE認證方式中使用者“掛死”現象分析及解決策略
近年來，隨著寬頻業務的蓬勃發展，原來用於圈地的包月制計費方式已經不能滿足使用者的要求，寬頻應用管理計費系統的建設已經成為電信運營商迫切的需求。在這種情況下，各省地市電信運營商都將寬頻應用管理計費平臺的建設納入了計劃日程。
筆者在參與運營商寬頻應用管理計費系統建設過程中，發現普遍存在使用者掛死現象，這需要引起運營商的注意，因為這個問題在運營商寬頻應用管理計費系統建設中關係重大。
2 PPPoE的認證過程
為了更好地理解掛死現象產生的原因，下面先分析PPPoE認證計費流程。圖1所示為典型的電信運營商認證計費系統PPPoE認證計費流程。
|
圖1PPPoE認證計費流程 |
2.1 PPPoE認證的發現階段
使用者開啟PPPoE虛擬撥號程式，計算機通過在乙太網上廣播PADI（PPPoE Active Discovery Initiation）分組來發現寬頻接入伺服器（BAS），PADI分組一旦到達BAS，BAS回發PADO(PPPoE Active Discovery Offer)分組作為響應。此時，可以認為發現階段已經完成。但是，人們通常把LCP（Link Control Protocol）過程也視為發現階段的一部分，即計算機作為PPP終端傳送LCP分組來配置和測試鏈路（在此過程中需要指定認證的壓縮方式等引數），
2.2 PPPoE認證的連線階段
與BAS建立鏈路之後，PPPoE終端發出認證包請求認證，這種認證包可以採用PAP（Password Authentication Protocol）或者CHAP（Challenge Handshake Authentication Protocol）兩種方式，基於對網路安全性的考慮，一般採用CHAP方式。BAS收到認證報文後，根據系統的設定判斷如何處理該報文。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%。雖然現在計算機的處理能力越來越高，增加的負荷基本不會影響系統的正常運轉，但對於特大的計費系統，這樣使用仍然存在風險。
此外，對於極少數的使用者“掛死”現象，可以通過限制最大線上空閒時長來減少超長話單的產生，以避免糾紛的出現。