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