【正文】 403 Forbidden 961 % 該狀態(tài)碼一般用于服務器端不想公布請求被拒絕的細節(jié)或沒有其 它的回應可用。其中應答碼為 2XX, 3XX 的非異常原因值所占比例也相對較大，合計為%左右。 CASE Analysis： Peer Request (%)續(xù) — 網(wǎng)絡引發(fā) 以上流程就是典型的由于網(wǎng)絡原因影響了 用戶感知，而引致用戶主動發(fā)起Peer Request 的典型案例。 從上圖 可以看出在 Get 過程中出現(xiàn) Abort Reason 為 Session has been disconected 的情況下有 %是集中于 10ms 以內(nèi)觸發(fā)的，另外有 %的情況下是長時間沒有得到網(wǎng)絡的 Reply 而中止。 考慮到局方網(wǎng)絡的數(shù)據(jù)量在特定時段較大 (例如手機早晚報下發(fā)時段 )，建議首先檢查 WAPGW 的運行狀況，例如進程調(diào)度情況， CPU、內(nèi)存占用情況，再決定優(yōu)化策略。 我們建議如果用戶設置了錯誤的 APN 時發(fā)起的 Connect 消息時網(wǎng)絡能夠 利用類似愛立信廠家提供的 ADC (Automatic Device Configure) Server 來 檢測到終端APN 設置 中的 存在問題并 智能的通過 PUSH 消息 通知的形式指導用戶正確配置APN。 結(jié)合現(xiàn)網(wǎng)的網(wǎng)絡情況是用戶如果 用 APN=CMWAP 發(fā)起 Connect 時，在穿過Fw 之后會將所有設置正確用戶的 Connect 請求消息中 IP 的目標地址統(tǒng)一進行NAT 轉(zhuǎn)換為 。我們判斷 Unknown 和各品牌終端在軟件設計上存在 Bug 有關(guān)。但是一直未得到終端的確認消息，計數(shù)器超時發(fā)送 Session has been disconnected 的 Abort 用于終止這個Session。 CASE Analysis: User Request (%) — 終端原因引發(fā) 以上信令流程可看出使用 MOTL7/ MIB/ Profile/品牌的終端用戶在 16:54:27’481 向 WAP 網(wǎng)關(guān)發(fā)送 Connect 請求消息，在間隔 36 毫秒又向網(wǎng)絡主動發(fā)起了 Abort 消息，其中的 Abort reason 為 User Request。這些大的時延很有可能導致終端用戶由于長時間等待而放棄業(yè)務，從而造成 WAP 業(yè)務成功率的下降，進而影響用戶業(yè)務體驗。 DNS 性能分析 下 圖 是 5/22 14:00~17:00 區(qū)間里面排名前五位的 DNS 訪問 成功率和時延統(tǒng)計： 可以看 出 作為 現(xiàn)網(wǎng) 主要的 DNS 服務器，占了所有訪問量的％ ，并且 平均查詢 時延 為 ， 時延 性能及指標較好 ，其查詢成功率為％ ， 在所有的訪問失敗中 ‘請求無響應 ’占據(jù)了 ％ 。這也進一步影響了用戶做數(shù)據(jù)業(yè)務時的感知， 我們 建議對這兩個 外省 APN 進行專題優(yōu)化。 用戶請求業(yè)務種類分析 通過對 采集的 海量 信令數(shù)據(jù)進行過濾功能，將采集時段內(nèi)用戶 上網(wǎng)請求上傳及下載的各種業(yè)務種類進行如下分類： JAVA Audio Image Get_Num Post_Num Visit_Delay Get_Num Post_Num Visit_Delay Get_Num Post_Num Visit_Delay 141430 86391 577 21 121704 89 Video Text Get_Num Post_Num Visit_Delay Get_Num Post_Num Visit_Delay 101 0 48950 48950 當前 WAP 用戶業(yè)務上傳及下載的內(nèi)容主要以 JAVA 應用程序的交互以及文本和圖片等應用居多，而且可以看出當用戶需要下載音頻或視頻 時 所需要花費的時間比其它數(shù)據(jù)業(yè)務應用類型明顯要長。 2 WAP 業(yè)務整體性能分析 WAP 業(yè)務總體分析 WAP 協(xié)議棧使用情況 WAP 協(xié)議按照版本可以分 為 與 。其中 中的 各種信令流程 主要 基于 WSP 和 WTP 協(xié)議，而 過程則基于 TCP 和 HTTP 協(xié)議，兩者的分析過程也不盡相同。 WAPGW節(jié)點服務器業(yè)務量分析 針對 6 月 30 日下午收集的 Gw 接口的信令，數(shù)據(jù)業(yè)務小組對現(xiàn)網(wǎng) NOKIA 及ZTE 的 WAPGW 從屬的各節(jié)點服務器的業(yè)務量進行了統(tǒng)計與分析： HuBei MCC WAPGW Node List Visit_Total Visit_Rate(%) ZXWAP GateWay,ZTE Technologies 144835 % WTP/ HBWHPSWAPGW20 62052 % WTP/ HBWHPSWAPGW16 48611 % WTP/ HBWHPSWAPGW03 47425 % WTP/ HBWHPSWAPGW13 47206 % WTP/ HBWHPSWAPGW11 47149 % WTP/ HBWHPSWAPGW15 47145 % WTP/ HBWHPSWAPGW14 46862 % WTP/ HBWHPSWAPGW12 46601 % WTP/ HBWHPSWAPGW01 46565 % WTP/ HBWHPSWAPGW18 45956 % WTP/ HBWHPSWAPGW19 45909 % WTP/ HBWHPSWAPGW17 45832 % WTP/ HBWHPSWAPGW02 45553 % WTP/ HBWHPSWAPGW10 31616 % WTP/ HBWHPSWAPGW09 31508 % WTP/ HBWHPSWAPGW08 31440 % WTP/ HBWHPSWAPGW04 31438 % WTP/ HBWHPSWAPGW05 31360 % WTP/ HBWHPSWAPGW06 31066 % 上表 統(tǒng)計中的訪問量的計算為在采集時段內(nèi)所有發(fā)向該 節(jié)點的 Get 及 Post 等消息求總 從以上針對 ZTE 及 NOKIA 的 WAPGW 各節(jié)點服務器的訪問量來看， NOKIA的 19 臺 Server 中 HBWHPSWAPGW20 這臺 Server 的訪問量較其它服務器要明顯高。 PDP 激活 GTP Cause 分析 對信令采集時段 PDP 激活過程中的 GTP 協(xié)議所攜帶的 Cause 進行整理如下： GTP_Cause GTP_Cause_Count Rate(%) Request accepted 178205 % No resource available 276 % Invalid message format 4 % System failure 1 % 從上表可以看出絕大部份的 PDP 激活請求都到了目標 GGSN 回復的 Request Accepted，但也有部份因為資源或不同廠家設備兼容性造成的 PDP 激活失敗的Cause。 作為次要的 DNS 服務器，承擔了 ％ 的 查詢 訪問量，平均訪問時延 劣于主用 DNS 服務器 為 。 Connect 成功率分析 下表是 5 月 22 日 15:0017:00 的 Connect KPI 結(jié)果： Times Connect_Total Reply Total Ack Total Abort_Total Connect Reply Succ(%) Relpy_Delay_Time(Avg) 2020522 15:00 22072 21811 21435 273 % 2020522 16:00 101266 100175 98114 1494 % 2020522 17:00 2573 2527 2480 30 % 根據(jù)我們的統(tǒng)計，移動現(xiàn)網(wǎng) Connect 成功率在 98%以上，從數(shù)據(jù)結(jié)果來看成功率較高。在之后用戶又重新發(fā)起一次正常的 Connect 流程。 Connect 過程一直未收到終端發(fā)送的 Ack 歷時長達 30 秒 從中可以看出由于網(wǎng)絡原因未響應終端側(cè)請求也會導致終端重發(fā)超時后發(fā)起Session has been disconnected 的 Abort。 5 WAPGW 連接無響應問題分析 WAPGW請求無響應情況描述 根據(jù)移動網(wǎng)維中心 客戶 反映，現(xiàn)網(wǎng) WAPGW 時常有 WSP Connect 消息需要發(fā)送多次才能得到 WAPGW 響應的 WSP Reply 并且在極端情況下會出現(xiàn)WAPGW 完全不響應用戶發(fā)起的 WSP Connect 請求消息的情況。從這點可以明顯看出當用戶在 APN=CMWAP 中設置了錯誤的 Proxy Server IP 實質(zhì)上在經(jīng)過 Fw 及 Router 時由于不符合設備上面ACL 中 定義的特定 Rule 所以將用戶發(fā)起的 Connect 請求丟棄掉而不在向WAPGW 進行地址轉(zhuǎn)化后再轉(zhuǎn)發(fā)。 WAPGW響應慢或不響應用戶請求分析 我們?yōu)榱瞬檎?WAPGW 自身原因產(chǎn)生的不響應用戶發(fā)起的 Connect 請求的原因，我們針對 Fw 出口至 WAPGW 間的 Gi 接口信令進行信令采集。 6 訪問性能分析 Get 過程分析 Get 時延分析 在 WAP 業(yè) 務中， WSP/WTP Get 過程在核心網(wǎng)上的信令流程如下圖： WAP 時延是在 Gn 或 Gi 接口從手機上發(fā) Get Request 開始，到在 Gn或 Gi 接口收到 WAP 網(wǎng)關(guān)下發(fā) Get Reply 信令之間的時間差。 對于在 10ms 以內(nèi)觸發(fā)的 Session has been disconected 可以想象用戶很難在極短的時間內(nèi)主動要求放棄 Session，我們判斷 Session has been disconected這種 Abort 主要 與用戶手中所持的品牌終端性能有很大關(guān)系。從中可以看出用戶發(fā)起 Get 一直無法得到網(wǎng)絡響應的Reply，而以間隔 5 秒的周期不斷的向網(wǎng)絡重發(fā) Get 請求，在間隔了 41 秒后用戶放棄請求，發(fā)起 Abort 中止此次 Session。 過程應答碼分布： 我們對于每種非正常的應答碼均給出了問題產(chǎn)生的大致原因，從而為后期的優(yōu)化為參考依據(jù)： Get Reply_Status Reply_Status_Num Reply_Status(%) Reply_Status 原因分析 200 OK 332017 % 服務器成功接受客戶端請求 302 Moved Temporarily 19530 % 請求的網(wǎng)頁鏈接地址被臨時取消，網(wǎng)絡會在返回消息中告知新地址。 500 Internal Server Error 758 % 服務器碰到了意外情況，使其無法繼 續(xù)回應請求。如果服務器不希望為客戶端提供這方面的信息，還回應 403（禁止）狀態(tài)碼。 CASE Analysis： Message too large (%) —終端異常造成 Reply 狀態(tài)碼分析 在數(shù)據(jù)采集時段中， 得到的 Reply 返回碼的各原因值的次數(shù)以及在總失敗中所占的比例見下表，網(wǎng)關(guān)返回的 200,OK,Success 的正常碼比例達到%。所以此類錯誤在這種用戶使用習慣影響下造成的 Abort 并不是由于網(wǎng)絡原因引起的，不應該加到成功率的計算當中。 我們對要集時段終端發(fā)起 Get 到 WAPGW 返回 Reply 過程中產(chǎn)生的 Reply，按照終端收到 Reply 之前與之后所產(chǎn)生的 Abort 進行類比如下： 從中可以看出占據(jù) Abort Reason 絕大多數(shù)比例的 Peer Request(%)、User Request(%)及 Session has been disconected(%)在得到WAPGW 回復 Reply 前后的分布比例有明顯差異， User Request 及 Peer Request在 WAPGW 響應 Reply 之后觸發(fā)的概率明顯要高于終端發(fā)起 Get 等待 WAPGW響應 Reply 之前的觸發(fā)次數(shù)，而 Session has been disconected 則與前兩者相反。 WAPGW 不能及時回應 Reply 而回復 Acknowledge 情況一： WAPGW 不能及時回應 Reply 而回復 Acknowledge 情況二： 從以上流程中可以看出用戶發(fā)起的 Connect 請求由于當時 WAPGW 可能賦忙不能及時響應 Reply 而是響應了 Acknowledge 來保持與 終端用戶的會話，在間隔了 997 毫秒 WAPGW 回應了終端的 Reply，當然也存在像第二種流程樣例中的WAPGW 響應 Acknowledge 后沒有任何后續(xù)回應的動作，這幾種類流程的觸發(fā)主要與當時的 WAPGW 的并發(fā)進程數(shù)及系統(tǒng)資源調(diào)度，板卡 CP 負荷容量有較大關(guān)聯(lián)。 除了用戶對 APN=CMWAP 中的 Proxy Server IP 設置存在問題引起WAPGW 不響應終端的 Connect 請求消息的情況，還有另一種由于用戶對終端設置存在問題可能導致 WAPGW 不作任何響應的情況：當用戶將 APN 中的 Proxy Server Port 中 的端口號設置成與自已所持終端性能不相匹配的情況下也會產(chǎn)生WAPGW 不作任何響應，例