【正文】 403 Forbidden 961 % 該狀態(tài)碼一般用于服務(wù)器端不想公布請求被拒絕的細節(jié)或沒有其 它的回應(yīng)可用。其中應(yīng)答碼為 2XX, 3XX 的非異常原因值所占比例也相對較大，合計為%左右。 CASE Analysis： Peer Request (%)續(xù) — 網(wǎng)絡(luò)引發(fā) 以上流程就是典型的由于網(wǎng)絡(luò)原因影響了 用戶感知，而引致用戶主動發(fā)起Peer Request 的典型案例。 從上圖 可以看出在 Get 過程中出現(xiàn) Abort Reason 為 Session has been disconected 的情況下有 %是集中于 10ms 以內(nèi)觸發(fā)的，另外有 %的情況下是長時間沒有得到網(wǎng)絡(luò)的 Reply 而中止。 考慮到局方網(wǎng)絡(luò)的數(shù)據(jù)量在特定時段較大 (例如手機早晚報下發(fā)時段 )，建議首先檢查 WAPGW 的運行狀況，例如進程調(diào)度情況， CPU、內(nèi)存占用情況，再決定優(yōu)化策略。 我們建議如果用戶設(shè)置了錯誤的 APN 時發(fā)起的 Connect 消息時網(wǎng)絡(luò)能夠 利用類似愛立信廠家提供的 ADC (Automatic Device Configure) Server 來 檢測到終端APN 設(shè)置 中的 存在問題并 智能的通過 PUSH 消息 通知的形式指導(dǎo)用戶正確配置APN。 結(jié)合現(xiàn)網(wǎng)的網(wǎng)絡(luò)情況是用戶如果 用 APN=CMWAP 發(fā)起 Connect 時，在穿過Fw 之后會將所有設(shè)置正確用戶的 Connect 請求消息中 IP 的目標地址統(tǒng)一進行NAT 轉(zhuǎn)換為 。我們判斷 Unknown 和各品牌終端在軟件設(shè)計上存在 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)絡(luò)主動發(fā)起了 Abort 消息，其中的 Abort reason 為 User Request。這些大的時延很有可能導(dǎo)致終端用戶由于長時間等待而放棄業(yè)務(wù)，從而造成 WAP 業(yè)務(wù)成功率的下降，進而影響用戶業(yè)務(wù)體驗。 DNS 性能分析 下 圖 是 5/22 14:00~17:00 區(qū)間里面排名前五位的 DNS 訪問 成功率和時延統(tǒng)計： 可以看 出 作為 現(xiàn)網(wǎng) 主要的 DNS 服務(wù)器，占了所有訪問量的％ ，并且 平均查詢 時延 為 ， 時延 性能及指標較好 ，其查詢成功率為％ ， 在所有的訪問失敗中 ‘請求無響應(yīng) ’占據(jù)了 ％ 。這也進一步影響了用戶做數(shù)據(jù)業(yè)務(wù)時的感知， 我們 建議對這兩個 外省 APN 進行專題優(yōu)化。 用戶請求業(yè)務(wù)種類分析 通過對 采集的 海量 信令數(shù)據(jù)進行過濾功能，將采集時段內(nèi)用戶 上網(wǎng)請求上傳及下載的各種業(yè)務(wù)種類進行如下分類： 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 當(dāng)前 WAP 用戶業(yè)務(wù)上傳及下載的內(nèi)容主要以 JAVA 應(yīng)用程序的交互以及文本和圖片等應(yīng)用居多，而且可以看出當(dāng)用戶需要下載音頻或視頻 時 所需要花費的時間比其它數(shù)據(jù)業(yè)務(wù)應(yīng)用類型明顯要長。 2 WAP 業(yè)務(wù)整體性能分析 WAP 業(yè)務(wù)總體分析 WAP 協(xié)議棧使用情況 WAP 協(xié)議按照版本可以分 為 與 。其中 中的 各種信令流程 主要 基于 WSP 和 WTP 協(xié)議，而 過程則基于 TCP 和 HTTP 協(xié)議，兩者的分析過程也不盡相同。 WAPGW節(jié)點服務(wù)器業(yè)務(wù)量分析 針對 6 月 30 日下午收集的 Gw 接口的信令，數(shù)據(jù)業(yè)務(wù)小組對現(xiàn)網(wǎng) NOKIA 及ZTE 的 WAPGW 從屬的各節(jié)點服務(wù)器的業(yè)務(wù)量進行了統(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é)點服務(wù)器的訪問量來看， NOKIA的 19 臺 Server 中 HBWHPSWAPGW20 這臺 Server 的訪問量較其它服務(wù)器要明顯高。 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 回復(fù)的 Request Accepted，但也有部份因為資源或不同廠家設(shè)備兼容性造成的 PDP 激活失敗的Cause。 作為次要的 DNS 服務(wù)器，承擔(dān)了 ％ 的 查詢 訪問量，平均訪問時延 劣于主用 DNS 服務(wù)器 為 。 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)絡(luò)原因未響應(yīng)終端側(cè)請求也會導(dǎo)致終端重發(fā)超時后發(fā)起Session has been disconnected 的 Abort。 5 WAPGW 連接無響應(yīng)問題分析 WAPGW請求無響應(yīng)情況描述 根據(jù)移動網(wǎng)維中心 客戶 反映，現(xiàn)網(wǎng) WAPGW 時常有 WSP Connect 消息需要發(fā)送多次才能得到 WAPGW 響應(yīng)的 WSP Reply 并且在極端情況下會出現(xiàn)WAPGW 完全不響應(yīng)用戶發(fā)起的 WSP Connect 請求消息的情況。從這點可以明顯看出當(dāng)用戶在 APN=CMWAP 中設(shè)置了錯誤的 Proxy Server IP 實質(zhì)上在經(jīng)過 Fw 及 Router 時由于不符合設(shè)備上面ACL 中 定義的特定 Rule 所以將用戶發(fā)起的 Connect 請求丟棄掉而不在向WAPGW 進行地址轉(zhuǎn)化后再轉(zhuǎn)發(fā)。 WAPGW響應(yīng)慢或不響應(yīng)用戶請求分析 我們?yōu)榱瞬檎?WAPGW 自身原因產(chǎn)生的不響應(yīng)用戶發(fā)起的 Connect 請求的原因，我們針對 Fw 出口至 WAPGW 間的 Gi 接口信令進行信令采集。 6 訪問性能分析 Get 過程分析 Get 時延分析 在 WAP 業(yè) 務(wù)中， 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)絡(luò)響應(yīng)的Reply，而以間隔 5 秒的周期不斷的向網(wǎng)絡(luò)重發(fā) Get 請求，在間隔了 41 秒后用戶放棄請求，發(fā)起 Abort 中止此次 Session。 過程應(yīng)答碼分布： 我們對于每種非正常的應(yīng)答碼均給出了問題產(chǎn)生的大致原因，從而為后期的優(yōu)化為參考依據(jù)： Get Reply_Status Reply_Status_Num Reply_Status(%) Reply_Status 原因分析 200 OK 332017 % 服務(wù)器成功接受客戶端請求 302 Moved Temporarily 19530 % 請求的網(wǎng)頁鏈接地址被臨時取消，網(wǎng)絡(luò)會在返回消息中告知新地址。 500 Internal Server Error 758 % 服務(wù)器碰到了意外情況，使其無法繼 續(xù)回應(yīng)請求。如果服務(wù)器不希望為客戶端提供這方面的信息，還回應(yīng) 403（禁止）狀態(tài)碼。 CASE Analysis： Message too large (%) —終端異常造成 Reply 狀態(tài)碼分析 在數(shù)據(jù)采集時段中， 得到的 Reply 返回碼的各原因值的次數(shù)以及在總失敗中所占的比例見下表，網(wǎng)關(guān)返回的 200,OK,Success 的正常碼比例達到%。所以此類錯誤在這種用戶使用習(xí)慣影響下造成的 Abort 并不是由于網(wǎng)絡(luò)原因引起的，不應(yīng)該加到成功率的計算當(dā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 回復(fù) Reply 前后的分布比例有明顯差異， User Request 及 Peer Request在 WAPGW 響應(yīng) Reply 之后觸發(fā)的概率明顯要高于終端發(fā)起 Get 等待 WAPGW響應(yīng) Reply 之前的觸發(fā)次數(shù)，而 Session has been disconected 則與前兩者相反。 WAPGW 不能及時回應(yīng) Reply 而回復(fù) Acknowledge 情況一： WAPGW 不能及時回應(yīng) Reply 而回復(fù) Acknowledge 情況二： 從以上流程中可以看出用戶發(fā)起的 Connect 請求由于當(dāng)時 WAPGW 可能賦忙不能及時響應(yīng) Reply 而是響應(yīng)了 Acknowledge 來保持與 終端用戶的會話，在間隔了 997 毫秒 WAPGW 回應(yīng)了終端的 Reply，當(dāng)然也存在像第二種流程樣例中的WAPGW 響應(yīng) Acknowledge 后沒有任何后續(xù)回應(yīng)的動作，這幾種類流程的觸發(fā)主要與當(dāng)時的 WAPGW 的并發(fā)進程數(shù)及系統(tǒng)資源調(diào)度，板卡 CP 負荷容量有較大關(guān)聯(lián)。 除了用戶對 APN=CMWAP 中的 Proxy Server IP 設(shè)置存在問題引起WAPGW 不響應(yīng)終端的 Connect 請求消息的情況，還有另一種由于用戶對終端設(shè)置存在問題可能導(dǎo)致 WAPGW 不作任何響應(yīng)的情況：當(dāng)用戶將 APN 中的 Proxy Server Port 中 的端口號設(shè)置成與自已所持終端性能不相匹配的情況下也會產(chǎn)生WAPGW 不作任何響應(yīng)，例