WebCache系統(tǒng)集中采購工程技術規(guī)范書(DOC36頁)(20220203140522)

1、中國移動2022年Web Cache系統(tǒng)集中采購工程技術標準書中國移動通信2022年8月1 總那么 . 11.1概述 11.2技術標準 11.3總體技術要求 11.4標準書應答要求 21.5技術文件 21.6技術建議書應包括的內(nèi)容 31.7報價要求 42 Web Cache 系統(tǒng)建設主要技術要求 . 62.1Web Cached統(tǒng)請求引導機制62.2Web Cach系統(tǒng)建設功能要求92.3與其他系統(tǒng)接口 232.4局域網(wǎng)組網(wǎng)結(jié)構 232.5平安策略 232.6網(wǎng)管需求 243 設備硬件要求. 253.1總體要求 253.2模塊化、冗余、容錯等 263.3效勞器的要求 263.4網(wǎng)絡設備要求 2

2、64 軟件要求. . 274.1模塊化 274.2人機控制 274.3兼容性及升級 274.4操作系統(tǒng) 274.5軟件系統(tǒng)優(yōu)化 285 系統(tǒng)容量要求 . 285.1系統(tǒng)容量的定義 285.2系統(tǒng)容量要求 285.3 系統(tǒng)擴展要求 285.4 本期集中采購建設規(guī)模需求 296 電源要求. 307 設備安裝調(diào)測、驗收以及試運行 . 307.1 安裝和調(diào)試 307.2 驗收 318 技術效勞和培訓 . 328.1 技術效勞 328.2 培訓 331 總那么1.1概述本文件是中國移動通信以下簡稱買方2022年Web Cache系統(tǒng)集 中采購工程向設備廠商以下簡稱賣方提出的技術標準書。本標準書與相關規(guī)

3、范一起將作為2022年集中采購Web Cache系統(tǒng)主設備的技術文件。根據(jù)此文件, 賣方應提出具體的技術應答和詳細的報價。1.2技術標準賣方所提供的所有各項設備和系統(tǒng)包括軟、硬件應符合技術標準的要求如 下：1符合有關標準如 ISO、ITU-T、ETSI、IETF等，賣方應在建議書中具體 說明，并附上相應的詳細技術資料；2符合中國移動通信?中國移動WebCache系統(tǒng)總體技術要求? ?中國移動WebCache系統(tǒng)設備標準?、?中國移動WebCache系統(tǒng)接口標準?、 ?工程和維護合同平安管理要求?等相關標準中對流程、設備、網(wǎng)管等方面的要求，且以上標準今后如有修改，賣方應免費修改其系統(tǒng)以滿足要求；

4、賣方如對以 上標準內(nèi)容有不滿足的地方，請給出技術上不滿足情況的偏離表偏離表格式詳見 附件一并做出相應說明。對于滿足局部，應給出明確的書面承諾。3國家已頒發(fā)的相關法律文件例如招標法等。1.3總體技術要求1賣方應按照本文件的要求提供報價和詳細的技術建議。賣方應承諾所 提供的設備在產(chǎn)品性能、技術指標、效勞內(nèi)容等方面滿足本技術標準書的要求。 對于本文件未規(guī)定的有關設備性能，賣方應提出建議，并陳述其理由。2本文件提出的具體技術要求如與上述文件及補充標準不一致的地方， 以本文件為準。3當買方有新建議，而本技術標準書又尚未包括或與本技術標準書不符 時，那么應符合買方新建議的要求；對于買方尚未有標準的，而本技

5、術標準書又未 提及的局部，賣方提出其標準，留待雙方認可后執(zhí)行。4當賣方的設備中包含自己的專用標準，應在建議書中具體說明，并附 上相應的詳細資料。5賣方應列出其建議書中所提供設備和系統(tǒng)在世界范圍內(nèi)和國內(nèi)的應用 情況，諸如最大規(guī)模、業(yè)務類型及開展方式等。6賣方提供的設備，硬件設備從系統(tǒng)最終驗收開通之日起五年內(nèi)，如果 買方需要，賣方應以不高于本次價格提供備板、備件，賣方不得以設備停產(chǎn)等理 由而拒絕提供。如果由于買方系統(tǒng)改良或擴容，所需的軟件設備賣方應以不高于 本次價格提供。7在合同簽訂之前，買方可以隨時對本技術標準書進行修改。8本技術標準書解釋權歸中國移動通信。1.4標準書應答要求1賣方對于技術標準

6、書的疑問可以通過書面材料與買方聯(lián)系。在規(guī)定的 建議書提交最后期限以前，買方將以書面材料給予答復。有關買方答復材料的復 印件也將遞交所有得到技術標準書的賣方。2在技術談判的各個階段，買方將以書面形式要求賣方對有關問題進行 進一步的技術澄清，賣方應以書面資料給予正式應答；所有各階段的技術澄清文 件都將作為合同附件。3買方在任何時候保存和擁有對本文件的解釋權。買方有權在簽定合同 前，根據(jù)需要修改和補充本技術標準書，修改補充后的最終技術標準書將作為合 同的附件。4賣方的應答書中，要求對本文件的所提出的各項條款進行逐項答復、 說明和解釋，首先對實現(xiàn)或滿足程度明確作出 滿足 局部滿足 不滿足等 應答。在答

7、復中，凡采用詳見參見方式說明的，應指明參見文檔的具體章 節(jié)或頁碼。請賣方特別注意：凡采用 詳見 參見方式說明的條款，必須在點 對點應答書中注有適當?shù)目偨Y(jié)性文字，簡潔、明了地答復相應的條款。對于本文 件中要求列舉的條款，必須在點對點應答書中進行列舉，不得簡單答復滿足等, 否那么視該條款的應答為不滿足如果答復局部滿足需要詳細說明哪些局部 滿足，哪些局部不滿足，并且詳細說明原因。賣方應容許與詳細的說明內(nèi)容一致, 如果應答與說明內(nèi)容矛盾那么視為不滿足1.5 技術文件賣方所提供的應答文本應按照以下內(nèi)容格式進行 附件一：系統(tǒng)價格清單；1總清單2分項清單3設備配置說明附件二：技術標準書及應答1賣方點對點答復

8、附件三：技術建議書包括整個系統(tǒng)總體模塊組成包括網(wǎng)絡、硬件、軟件等、各模塊具體結(jié)構、 配置依據(jù)、各種業(yè)務流程、系統(tǒng)與相關其它系統(tǒng)接口、系統(tǒng)管理、系統(tǒng)平安、統(tǒng) 計等方面附件四：技術文件清單應包含本次提供的技術文件的種類、數(shù)量及簡要內(nèi)容介紹附件五：軟件功能清單附件六：工程實施方案附件七：設備情況、機架狀況及場地環(huán)境要求附件八：合同雙方的責任分工及界面要求圖示并加以說明附件九：驗收及測試附件十：工程協(xié)調(diào)會附件十一：售后效勞附件十二：最終用戶人員培訓附件十三：相關備忘錄及承諾附件十四：產(chǎn)品說明包括相關資質(zhì)及入網(wǎng)許可證1.6技術建議書應包括的內(nèi)容系統(tǒng)概況1Web Cach系統(tǒng)的結(jié)構、系統(tǒng)組成情況以及典型的

9、工作流程。2Web Cach系統(tǒng)與DPI、網(wǎng)管系統(tǒng)的連接方式。3系統(tǒng)過負荷控制機制，即業(yè)務量到達或超過最大硬件處理能力的流控 機制。4系統(tǒng)的License控制機制，即在業(yè)務量超過License容量但未到達系統(tǒng) 最大處理能力系統(tǒng)的處理流程。系統(tǒng)配置1現(xiàn)網(wǎng)各省Web Cach系統(tǒng)使用的效勞器設備的型號配置。(2) 本工程方案使用的效勞器設備的型號配置。(3) 主設備配置的核算方法。系統(tǒng)容量(1) 現(xiàn)網(wǎng)存在的各個版本以及各種硬件配置情況下單臺設備的最大容量和 處理能力。系統(tǒng)容量的定義見第5節(jié)系統(tǒng)容量需求。(2) 本期工程配置設備在各個版本下單臺設備最大的容量和處理能力，并 說明設備容量或處理能力的測

10、試條件、方法和計算方法。(3) Web Cache勺容量需求的核算方法。(4) Web Cach系統(tǒng)的病毒防護以及防止惡意攻擊等平安防護機制。版本情況(1) 現(xiàn)網(wǎng)主設備的版本情況以及分布的省份。(2) Web Cache系統(tǒng)的版本路標。(3) 在各個新版本中提供的新的功能以及導致容量的變化情況。(4) 版本升級需要進行軟、硬件改造、增加的情況。(5) 系統(tǒng)硬件對新版本的支持情況。1.7報價要求1.7.1 總體要求(1) 報價應包括根據(jù)設備完備性要求的所有必須的硬件設備、軟件以及系 統(tǒng)集成所需要的安裝材料、工具、技術文件及安裝調(diào)測、培訓、技術支持等；(2) 報價應包括硬件設備名稱、型號及配置模塊

11、、數(shù)量，軟件模塊、版本、 Licence數(shù)量、相關配置情況，系統(tǒng)集成所需要的相關軟硬件及配套設備和部件等 詳細內(nèi)容；(3) 報價應以人民幣為單位；(4) 報價應按目錄價列清單；(5) 報價應詳細列出提供終驗后一年效勞費用(包括系統(tǒng)維護所需要的軟硬 件費用和技術效勞費用)，以及相應的效勞水平；(6) 報價應詳細列出人員培訓的單價；(7) 賣方在報價中應明確標注采用的第三方軟、硬件。(8) 針對本工程所建系統(tǒng)，在本工程實施后買方針對原需求假設有局部變化、 買方有新的有關標準制定出來或者原有標準進行修改后，對于本工程所建系統(tǒng)已 有同等功能的改良、完善、優(yōu)化等，賣方應免費修改其系統(tǒng)以滿足要求。報價方式

12、1設備以人民幣為單位報價。2報價應報出設備到現(xiàn)場價。3賣方應承諾當所購置設備種類、數(shù)量發(fā)生變化時，所提供的價格折扣 水平、技術效勞等方面的各種優(yōu)惠條件不變。4賣方應承諾在隨后的工程擴容、備件采購中，采購同種設備的價格水 平不高于本次的價格水平。5本技術標準書為保證網(wǎng)絡運行所需的最低要求，如有遺漏，賣方應予 以補充，否那么一旦中標將認為賣方認同遺漏局部并免費提供。6賣方應說明隨著網(wǎng)絡規(guī)模的擴充、用戶數(shù)的增加，其軟硬件擴容方式 及收費標準。7要求賣方應用軟件采用功能模塊配置方法和/或許可證配置方法，其中 功能模塊的功能應與軟件功能清單對應一致，許可證只能與系統(tǒng)處理能力實際 出口帶寬相關聯(lián)，并且在W

13、eb Cache平臺系統(tǒng)實際運行中系統(tǒng)到達該許可證 數(shù)量時不應限制業(yè)務處理而只是向網(wǎng)管系統(tǒng)發(fā)出告警信息，并在系統(tǒng)日志中記 錄，不接受許可證與某種形式的系統(tǒng)靜態(tài)容量例如效勞器數(shù)量、設備數(shù)量相關 聯(lián)的配置方法。報價體系要求請賣方按照以下各項要求分別報價：1報價清單總表中應表達，硬件、軟件、效勞、培訓局部的目錄價，分 類工程小計價格及總價。2硬件清單分別提供效勞器設備清單以及其他硬件局部的清單。效勞器 設備清單包含PC效勞器以及PC終端設備。賣方購置效勞器廠家提供商的效勞應 在效勞器清單中作為單獨條目列出。3軟件清單中賣方應將自產(chǎn)軟件以及外購軟件分別列出。4設備應按類別分別提出詳細的分項單價和總價，

14、對能夠獨立工作或可 以單獨采購的設備和部件及軟件模塊均分別報價，即按不可拆分原那么報價。設備清單要求1設備硬件應細分到板件。(2) 第三方提供的設備應詳細的列出廠家名稱，產(chǎn)品型號、設備配置等內(nèi) 容。(3) 軟件清單應將自產(chǎn)軟件和外購軟件分別列出。2 Web Cache系統(tǒng)建設主要技術要求WebCache系統(tǒng)是在中國移動現(xiàn)有的IP承載網(wǎng)絡中部署的緩存設備，存儲互 聯(lián)網(wǎng)熱點或特定內(nèi)容。通過引導網(wǎng)內(nèi)用戶的訪問請求轉(zhuǎn)發(fā)到WebCache系統(tǒng)中， 由WebCache系統(tǒng)直接將數(shù)據(jù)返回給用戶，防止直接從互聯(lián)網(wǎng)源站下載數(shù)據(jù)，從 而降低客戶訪問互聯(lián)網(wǎng)資源的時延，有效提升用戶訪問速度和質(zhì)量，降低互聯(lián)網(wǎng) 出口擁塞

15、的現(xiàn)狀。從技術上解決由于網(wǎng)絡帶寬小、用戶訪問量大、互聯(lián)網(wǎng)資源分 布不均等原因所造成的用戶訪問互聯(lián)網(wǎng)資源響應速度慢的問題，提升用戶的業(yè)務 感知，同時降低因網(wǎng)間流量產(chǎn)生的網(wǎng)間結(jié)算費用。WebCache系統(tǒng)支持對Web瀏覽、文件下載、視頻播放等基于 協(xié)議的 互聯(lián)網(wǎng)業(yè)務進行加速，系統(tǒng)對于本地存儲的文件格式、音視頻及文件編碼方式均 沒有特定要求，各類互聯(lián)網(wǎng)音頻、視頻、圖像、文本等文件均可通過系統(tǒng)實現(xiàn)緩 存和加速效勞。WebCacheS統(tǒng)應支持移動蜂窩網(wǎng)(2G/3G/ITE)、WLAN、固定寬帶等不同 的網(wǎng)絡接入方式，并能夠同時為PC、 、Pad等不同形態(tài)的終端提供效勞。2.1 Web Cached統(tǒng)請求

16、引導機制2.1.1 DNS重定向模式WebCache系統(tǒng)通過檢測用戶側(cè)發(fā)出的DNS解析請求，如果用戶訪問的站點 域名屬于系統(tǒng)配置的白名單，那么在DNS解析響應消息中向用戶返回WebCache 系統(tǒng)的IP地址，引導用戶的 業(yè)務請求發(fā)送至WebCache系統(tǒng)，由WebCache 系統(tǒng)響應用戶訪問請求。在面向互聯(lián)網(wǎng)網(wǎng)站、web小文件場景進行緩存加速時，建議WebCache系統(tǒng) 優(yōu)先采用DNS重定向模式。對于文件下載、視頻播放類的應用場景，也可選擇采用DNS重定向模式。 但對于以IP地址標識的對象，由于在下載過程前沒有DNS解析流程，故無法通 過DNS重定向模式進行處理。DNS重定向模式下，WebCa

17、che系統(tǒng)可通過如下兩種方式獲取用戶發(fā)起的 DNS解析請求，在實際部署中建議根據(jù)網(wǎng)絡部署情況選擇使用。(1) 分光鏡像方式分光鏡像方式要求在需監(jiān)測的鏈路上部署無源分光設備，將鏈路中的信號通 過分光處理后發(fā)送至WebCache系統(tǒng)的DPI功能中。DPI功能中應根據(jù)需要配置過濾流量的條件，如DNS協(xié)議類型、端口號等， 將滿足條件的用戶請求轉(zhuǎn)發(fā)送至后端的請求重定向功能模塊。在DPI功能中不開啟流量過濾功能時，DPI功能會將全量的上行請求均發(fā)送 至WebCache系統(tǒng)。此時由WebCache系統(tǒng)需根據(jù)本地配置的域名白名單進行匹 配，如滿足一致性條件，再向用戶返回對應的重定向響應消息。由于分光鏡像模式需

18、要在源網(wǎng)站的授權DNS返回響應結(jié)果之前對用戶進行 重定向，故要求重定向子系統(tǒng)發(fā)送重定向報文應當滿足時延要求。(2) DNS轉(zhuǎn)發(fā)方式DNS轉(zhuǎn)發(fā)模式要求將省內(nèi)的Local DNS與WebCache系統(tǒng)相連接。由管理員 在Local DNS上開啟Forward功能，并在轉(zhuǎn)發(fā)策略中將需要加速的域名列表(白 名單)配置為Forward Firs模式，目標為WebCache系統(tǒng)的調(diào)度效勞器的IP地址。 Forward First模式下DNS效勞器會優(yōu)先選擇轉(zhuǎn)發(fā)的目標DNS返回的解析結(jié)果， 當Forward目標因故無法返回結(jié)果或返回結(jié)果延遲較大，Local DNS本身那么會繼 續(xù)遞歸解析以獲取解析結(jié)果。當用

19、戶終端發(fā)起的DNS解析請求發(fā)送至Local DNS效勞器后，DNS效勞器 將目標域名與本地配置的Forward名單進行匹配，如滿足一致性條件，那么將該條 DNS解析請求前傳至WebCache系統(tǒng)的請求調(diào)度功能模塊。WebCache系統(tǒng)的請求調(diào)度功能模塊在接收到該條DNS解析請求后，應向 Local DNS返回對應的DNS解析響應消息，解析結(jié)果的目標地址為緩存子系統(tǒng)的 IP地址。2.1.2 重定向模式 重定向模式包含非代理方式和代理方式兩種處理機制：非代理處理機制：僅當WebCache系統(tǒng)監(jiān)測到用戶發(fā)出的 訪問請 求屬于本地已緩存的資源，才由WebCache系統(tǒng)向用戶返回 302 重定向報文，響

20、應報文的目標地址為WebCache系統(tǒng)的IP地址，用戶終 端接收到該條 302響應消息后，將向WebCache系統(tǒng)發(fā)起請求下載 數(shù)據(jù)。代理處理機制： 重定向模式也支持工作于代理模式，對于滿足域 名匹配條件的請求均引導至緩存子系統(tǒng)，如已緩存那么直接向用戶提供服 務；如該內(nèi)容在本地未緩存時，那么由WebCahe系統(tǒng)作為代理向外網(wǎng)下載 并傳送給用戶側(cè)。在面向大文件下載、視頻播放類的場景進行緩存加速時，建議WebCache系 統(tǒng)優(yōu)先采用 重定向模式及非代理處理機制。 重定向機制下，WebCache系統(tǒng)應采用分光鏡像方式獲取用戶發(fā)起的 請求。通過在需監(jiān)測的鏈路上部署無源分光設備，將鏈路中的信號通過分 光

21、處理后發(fā)送至WebCache系統(tǒng)的DPI功能中。DPI功能中應根據(jù)需要配置過濾 流量的條件，如 協(xié)議類型、端口號80/8080、關注域名或IP地址列表等 維度，將滿足一致性要求的 請求轉(zhuǎn)發(fā)送至后端的請求重定向功能模塊。由于分光鏡像模式需要在源網(wǎng)站返回響應結(jié)果之前對用戶進行重定向，故要 求重定向子系統(tǒng)發(fā)送重定向報文應當滿足時延要求。特定場景下，也可以通過端口鏡像方式獲取用戶請求。端口鏡像模式主要面 向網(wǎng)絡流量較小的場景，通過在路由器或交換機上開啟端口鏡像功能，將所有流 量均通特定端口轉(zhuǎn)發(fā)至WebCacheS統(tǒng)，并由DPI設備過濾出所需的 流量。 端口鏡像方式可進行全流量進行，也可以依據(jù)可以是端口

22、號、目標地址、源地址 等進行鏡像。策略路由引導模式策略路由模式主要應用于省網(wǎng)內(nèi)部署的WebCache系統(tǒng)，通過在核心路由器 上開啟策略路由PBR功能，將滿足條件的用戶流量通過路由轉(zhuǎn)發(fā)至WebCache 系統(tǒng)，判斷依據(jù)可以是端口號、目標地址、源地址等，后續(xù)相關的上行、下行流 量均會經(jīng)由WebCache系統(tǒng)進行處理，而無需向終端側(cè)發(fā)送重定向報文。對于用戶請求，如果WebCache系統(tǒng)本地命中，那么直接向用戶返回數(shù)據(jù)；女口 果本地未命中，那么由WebCache系統(tǒng)代理用戶向源網(wǎng)站請求數(shù)據(jù)，并返回給用戶。 對于熱點內(nèi)容，由WebCache系統(tǒng)在本地存儲一份副本。對于思科路由器，也可以通過其專用的WCC

23、P協(xié)議進行流量轉(zhuǎn)發(fā)。策略路由引導模式下，當網(wǎng)絡中斷時，路由器應能夠自動調(diào)整為直通模式， 防止可能出現(xiàn)的訪問故障。策略路由引導模式下，也可以采用發(fā)布BGP路由的方式將需加速的流量從核 心路由器會聚轉(zhuǎn)發(fā)到WebCach系統(tǒng)專用的路由器，然后再在該臺路由器上面配 置PBR策略進行流量引導。2.2 Web Cach系統(tǒng)建設功能要求重定向子系統(tǒng)深度報文解析模塊DPI設備通過串行或者旁路分光方式部署在網(wǎng)絡會聚節(jié)點，采集并分析業(yè)務 原始網(wǎng)絡數(shù)據(jù)流量及用戶請求，將對應的用戶流量轉(zhuǎn)發(fā)至系統(tǒng)后端，為WebCache 系統(tǒng)實施用戶請求重定向提供根底數(shù)據(jù)支持。在WebCach系統(tǒng)采用DNS轉(zhuǎn)發(fā)模式、策略路由引導模式時

24、，由于WebCache 系統(tǒng)能夠直接從DNS效勞器獲得對應的DNS請求解析流量，從路由器直接獲取 到對應的用戶 流量，此時WebCache系統(tǒng)中也可不部署DPI設備，或由其 他設備兼作。1. 流量分析功能DPI設備必須支持基于L3/L4信息、基于L7應用層特征如應用層協(xié)議特 征碼對數(shù)據(jù)流量進行分析和識別。DPI設備必須支持 、DNS協(xié)議。2. 流量轉(zhuǎn)發(fā)功能DPI設備支持流量轉(zhuǎn)發(fā)功能，具體要求如下：支持對于滿足設定規(guī)那么匹配條件的報文進行處理，將滿足匹配條件的報 文從指定接口轉(zhuǎn)發(fā)到用戶請求調(diào)度設備，例如DNS解析請求報文、 訪問請求報文等；支持靈活配置過濾轉(zhuǎn)發(fā)規(guī)那么，規(guī)那么可以是指定協(xié)議類型、I

25、P地址、端口 號、流量方向、應用層特征等組合方式；支持無效流量的靈活過濾，支持靈活按照協(xié)議類型、應用層特征、源/目 的IP地址、流量方向等作為過濾條件，能夠鏡像出高比例收斂的有效流 量；支持配置多個出接口組，能夠根據(jù)負載均衡策略實施轉(zhuǎn)發(fā)；3. 流量統(tǒng)計功能DPI設備提供支持的流量統(tǒng)計功能如下： 支持多種流量統(tǒng)計，如對字節(jié)數(shù)、當前帶寬、峰值流量、新增連接數(shù)、最大并發(fā)連接數(shù)、當前并發(fā)連接數(shù)等網(wǎng)絡流量參數(shù)進行統(tǒng)計；支持輸出外部網(wǎng)站及域名的請求次數(shù)、流量統(tǒng)計及排名次序等統(tǒng)計數(shù)據(jù)； 支持通過手動或自動方式上報至其他外部系統(tǒng)，例如WebCache系統(tǒng)或 全網(wǎng)管理控制中心；用戶請求調(diào)度模塊用戶請求調(diào)度設備的

26、主要功能是根據(jù)緩存白名單配置或者本地已緩存內(nèi)容， 將用戶的訪問請求重定向至后端的緩存子系統(tǒng)。1. DNS重定向功能用戶請求調(diào)度設備處理接收到用戶終端發(fā)出的 DNS解析請求報文，根據(jù) WebCach系統(tǒng)效勞器狀態(tài)和配置參數(shù)，生成相應的DNS響應消息。用戶請求調(diào)度設備必須支持對DNS請求的源IP地址進行判斷：如果是WebCache系統(tǒng)發(fā)送的請求那么不實施處理，該請求將被透傳至外 網(wǎng)上一級DNS效勞器進行處理。對于源IP地址為用戶側(cè)的DNS請求報文，如果WebCach系統(tǒng)運行正常, 那么將WebCach系統(tǒng)的IP地址作為DNS解析響應結(jié)果發(fā)送給用戶終端。 支持對特定源IP地址的調(diào)度Bypasi功能，

27、對滿足源地址匹配條件的DNS 請求不進行重定向，不對這局部用戶進行緩存加速。源IP地址段必須可 靈活配置。2. 重定向功能用戶請求調(diào)度設備處理接收到用戶終端發(fā)出的 請求報文，并根據(jù) WebCach系統(tǒng)效勞器狀態(tài)、本地緩存數(shù)據(jù)以及IP地址配置參數(shù)等，生成對應的 302重定向消息，其中目標為緩存子系統(tǒng)的公網(wǎng)IP地址。在緩存子系統(tǒng)中沒有部署負載均衡設備的場景下，用戶請求調(diào)度設備必須能 夠?qū)崟r獲取緩存子系統(tǒng)中已緩存的內(nèi)容資源信息，對用戶的 請求進行綜合 判斷，根據(jù)資源分布、設備負載以及內(nèi)容策略等信息將用戶的請求制定路由導向 策略，將用戶請求重定向至最適宜的緩存效勞器上。如果用戶請求調(diào)度設備監(jiān)測到Web

28、Cache緩存子系統(tǒng)不可用，那么不對用戶的 請求作出重定向操作。支持對特定源IP地址的調(diào)度Bypass功能，對滿足源IP地址匹配條件的 請求不進行重定向，不對這局部用戶進行緩存加速。源IP地址段必須可靈活配置。3. 黑白名單功能WebCache系統(tǒng)支持配置加速域名列表白名單，僅對于白名單內(nèi)的網(wǎng)站域 名進行加速，對于其他請求不進行響應，也可返回DNS遞歸解析結(jié)果以保護用 戶DNS請求的成功性。WebCache系統(tǒng)支持配置黑名單，包含非 協(xié)議的域名和不適合進行緩 存加速的域名，如郵箱域名、FTP域名、SSL域名等。黑白名單域名信息配置必須支持如下2類方式：精確域名：如tuanjd 泛域名：女口 *

29、.sports.si na , . news.163 可支持正那么匹配域名配置方式：如dl1-9.qq ww*.sohu 對于黑白名單中配置的域名，用戶請求調(diào)度設備僅對在白名單內(nèi)、且不在黑 名單內(nèi)的訪問請求進行響應。當系統(tǒng)配置的白名單與黑名單存在交疊時，必須優(yōu)先使用匹配黑名單的策略 生效。支持黑白名單的管理功能，支持手工增刪改查。4. 健康檢查功能用戶請求調(diào)度設備支持通過多種方式監(jiān)測緩存子系統(tǒng)的可用性及工作狀態(tài)， 能夠根據(jù)緩存子系統(tǒng)的可用性及存儲的文件內(nèi)容進行調(diào)度?？捎眯灾辽賾ㄈ?下方面：設備可達：設備硬件層面是否可用，例如可發(fā)送ICMP報文實施探測； 效勞狀態(tài)：檢查TCP/UDP端口是否

30、提供效勞；負載情況：接收并監(jiān)測Cache效勞器上報的設備狀態(tài)負載信息，如CPU、 內(nèi)存、硬盤空間使用率等預先協(xié)商的數(shù)據(jù)項可選；用戶請求調(diào)度設備的負載監(jiān)測功能可通過SNMP協(xié)議實現(xiàn)，對WebCache服 務器設備層面的監(jiān)控項實施數(shù)據(jù)采集，此時緩存效勞器中需要安裝SNMP Age nt 效勞。用戶請求調(diào)度設備根據(jù)設定的時間周期性探測對端設備的健康狀態(tài)。如果在 采集周期內(nèi)緩存子系統(tǒng)出現(xiàn)不可用的狀態(tài)，用戶請求調(diào)度設備將繼續(xù)探測以確認 設備不可用，最多進行3次累計探測或探測累計時間在超時范圍內(nèi)，那么判定系統(tǒng)不可用。請求調(diào)度模塊能夠根據(jù)緩存子系統(tǒng)的可用性進行調(diào)度，具體要求如下： 緩存子系統(tǒng)單個文件損壞時，

31、請求調(diào)度模塊應自動停止對應損壞文件的 重定向；緩存子系統(tǒng)數(shù)據(jù)硬盤出現(xiàn)故障時，請求調(diào)度模塊應自動停止對應故障磁 盤緩存文件的重定向；緩存子系統(tǒng)不可用時，請求調(diào)度模塊應不對用戶請求作出響應。緩存子系統(tǒng)負載過重時，請求調(diào)度模塊應自動識別，并降低向緩存子系 統(tǒng)的重定向用戶請求；用戶請求調(diào)度設備可支持通過 方式對其它WebCache點的可用性進 行周期性檢查。5. 主備冗余功能用戶請求調(diào)度設備需具備冗余切換能力，兩臺設備之間使用網(wǎng)線傳遞心跳信 號、主備切換觸發(fā)信號，以監(jiān)控對端設備的狀態(tài)。6. 策略同步功能支持與管理子系統(tǒng)交互，獲取本地緩存內(nèi)容情況、以及由全網(wǎng)管控中心、內(nèi) 容資源管理平臺或者其他外部網(wǎng)元實

32、體下發(fā)的各類資源信息、內(nèi)容信息以及調(diào)度 策略數(shù)據(jù)，并在本地配置生效。緩存子系統(tǒng)負載均衡模塊1. 健康檢查功能負載均衡設備必須支持對Cache效勞器資源的健康檢查，常用的健康檢查機 制如下表所示。系統(tǒng)的可用性至少應包括：設備可達：設備硬件層面是否可用，可基于發(fā)送ICMP報文實施探測； 效勞狀態(tài)：檢查TCP/UDP端口是否提供效勞；負載情況：接收并監(jiān)測Cache效勞器上報的設備狀態(tài)負載信息，如CPU 利用率、內(nèi)存利用率、存儲資源、EBI、EBO、CC或其它預先協(xié)商的監(jiān) 控數(shù)據(jù)項；此時Cache月艮務器組中需要部署SNMP Age nt效勞或其它資 源插件來支持數(shù)據(jù)獲取。當判定緩存效勞器不可用時，負

33、載均衡設備需將該效勞器從WebCach由艮務 隊列中取出，不參加下一次的分發(fā)，直到該設備恢復正常。2. 負載均衡功能支持將用戶請求和In ternet網(wǎng)絡流量按照配置的負載分擔算法分發(fā)到不同的 Cache效勞器進行處理。當用戶請求到達緩存子系統(tǒng)時，負載均衡功能根椐配置 策略，選擇特定的緩存效勞器，由該臺Cache月艮務器響應用戶的請求、提供緩存 效勞，例如選擇性能最正確的緩存效勞器，存儲該份內(nèi)容的緩存效勞器等。支持會話保持功能，對于同一用戶、同一會話的多個訪問請求，可分配至同 一臺緩存效勞器中，防止出現(xiàn)會話失效的問題。支持基于L4和L7的流量分發(fā)機制。負載均衡模塊必須支持配置多個VIP地 址。

34、支持對IPv6協(xié)議報文的負載均衡功能，能夠?qū)Pv6報文實現(xiàn)接收、解析和 分發(fā)處理。支持根據(jù)使用的分發(fā)機制來決定選擇監(jiān)控的數(shù)據(jù)項，監(jiān)控數(shù)據(jù)項的采集周期可靈活配置。支持的流量分發(fā)機制如表所示序號均衡算法詳細描述是否必須1輪詢(Rou ndRobin)負載均衡設備將所有用戶請求按照Cache資源 池的隊列順序，分發(fā)給資源池內(nèi)每臺Cache效勞 器進行處理，依次循環(huán)。必選2L4負載分擔按照用戶請求的4層信息，如IP地址、端口等對 數(shù)據(jù)流進行分配。必選3L7負載分擔按照用戶請求的7層信息對數(shù)據(jù)流進行分配，例 如根據(jù)目的URL映射至特定的Cache效勞器 中。必選4動態(tài)性能分配(Dyn amicRati

35、o)根據(jù)收集到應用程序和Cache效勞器的各項性 能參數(shù)如CPU、內(nèi)存和磁盤的占用情況，動態(tài) 調(diào)整流量分配。動態(tài)性能分配可通過標準 SNMP或Cache!效勞器端的插件實現(xiàn)。可選5最快模式(Fastes)將新的用戶請求分發(fā)給響應最快的Cache效勞 器。可選6最少連接方式(LeastC onn ecti on)將新的用戶請求分發(fā)給最少連接的Cache效勞 器。可選7優(yōu)先權Priority負載均衡設備將所有Cachd效勞器進行分組，為 每個組定義優(yōu)先權，將用戶請求分配給優(yōu)先級 最高的Cach效勞器組在同一組內(nèi)，采用輪詢 或比率算法，分配用戶請求。當最高優(yōu)先級中所有Cachd效勞器出現(xiàn)故障，才 將

36、請求送給次優(yōu)先級的Cache效勞器組。為用戶 提供Cache效勞器組的熱備份功能?？蛇x其中L7負載分擔功能中要求至少支持如下兩類方式：Hash：負載均衡設備同一文件的Hash結(jié)果，把相同的HASH文件用戶 請求分發(fā)到每臺Cache效勞器；一致性Hash對請求內(nèi)容和緩存效勞器使用相同的Hash函數(shù)，并將資 源和地址節(jié)點在統(tǒng)一地址空間進行編址，從數(shù)據(jù)映射到的位置開始順時 針查找，將請求轉(zhuǎn)發(fā)至找到的第一個效勞器；3. 主備冗余功能負載均衡模塊應具備多臺設備的冗余能力，不同設備之間應當具有心跳監(jiān)控 及切換能力，監(jiān)控對端負載均衡設備的狀態(tài)。主用負載均衡設備將心跳信號定時 發(fā)送到備用負載均衡設備,備用設備

37、在一定周期內(nèi)沒有收到主用設備的心跳信號， 支持主動將自己切換為主用設備。2.222負載均衡模塊緩存效勞效勞模塊是整個WebCache系統(tǒng)的核心組件。1. 網(wǎng)頁對象緩存功能支持對于互聯(lián)網(wǎng)站點頁面的解析，能夠?qū)⒕W(wǎng)頁中的靜態(tài)Web對象存儲于本地 的緩存效勞器中。在接收到用戶發(fā)送的Web訪問請求時，分析請求是否在本地命 中，對于命中請求直接響應，就近為用戶提供效勞；對未命中的請求，系統(tǒng)能夠 從互聯(lián)網(wǎng)源站下載內(nèi)容，并就近返回給用戶終端。緩存的網(wǎng)頁對象類型包括但不限于：文本：HTML、XML、XHTML、JS CSS DOC、PDF、TXT 等; 圖像：JPG PNG、GIF 等；視頻：FLV、MP4、M

38、OV、WMV、RMVB、F4V等；音頻：MP3、WAV等； 其他：ZIP、RAR等；支持 /1.0 /1.1協(xié)議定義的緩存字段：支持根據(jù)Expires頭域?qū)撁鎸ο蟮目删彺嫘赃M行判斷，在Expire Date 到達之前不再向源站發(fā)送 請求獲取該文件；支持根據(jù)Cache-Contrc頭域?qū)撁鎸ο蟮目删彺嫘赃M行判斷，對于設置 為public的內(nèi)容進行緩存，對于設置為private no-cache no-store等的 對象，默認不進行緩存，支持根據(jù)max-age參數(shù)所指定的相對時間間隔 進行數(shù)據(jù)緩存；對于源網(wǎng)站中在 頭域中指明不應被緩存的內(nèi)容，要求緩存效勞模塊工 作于代理模式，所有數(shù)據(jù)不在本地

39、緩存。對于互聯(lián)網(wǎng)中的動態(tài)內(nèi)容，要求系統(tǒng)能夠予以識別，不在本地緩存，對于所 有用戶的請求，均以代理方式向源網(wǎng)站下載數(shù)據(jù)并傳送給用戶。支持針對特定網(wǎng)站或域名實現(xiàn)靜態(tài)對象的緩存周期配置，用戶可以通過修改 配置來設定本地緩存時間和緩存對象的類型。在本地設置與源站設置沖突時，優(yōu) 先以本地設定為準。2. 大文件/視頻緩存功能支持基于 協(xié)議傳輸?shù)拇笪募彺婕铀俟δ?，如游戲、軟件、升級包?載效勞等。緩存效勞模塊接收用戶的文件下載請求，分析該內(nèi)容是否已經(jīng)被 WebCache系統(tǒng)在本地緩存，對于已緩存的內(nèi)容，將通過重定向引導用戶從緩存 效勞器下載數(shù)據(jù)。工作于代理模式時，對于被引導至緩存效勞器，但本地未命中的請求

40、，要求 系統(tǒng)能夠以代理方式向內(nèi)容源站下載后，將對應的數(shù)據(jù)發(fā)送至用戶終端。支持 視頻內(nèi)容的緩存和下載，主要針對基于 方式的各類在線視 頻媒體對象，包括FLV、MP4、MOV、WMV、RMVB、F4V等多種文件格式， 設備應該支持對流媒體對象的緩存配置。支持基于 Live Streamin©HLS協(xié)議的互聯(lián)網(wǎng)視頻內(nèi)容的緩存和加速。 支持面向 終端的各類應用軟件APP內(nèi)容的下載與加速功能。3. 代理下載功能在用戶請求被引導到緩存子系統(tǒng)后，緩存子系統(tǒng)首先檢查用戶請求的文件是 否在本地命中，如果命中那么直接為用戶提供效勞；如果未命中，緩存子系統(tǒng)將作 為代理轉(zhuǎn)發(fā)用戶的請求至互聯(lián)網(wǎng)源網(wǎng)站，并將源網(wǎng)

41、站返回的數(shù)據(jù)轉(zhuǎn)發(fā)給用戶。如 果源網(wǎng)站返回的是有效數(shù)據(jù)且可緩存，緩存效勞器根據(jù)熱度規(guī)那么，在本地同時存 儲熱點內(nèi)容的文件副本。對于大文件和視頻播放等應用場景，需能夠支持邊下載邊效勞功能，防止將 用戶請求長時間置于等待狀態(tài)。代理下載功能必須根據(jù)實際的網(wǎng)站列表選擇開啟，對于可能存在認證失敗、 cookie校驗等問題的網(wǎng)站，要求不開啟。4. URL防盜鏈功能針對主流的文件下載、視頻播放、網(wǎng)絡存儲類網(wǎng)站的URL文件防盜鏈功能, 支持對加密后的URL進行反向處理，獲取真實的文件對象URL。支持網(wǎng)站URL規(guī)那么庫，可以識別并兼容國內(nèi)絕大多數(shù)視頻及下載網(wǎng)站。可 根據(jù)互聯(lián)網(wǎng)站的功能及版本升級，支持通過加載新的規(guī)

42、那么庫插件即可實現(xiàn)對新規(guī) 那么的反向處理，支持自動遠程升級。支持校驗排錯功能，能夠?qū)σ丫彺娴南螺d類資源對象進行驗證，例如通過對 進行文件HASH運算，讀取資源局部頭信息或散列信息等方式，以防止內(nèi)容資源 定位錯誤，影響用戶的正常訪問。5. 持久連接功能支持基于 /1.1的持久連接PersistentConnection，能夠針對同一對象 的多個用戶請求只建立一條連接。當多個用戶請求相同的網(wǎng)頁對象時，緩存效勞 器僅與源網(wǎng)站效勞器建立一條連接，以便防止為每次單獨的請求/應答建立新的連 接。得到響應報文后，WebCache系統(tǒng)將響應內(nèi)容的副本保存在本地，同時復制 報文分發(fā)給發(fā)起請求各個用戶。通過使用同

43、一 連接的方式以解決頻繁建立 連接帶來的時間消耗，縮短響應時間提升用戶體驗，有效減少終端與效勞器建立 的連接數(shù)。6. 內(nèi)容復制功能對于用戶從Cache系統(tǒng)下載的TOP N熱點資源，緩存效勞器支持自動檢測如 可按照命中次數(shù)排序，能夠根據(jù)熱度在本地不同緩存效勞器之間進行復制，使得 熱點內(nèi)容可以由多個緩存效勞器并行提供加速效勞，支撐高性能并發(fā)。復制時間周期、復制的熱點資源數(shù)量應支持靈活配置，默認時間周期為一天。7. 數(shù)據(jù)復用功能針對不同URL但文件內(nèi)容相同的互聯(lián)網(wǎng)文件，Cache效勞器能夠通過文件比 對或依據(jù)站點的防盜鏈處理規(guī)那么處理后實施甄別比對，識別出相同的文件對象， 實現(xiàn)緩存數(shù)據(jù)復用，僅緩存初

44、始URL所對應的數(shù)據(jù)，對于向其他URL發(fā)起的文 件請求也可以保持命中。通過重用初始緩存文件的數(shù)據(jù)，能夠提升訪問命中率， 節(jié)省系統(tǒng)回源流量，也防止針對同一對象重復下載，減少對于本地存儲空間的占 用。對于不同URL、但內(nèi)容一致的文件內(nèi)容，必須支持通過URL規(guī)那么、文件名 稱、大小進行關聯(lián)，如：URL1: :/jsmcc2.newhua /down/ppstreamsetup_onlinedown.zip URL2： :/qzmcc.newhua /down/ppstreamsetup_onlinedown.zip URL3： 系統(tǒng)也可支持通過對文件內(nèi)容計算Hash值的方式進行有效關聯(lián)。通過該算 法

45、生成與文件內(nèi)容相對應的摘要數(shù)值，通過該摘要信息可以唯一標識某一文件。8. 內(nèi)容熱度更新功能內(nèi)容熱度更新是指在緩存效勞器的存儲空間占用到達一定程度時，必須刪除 掉一些不常用的緩存數(shù)據(jù)。對于每個對象，緩存效勞器根據(jù)其訪問頻率計算相應 的熱度值，訪問頻率越高那么其熱度值也越高，熱度值較低的緩存對象將會被優(yōu)先 刪除。對于相同熱度值的對象，可以比擬對象的超時周期，優(yōu)先刪除超時周期指 標較低的數(shù)據(jù)對象。內(nèi)容熱度更新算法的核心是輸入?yún)?shù)及權值函數(shù)，緩存對象在某時間點的熱 度值可根據(jù)如下輸入?yún)?shù)計算：上次數(shù)據(jù)熱度值計算時間特定時間段內(nèi)數(shù)據(jù)訪問次數(shù)數(shù)據(jù)對象上一次的熱度值文件大小緩存對象的老化時間的設定需要參考網(wǎng)

46、頁 頭域中的超期參數(shù)，當超期 時間到達時內(nèi)容也會被自動刪除。當源網(wǎng)站沒有指定超期參數(shù)或錯誤參數(shù)時，可 以根據(jù)WebCacheS統(tǒng)配置進行更新，支持對不同域名、不同類型的對象獨立設定老化時間。9. 內(nèi)容預取功能支持自動預取互聯(lián)網(wǎng)內(nèi)容的功能，對于熱點內(nèi)容，支持根據(jù)源網(wǎng)站在 頭域中確定內(nèi)容的超期時間，或者WebCache系統(tǒng)本地強制配置的更新周期，可 實現(xiàn)在用戶發(fā)起請求之前提前將網(wǎng)頁內(nèi)容或文件更新為最近的版本。預取數(shù)據(jù)后 WebCach系統(tǒng)將重新刷新對象的超期時間。內(nèi)容預取功能可以有效降低用戶請求到達后，緩存效勞器進行校驗和回源下 載的時間，提升用戶的訪問體驗。內(nèi)容預取功能默認不開啟，可根據(jù)需求對特

47、定網(wǎng)站開啟，預取周期可按照網(wǎng) 站域名為維度進行靈活配置。10. 超期校驗功能支持 /1.1協(xié)議的If-Modified機制。在Cache系統(tǒng)緩存內(nèi)容已經(jīng)過期時， 緩存效勞器支持向源網(wǎng)站發(fā)送If-Modified-Since頭信息，包含上一次從效勞器獲 取數(shù)據(jù)的產(chǎn)生時間。如果文件從上次獲取后沒有更新，源站效勞器將返回 狀態(tài)代碼304 Not Modified，表示從上一次請求后這個數(shù)據(jù)沒有改變，此時緩存 效勞器可以直接使用原有緩存數(shù)據(jù)，無需再次下載。支持 /1.1協(xié)議的Etag校驗機制。對于源效勞器生成的唯一標志符Etag 的文件，緩存效勞器可以進行校驗，由緩存效勞器在請求消息的If-No ne

48、-Match 字段中上報ETag如果文件沒有改變，源效勞器將返回304狀態(tài)代碼，告知系 統(tǒng)無需再次請求下載數(shù)據(jù)。此時緩存效勞器可以直接使用原有緩存數(shù)據(jù)，無需再 次下載。11. 本地DNS功能對于用戶發(fā)起的訪問請求，當WebCacheS統(tǒng)未命中時，緩存效勞器可以通 過查詢本地DNS、或使用系統(tǒng)內(nèi)置的DNS功能實現(xiàn)面向互聯(lián)網(wǎng)網(wǎng)站的域名解析 功能。本地DNS可以有效減少WebCach系統(tǒng)對外的大量DNS解析請求，提高DNS 響應速度，也可以防止向內(nèi)網(wǎng)DNS效勞器查詢時產(chǎn)生的DNS環(huán)路。對于WebCache系統(tǒng)發(fā)起的DNS解析請求，應當通過IP地址配置防止被系 統(tǒng)再次攔截。12. 回源管理功能對于特定

49、域名或網(wǎng)站的內(nèi)容，應能夠通過配置采用分時段錯峰回源機制，例 如針對特定網(wǎng)站集中在凌晨1點至6點時段進行更新。支持對回源帶寬進行限制。支持根據(jù)網(wǎng)絡條件選擇不同的鏈路進行回源，如CMNET網(wǎng)間出口、省內(nèi)第 三方鏈路等。對于存在的多條回源鏈路，支持根據(jù)訪問質(zhì)量等因素進行配置，可 支持動態(tài)調(diào)整。系統(tǒng)支持通過人工方式對WebCache系統(tǒng)中已緩存的資源內(nèi)容進行管理，支 持對特定文件對象進行手工刪除。支持按照URL、文件類型、文件大小作為參數(shù) 進行篩選。支持根據(jù)內(nèi)容視圖的分布，向其他WebCache系統(tǒng)進行回源下載數(shù)據(jù)。13. 對象策略功能支持多個維度的對象緩存策略管理功能，通過ACL訪問列表，支持對訪問

50、 請求進行控制。系統(tǒng)管理員可以嚴格、清晰地定義緩存效勞器的訪問控制策略， 不同策略能夠靈活組合使用。文件大小策略：可以設置緩存資源大小范圍，對于超出范圍的文件不提 供緩存效勞，例如配置為100KB20G;文件類型策略：可以設置緩存文件類型，管理員可以通過修改配置到達 不同類型文件是否緩存的目的，對于非許可格式的文件不進行緩存。14. 用戶訪問控制功能系統(tǒng)能夠配置Client Pool限制用戶終端的IP地址，從而有效區(qū)分內(nèi)外網(wǎng)用 戶及域內(nèi)用戶，以保證緩存系統(tǒng)平安及實現(xiàn)對用戶接入的嚴格管理。系統(tǒng)支持只 對中國移動網(wǎng)內(nèi)用戶進行緩存加速效勞，并配置對不同省份的網(wǎng)內(nèi)用戶的訪問權 限，對于不屬于效勞IP地

51、址范圍的用戶要求默認限制其訪問。在分級分域部署方式下，一級Cache節(jié)點為所有中國移動用戶提供緩存加速 效勞，二級Cache節(jié)點默認為所屬區(qū)域內(nèi)的本地用戶提供效勞，也可開啟對網(wǎng)內(nèi) 其他地域用戶的訪問支撐功能。系統(tǒng)允許根據(jù)IP地址設置優(yōu)先緩存的效勞用戶，支持用戶帶寬策略設定，可 根據(jù)用戶類型設置不同的帶寬分配、流量控制策略。系統(tǒng)支持批量從外部導入IP地址段功能。15. IPv6協(xié)議支持功能必須支持IPv4/IPv6雙協(xié)議棧，能夠?qū)ν馓峁㊣Pv4地址和IPv6地址。支持接 收、解析和發(fā)送IPv6報文，支持對于IPv6固定報頭和擴展報頭的處理。支持與IPv6用戶終端及網(wǎng)站的數(shù)據(jù)傳輸。對于IPv6終端

52、發(fā)出的IPv6業(yè)務請 求，緩存子系統(tǒng)能夠根據(jù)對應的協(xié)議向用戶終端發(fā)送對應的互聯(lián)網(wǎng)內(nèi)容。對于解 析為IPv6地址的網(wǎng)站，應能通過IPv6方式向網(wǎng)站請求內(nèi)容。對于源網(wǎng)站為IPv4/IPv6雙棧的場景，要求可根據(jù)配置實現(xiàn)優(yōu)選IPv6協(xié)議、 或者IPv4協(xié)議。管理子系統(tǒng)管理子系統(tǒng)是WebCache系統(tǒng)的本地管理組件，應基于雙機主從方式提供服 務，對業(yè)務管理員提供統(tǒng)一的WWW Protal配置界面，用于對WebCache系統(tǒng)和 各設備進行管理，支持統(tǒng)計流量分布情況，可以統(tǒng)計Cache子系統(tǒng)的緩存效率以 及各個效勞器的系統(tǒng)狀況，從而有效地管理系統(tǒng)，形成相應的業(yè)務報表，為運營 商提供決策依據(jù)；可以根據(jù)需求靈

53、活擴充功能。支持向WebCache系統(tǒng)的運營人 員提供分級管理權限。配置管理功能組織網(wǎng)內(nèi)運營所需要的資源和數(shù)據(jù)，支持保存WebCache系統(tǒng)的根本配置以 及與功能相關的核心數(shù)據(jù)，主要包括：代理模式配置網(wǎng)絡參數(shù)配置訪問控制配置內(nèi)容過濾配置回源路由配置內(nèi)容類型配置支持組織網(wǎng)內(nèi)運轉(zhuǎn)所需要的資源和數(shù)據(jù)，保證網(wǎng)絡的根本配置，支持按照具 體情況改變配置，設置系統(tǒng)參數(shù)，收集并存儲各參數(shù)，報告與根本配置值的偏差, 起動和關閉資源等。223.2狀態(tài)監(jiān)控功能對重定向子系統(tǒng)、緩存子系統(tǒng)等所在效勞器提供全面監(jiān)控，實時監(jiān)測各業(yè)務 系統(tǒng)的資源使用情況和健康狀態(tài)。，保障業(yè)務系統(tǒng)能處在正常運行環(huán)境。支持對系 統(tǒng)總體運行情況進

54、行監(jiān)測，包括CPU利用率、內(nèi)存利用率、存儲量大小、存儲利 用率、回源峰值/均值流量大小、效勞峰值/均值流量大小等信息。支持對系統(tǒng)使用的數(shù)據(jù)庫進行全面的監(jiān)控，實時監(jiān)測數(shù)據(jù)庫的活動情況和健 康狀態(tài)，鑒別和消除瓶頸以提高數(shù)據(jù)庫系統(tǒng)的整體性能。支持監(jiān)控緩存子系統(tǒng)訪問情況，包括訪問用戶、開始時間、結(jié)束時間、內(nèi)容 類型、內(nèi)容編號、內(nèi)容信息、是否命中、效勞節(jié)點、效勞流量等信息。223.3性能管理功能支持對本系統(tǒng)中的性能指標進行評定，如吞吐量Throughput、設備負載、 命中率、效勞質(zhì)量QoS Quality of Servk、時延情況等。測量需要連續(xù)進行， 在異?；蛐阅軔夯闆r下能夠及時通知有關管理人員

55、。2.234報表管理功能平臺支持對WebCacheS統(tǒng)的運行情況及用戶使用情況進行記錄、統(tǒng)計和分 析，能夠自動生成日報、周報、月報等常規(guī)報表和各種個性化報表，支持分析數(shù) 據(jù)并通過曲線圖、餅圖、柱狀圖等各種圖形進行展現(xiàn)。支持查詢、導出功能。通 過該平臺，運營商管理員能夠?qū)Ξ斍暗男谇闆r進行監(jiān)測、處理、查詢等功能。 能夠形象真實的分析整個互聯(lián)網(wǎng)緩存系統(tǒng)的運營狀況，滿足管理的需要，分析用 戶訪問行為，實現(xiàn)流量可視化，為業(yè)務開展提供決策依據(jù)。管理子系統(tǒng)需提供如下根本統(tǒng)計功能：熱點內(nèi)容統(tǒng)計：分析用戶下載的內(nèi)容名稱、內(nèi)容熱度、內(nèi)容大小、內(nèi)容 類型、下載流量，根據(jù)記錄日志對各種用戶下載的資源進行統(tǒng)計和排名； 用戶行為統(tǒng)計：根據(jù)用戶訪問情況形成用戶的業(yè)務使用情況，包含下載 的資源類型、標識、時長、流量效勞節(jié)點、用戶IP地址等；可提供訪問 者的流量、流量占比、瀏覽器類型、終端類型等分析統(tǒng)計數(shù)據(jù)； 數(shù)據(jù)流量統(tǒng)計：分析所效勞各類流量及占總流量的比