趙 明，萬(wàn) 倩 ，白 鶴，李 博

（1.廣播科學(xué)研究院，北京 100053；2.國(guó)家廣播電視網(wǎng)工程技術(shù)研究中心，北京 100866）

1 廣電寬帶數(shù)據(jù)網(wǎng)現(xiàn)狀

中國(guó)廣播電視網(wǎng)絡(luò)經(jīng)過(guò)幾十年的發(fā)展，已建成世界上覆蓋人口最多，無(wú)線、有線、衛(wèi)星等多種技術(shù)手段并用，中央與地方、城市與農(nóng)村、國(guó)內(nèi)與國(guó)外并重的規(guī)模龐大的廣播電視網(wǎng)絡(luò)，廣播電視的傳播能力、覆蓋水平、服務(wù)質(zhì)量大大提高，廣播電視數(shù)字化進(jìn)程明顯加快，進(jìn)入了有線、無(wú)線、臺(tái)內(nèi)數(shù)字化全面推進(jìn)的新階段。截至2011年底，中國(guó)有線電視網(wǎng)絡(luò)擁有1.9億有線電視用戶，是用戶聚集度最高、用戶終端規(guī)模全球最大的有線電視網(wǎng)絡(luò)，是入戶帶寬資源最高的基礎(chǔ)信息網(wǎng)絡(luò)，這些都是下一代寬帶網(wǎng)絡(luò)與應(yīng)用技術(shù)研究最堅(jiān)實(shí)的物質(zhì)基礎(chǔ)。

隨著入網(wǎng)用戶的增加，用戶對(duì)業(yè)務(wù)的需求也日益膨脹，廣電寬帶數(shù)據(jù)網(wǎng)將向多業(yè)務(wù)承載網(wǎng)的方向發(fā)展。在系統(tǒng)中引入的BRAS（Broadband Remote Access Server，寬帶接入服務(wù)器）設(shè)備負(fù)責(zé)終端用戶的連接和用戶流量的匯聚，并與認(rèn)證系統(tǒng)、計(jì)費(fèi)系統(tǒng)和客戶管理系統(tǒng)及服務(wù)策略控制系統(tǒng)相配合，實(shí)現(xiàn)用戶接入的認(rèn)證、計(jì)費(fèi)和管理功能。BRAS具有靈活的接入認(rèn)證方式、有效的地址管理功能、強(qiáng)大的用戶管理功能，并能提供豐富的業(yè)務(wù)及控制功能。

在建設(shè)用戶認(rèn)證系統(tǒng)平臺(tái)中，如何使用正確的測(cè)試方法評(píng)估系統(tǒng)的處理能力，確保在高峰期間系統(tǒng)的穩(wěn)定性和健壯性，成為有線網(wǎng)絡(luò)運(yùn)營(yíng)商面臨的重要問(wèn)題。

2 Web認(rèn)證技術(shù)

2.1 概念

Web認(rèn)證接入方式采用了HTTP重定向技術(shù)，客戶端無(wú)需安裝任何軟件，用戶打開(kāi)瀏覽器輸入任意網(wǎng)址后，由認(rèn)證系統(tǒng)推送認(rèn)證登錄界面，輸入用戶名和密碼發(fā)送到認(rèn)證服務(wù)器進(jìn)行身份認(rèn)證，從而獲得相應(yīng)的授權(quán)。

2.2 認(rèn)證系統(tǒng)體系結(jié)構(gòu)

在使用Web認(rèn)證的系統(tǒng)中，AAA服務(wù)器（認(rèn)證、授權(quán)和計(jì)費(fèi)，Authentication，Authorization，and Accounting）與BRAS設(shè)備之間使用RADIUS（遠(yuǎn)程用戶撥號(hào)認(rèn)證系統(tǒng)，Remote Authentication Dial In User Service）協(xié)議，BRAS設(shè)備為AAA服務(wù)器的客戶端。門戶服務(wù)器從用戶提交的報(bào)文中將用戶名和密碼提取，封裝成相應(yīng)的報(bào)文傳遞給BRAS設(shè)備，BRAS設(shè)備再與AAA服務(wù)器通信完成認(rèn)證，體系結(jié)構(gòu)如圖1所示。

2.3 Web認(rèn)證系統(tǒng)流程

Web認(rèn)證系統(tǒng)的流程，從用戶發(fā)起HTTP請(qǐng)求、BRAS設(shè)備觸發(fā)認(rèn)證、到用戶完成認(rèn)證，可以劃分為6個(gè)步驟，如圖2所示。

1）用戶登陸瀏覽器，輸入任意網(wǎng)址發(fā)出HTTP請(qǐng)求，BRAS設(shè)備收到后，判斷用戶是否通過(guò)認(rèn)證，如果用戶沒(méi)有經(jīng)過(guò)認(rèn)證，則將認(rèn)證門戶服務(wù)器地址推送到用戶客戶端。

2）用戶客戶端對(duì)認(rèn)證門戶服務(wù)器發(fā)出登陸頁(yè)面的HTTP GET請(qǐng)求，認(rèn)證門戶服務(wù)器返回登陸頁(yè)面的URL地址。

3）用戶通過(guò)瀏覽器頁(yè)面呈現(xiàn)的表單輸入用戶名密碼，提交給門戶服務(wù)器的認(rèn)證模塊，等待認(rèn)證結(jié)果。

4）門戶服務(wù)器認(rèn)證模塊將用戶信息進(jìn)行協(xié)議封裝后傳遞給BRAS設(shè)備對(duì)應(yīng)接口。

5）BRAS設(shè)備收到帶有用戶信息的數(shù)據(jù)報(bào)文后，經(jīng)過(guò)AAA客戶端接口，使用RADIUS協(xié)議與AAA服務(wù)器完成用戶信息認(rèn)證。

6）返回的結(jié)果信息經(jīng)由門戶服務(wù)器推送到用戶的瀏覽器界面上。

從認(rèn)證系統(tǒng)的體系結(jié)構(gòu)和整體流程可以看出，影響認(rèn)證系統(tǒng)性能的接口和環(huán)節(jié)較多，需要分解整個(gè)流程，單步測(cè)試后，再進(jìn)行整體測(cè)試，以判斷系統(tǒng)的性能瓶頸。

3 測(cè)試方法學(xué)

針對(duì)網(wǎng)絡(luò)應(yīng)用層的測(cè)試方法學(xué)在業(yè)界還沒(méi)有形成系統(tǒng)的RFC文檔，測(cè)試方法的選擇要基于各個(gè)協(xié)議的RFC文檔定義，以及參考相關(guān)網(wǎng)絡(luò)設(shè)備對(duì)于應(yīng)用層測(cè)試的要求。在用戶的整個(gè)認(rèn)證流程中，HTTP協(xié)議和RADIUS協(xié)議都有相關(guān)RFC文檔說(shuō)明。

3.1 HTTP協(xié)議和HTTP事務(wù)處理速率

HTTP（Hypertext Transport Protocol）協(xié)議，即超文本傳輸協(xié)議，是網(wǎng)絡(luò)應(yīng)用層最常用的協(xié)議之一。HTTP協(xié)議目前常用的版本包括HTTP1.0（RFC1945）[1]和HTTP1.1（RFC2616）[2]。兩者的區(qū)別在于是否默認(rèn)支持持續(xù)性連接。持續(xù)性連接是指在最初的HTTP信息交互完成之后，相應(yīng)的TCP連接仍然保持打開(kāi)的狀態(tài)，使用持續(xù)連接，多個(gè)HTTP請(qǐng)求可以在同一個(gè)TCP連接里完成，因而能提高HTTP的性能。

根據(jù)RFC3511[3]中的相關(guān)定義，HTTP事務(wù)是指客戶端和服務(wù)器之間一次請(qǐng)求與響應(yīng)的過(guò)程，因此HTTP事務(wù)處理速率（HTTP Transaction Rate）的測(cè)試目的在于檢驗(yàn)DUT（被測(cè)設(shè)備，Device Under Test）/SUT（被測(cè)系統(tǒng)，System Under Test）能支持的用戶存取HTTP對(duì)象的最大速率。HTTP事務(wù)處理速率測(cè)試的重點(diǎn)在于檢驗(yàn)被測(cè)設(shè)備的CPU運(yùn)算速度、內(nèi)存資源利用率等性能指標(biāo)。對(duì)于用戶而言，如果設(shè)備的運(yùn)算性能和資源不足，盡管網(wǎng)絡(luò)帶寬足夠，用戶仍然無(wú)法體驗(yàn)快速流暢的網(wǎng)絡(luò)應(yīng)用[4]。

3.2 RADIUS協(xié)議和用戶請(qǐng)求處理速率

RADIUS 協(xié)議由 RFC2865[5]、RFC2866[6]定義，是目前應(yīng)用最廣泛的AAA協(xié)議。

用戶請(qǐng)求處理是指用戶通過(guò)客戶端與服務(wù)器之間發(fā)起的一次請(qǐng)求并認(rèn)證完成的過(guò)程。對(duì)于RADIUS服務(wù)器來(lái)說(shuō)，每個(gè)用戶在認(rèn)證過(guò)程中都會(huì)首先向服務(wù)器發(fā)起一次認(rèn)證請(qǐng)求并獲得認(rèn)證的結(jié)果。用戶請(qǐng)求處理速率的測(cè)試重點(diǎn)是檢測(cè)服務(wù)設(shè)備在CPU、內(nèi)存利用沒(méi)有達(dá)到飽和狀態(tài)時(shí)能夠處理的用戶請(qǐng)求速率。如果設(shè)備的最大用戶請(qǐng)求速率不能滿足用戶數(shù)量的設(shè)計(jì)要求，那么就會(huì)導(dǎo)致大量用戶無(wú)法接入的故障出現(xiàn)。

4 系統(tǒng)性能測(cè)試方法研究

基于認(rèn)證流程，系統(tǒng)性能測(cè)試被分解成4個(gè)階段逐一進(jìn)行，使用Spirent Avalanche網(wǎng)絡(luò)應(yīng)用層仿真及性能測(cè)試儀表模擬對(duì)應(yīng)接口的用戶行為。

4.1 BRAS設(shè)備的URL地址重定向性能

基于系統(tǒng)流程，如圖3所示將測(cè)試儀和BRAS連接，BRAS在收到用戶的HTTP GET請(qǐng)求后，首先判斷用戶是否通過(guò)認(rèn)證，如果是未認(rèn)證用戶，則返回認(rèn)證門戶服務(wù)器的URL地址。

圖3 URL重定向性能測(cè)試

1）使用測(cè)試儀模擬客戶端，在測(cè)試儀表的物理測(cè)試端口，通過(guò)配置，模擬仿真一定數(shù)量的IP地址，并保證這些IP地址并沒(méi)有被BRAS設(shè)備認(rèn)證過(guò)，如圖4所示。

圖4 測(cè)試端口模擬客戶端（截圖）

2）配置客戶端發(fā)出HTTP GET請(qǐng)求的行為。由于測(cè)試系統(tǒng)未包含DNS域名解析服務(wù)器，使用任意一個(gè)不可被直接訪問(wèn)到的IP地址即可，例192.168.1.1/index.html（見(jiàn)圖5），客戶端的HTTP版本配置為HTTP 1.1。

圖5 任意HTTP GET請(qǐng)求行為（截圖）

3）GET請(qǐng)求發(fā)出后，BRAS設(shè)備要判斷用戶是否認(rèn)證，并回復(fù)URL重定向的報(bào)文，其中HTTP狀態(tài)碼為302（見(jiàn)圖6），客戶端收到此報(bào)文認(rèn)為一次有效的HTTP重定向請(qǐng)求事務(wù)處理結(jié)束。

圖6 URL重定向報(bào)文（截圖）

4）如果每次事務(wù)處理都成功，則提高每秒鐘事務(wù)的請(qǐng)求數(shù)目，反之則降低。在所有事務(wù)都成功的臨界狀態(tài)下，記錄每秒的事務(wù)請(qǐng)求處理速率（TPS，Transactions/s）。

4.2 認(rèn)證門戶的請(qǐng)求處理能力

認(rèn)證門戶服務(wù)器基于HTTP架構(gòu)設(shè)計(jì)，服務(wù)器的硬件和HTTP軟件環(huán)境的性能同樣會(huì)成為影響Web認(rèn)證整體性能的瓶頸之一。按照?qǐng)D7所示，將測(cè)試儀表和門戶服務(wù)器集群直接連接。

門戶測(cè)試指標(biāo)同樣是HTTP事務(wù)處理速率，同時(shí)需要分別測(cè)試門戶服務(wù)器靜態(tài)首頁(yè)和動(dòng)態(tài)處理兩種情況下的對(duì)應(yīng)數(shù)據(jù)。因?yàn)樵趯?shí)際業(yè)務(wù)運(yùn)行中，如果門戶的動(dòng)態(tài)處理能力出現(xiàn)飽和，但是靜態(tài)性能仍有空閑，用戶還是可以訪問(wèn)到認(rèn)證首頁(yè)。

1）靜態(tài)頁(yè)面

使用測(cè)試儀模擬用戶客戶端，配置客戶端為HTTP1.1版本，對(duì)門戶服務(wù)器的靜態(tài)首頁(yè)發(fā)出HTTP GET請(qǐng)求。記錄系統(tǒng)能夠成功處理的最大HTTP事務(wù)請(qǐng)求處理速率。

2）動(dòng)態(tài)頁(yè)面

使用測(cè)試儀模擬用戶客戶端，配置客戶端為HTTP1.1版本。通過(guò)讀取真實(shí)用戶數(shù)據(jù)信息表（見(jiàn)圖8）中的用戶ID和登陸密碼，對(duì)門戶服務(wù)器的用戶名密碼提交頁(yè)面發(fā)出大量的用戶HTTP POST請(qǐng)求。

門戶服務(wù)器配置模擬認(rèn)證程序，在收到用戶信息后返回HTTP/1.1 200 OK的狀態(tài)結(jié)果（見(jiàn)圖9）。記錄系統(tǒng)能夠成功處理的最大HTTP事務(wù)請(qǐng)求處理速率。

4.3 AAA服務(wù)器RADIUS請(qǐng)求處理能力

AAA服務(wù)器對(duì)RADIUS請(qǐng)求的處理能力是Web認(rèn)證系統(tǒng)性能的重要測(cè)試指標(biāo)。測(cè)試儀和RADIUS服務(wù)器連接如圖10所示。

對(duì)于AAA服務(wù)器的服務(wù)性能，需要測(cè)試記錄用戶請(qǐng)求處理速率。利用測(cè)試儀模擬RADIUS客戶端，按照RADIUS標(biāo)準(zhǔn)協(xié)議發(fā)出認(rèn)證請(qǐng)求，AAA服務(wù)器在收到請(qǐng)求后返回認(rèn)證結(jié)果給客戶端。

對(duì)于不同的AAA服務(wù)器，RADIUS協(xié)議采用的EAP（可擴(kuò)展身份驗(yàn)證協(xié)議，Extensible Authentication Protocol）類型可能不同，在實(shí)際測(cè)試中，主要評(píng)估的是系統(tǒng)處理能力，無(wú)論用戶認(rèn)證是通過(guò)還是拒絕，都算一次有效的請(qǐng)求處理過(guò)程，如圖11所示。

4.4 整體系統(tǒng)處理能力

理論上，上述3個(gè)測(cè)試結(jié)果中獲得的最小數(shù)據(jù)即是系統(tǒng)整體性能參考值。認(rèn)證流程涉及的每個(gè)環(huán)節(jié)和接口，都可能會(huì)對(duì)測(cè)試結(jié)果帶來(lái)影響，為了保證該數(shù)據(jù)的準(zhǔn)確性，需要進(jìn)行一次完整的系統(tǒng)測(cè)試，如圖12所示。

負(fù)責(zé)認(rèn)證的服務(wù)系統(tǒng)位于省級(jí)的中心機(jī)房，BRAS設(shè)備位于地市機(jī)房。整體性能測(cè)試將認(rèn)證系統(tǒng)看作一個(gè)黑盒，使用網(wǎng)絡(luò)測(cè)試儀讀取用戶信息數(shù)據(jù)表數(shù)據(jù)，模擬用戶發(fā)起HTTP GET請(qǐng)求，獲得重定向地址后，輸入用戶名密碼，HTTP POST提交后，返回HTTP/1.1 200 OK的狀態(tài)碼。

測(cè)試儀表配置中，需要對(duì)每一步系統(tǒng)回應(yīng)報(bào)文的捕獲后，提取相關(guān)變量，模擬用戶客戶端連續(xù)請(qǐng)求發(fā)出過(guò)程。在獲得到HTTP/1.1 200 OK狀態(tài)碼后，一個(gè)有效的認(rèn)證流程結(jié)束。將整個(gè)認(rèn)證過(guò)程看成一個(gè)HTTP事務(wù)處理，記錄獲得的HTTP事務(wù)處理速率，即整體系統(tǒng)的性能。

5 結(jié)論

本文研究了針對(duì)基于BRAS設(shè)備Web認(rèn)證系統(tǒng)的性能測(cè)試方法。根據(jù)Web認(rèn)證系統(tǒng)自身的特點(diǎn)，將被測(cè)系統(tǒng)劃分為3部分分別測(cè)試，獲取相應(yīng)的數(shù)據(jù)后，再進(jìn)行整體測(cè)試。運(yùn)用此方法可以有效地發(fā)現(xiàn)認(rèn)證系統(tǒng)存在的性能瓶頸，并在進(jìn)行整體測(cè)試時(shí)，可以模擬更接近真實(shí)處理能力的請(qǐng)求量。

隨著廣電寬帶數(shù)據(jù)網(wǎng)的進(jìn)一步建設(shè)，BRAS設(shè)備會(huì)被更加廣泛地使用，而Web認(rèn)證作為一種認(rèn)證手段也會(huì)得到相關(guān)的應(yīng)用。運(yùn)用合理的性能測(cè)試方法，可以準(zhǔn)確判斷系統(tǒng)的瓶頸，為制定系統(tǒng)進(jìn)一步的升級(jí)改造策略提供指導(dǎo)。

[1]BERNERS L T，F(xiàn)IELDING R，F(xiàn)RYSTYK H.Hypertext transfer protocol—HTTP/1.0，RFC1945[S].1996.

[2]FIELDING R，GETTYS J，MOGUL J，et al.Hypertext transfer protocol—HTTP/1.1，RFC2616[S].1999.

[3]HICKMAN B，NEWMAN D，TADJUDIN S.Benchmarking methodology for firewall performance，RFC 3511[S].2003.

[4]林田，施小秋，胡波.網(wǎng)絡(luò)性能測(cè)試與分析[M].北京：高等教育出版社，2009.

[5]RIGNEY C，WILLENS S，RUBENS A，et al.Remote authentication dial in user service（RADIUS），RFC 2865[S].2000.

[6]RIGNEY C.RADIUS accounting，RFC 2866[S].2000.