【正文】 有編輯鏈接功能的客戶端會盡可能地根據(jù)服務(wù)器端傳回的新鏈接而自動更新請求 URI。 500 Internal Server Error 758 % 服務(wù)器碰到了意外情況，使其無法繼 續(xù)回應(yīng)請求。如果服務(wù)器不希望為客戶端提供這方面的信息，還回應(yīng) 403（禁止）狀態(tài)碼。 404 Not Found 2142 % 服務(wù)器沒有找到與請求 URI 相符的資源。 206 Partial Content 3668 % 服務(wù)器成功接受客戶端請求 304 Not Modified 3291 % 請求的內(nèi)容已有緩存時，終端發(fā)送帶條件的請求消息，返回 值 304表示沒有滿足更新條件的內(nèi)容，終端可以直接調(diào)用緩存。 過程應(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ò)會在返回消息中告知新地址。 CASE Analysis： Message too large (%) —終端異常造成 Reply 狀態(tài)碼分析 在數(shù)據(jù)采集時段中， 得到的 Reply 返回碼的各原因值的次數(shù)以及在總失敗中所占的比例見下表，網(wǎng)關(guān)返回的 200,OK,Success 的正常碼比例達(dá)到%。 CASE Analysis： No Response (%) —終端異常造成 從上圖流程可以看出用戶發(fā)起 Get 請求接收一條彩信， WAPGW 將彩信內(nèi)容進(jìn)行分段，分段的 Packet Sequence 為 14，由于用戶未能正常接收此條彩信，要求 WAPGW 對彩信內(nèi)容的分段進(jìn)行重新下發(fā)，但是 Negtive ack 消息中攜帶的要求進(jìn)行重發(fā)的包片為 03， WAPGW 在后續(xù)流程僅針對 Packet Sequence 為 13的包進(jìn)行了重發(fā)，而終端由于誤報了 Packet Sequence 0，而始終端不能得到網(wǎng)絡(luò)重發(fā)的 Packet Sequence 0，最終采取以 Abort Reason 為 No Response 來終止此次會話。 我們通過 IBS 信令分析軟件對這幾種類型的 Abort 進(jìn)行了如下 案例 分析： CASE Analysis： Protocol Error (%) —終端數(shù)據(jù)包亂序整合能力差引起 Mobile_Type Abort_Reason Abort_Reason_Total Abort_time(Avg) NECN600/ HopenOS/ Protocol Error 122 AHONG_D05/ Protocol Error 5 UserAgent: Nokia7650/ SymbianOS/ Protocol Error 4 AHONG_A12/ Protocol Error 4 A06/ MTK_6217/ Protocol Error 3 LGKG70 MIC/ Protocol Error 2 9437 D998/AHONG_D08/ Protocol Error 1 36620 AAAAAA Protocol Error 1 94816 A11/ MTK_6217/ Protocol Error 1 41124 根據(jù)統(tǒng)計發(fā)現(xiàn)產(chǎn)生 85%的 Protocol Error 是 NEC 一款型號為 N600/ HopenOS/ 的終端造成。從中可以看出用戶發(fā)起 Get 一直無法得到網(wǎng)絡(luò)響應(yīng)的Reply，而以間隔 5 秒的周期不斷的向網(wǎng)絡(luò)重發(fā) Get 請求，在間隔了 41 秒后用戶放棄請求，發(fā)起 Abort 中止此次 Session。所以此類錯誤在這種用戶使用習(xí)慣影響下造成的 Abort 并不是由于網(wǎng)絡(luò)原因引起的，不應(yīng)該加到成功率的計算當(dāng)中。 但是當(dāng)用戶看到大部分圖片或是網(wǎng)頁上已經(jīng)顯示的內(nèi)容大體滿足其當(dāng)時瀏覽的需求時就會主動斷開連接。 Session has been CASE Analysis： Peer Request (%) — 用戶主動發(fā)起 232 peer request 及 234 user request 錯誤主要是用戶側(cè)主動發(fā)起中斷引起的，如上圖是一個典型的 Peer request 例子。 對于在 10ms 以內(nèi)觸發(fā)的 Session has been disconected 可以想象用戶很難在極短的時間內(nèi)主動要求放棄 Session，我們判斷 Session has been disconected這種 Abort 主要 與用戶手中所持的品牌終端性能有很大關(guān)系。 我們對要集時段終端發(fā)起 Get 到 WAPGW 返回 Reply 過程中產(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 則與前兩者相反。但仍然有一些異常的 Abort 影響了 Get 的連接成功率，我們對在 Get 過程中出現(xiàn)的 Abort 進(jìn)行了如下歸類。這些大的時延與用戶請求的 SP 服務(wù)器性能有很大關(guān)系，部份 SP 提供的 Content Server 存在問題從而造成 WAP 業(yè)務(wù)訪 問整體時延的下降，進(jìn)而影響用戶數(shù)據(jù)業(yè)務(wù)體驗。 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 信令之間的時間差。 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ā)進(jìn)程數(shù)及系統(tǒng)資源調(diào)度，板卡 CP 負(fù)荷容量有較大關(guān)聯(lián)。經(jīng)過統(tǒng)計發(fā)現(xiàn)類似這種情況的 Connect 過 程占據(jù)異常的 Connect 流程中的很大比例 ，達(dá)到 95%以上 。 經(jīng)過我們針對 Fw Outside 的 Gi 接口數(shù)據(jù)進(jìn)行觀察，發(fā)現(xiàn)存在多種情況： ? 用戶發(fā)起 Connect 以毫秒級間隔并發(fā) Session has been disconnected ? 用戶發(fā)起 Connect 得到 WAPGW 回復(fù)的 Reply，但是期間終端不斷重發(fā)Connect，網(wǎng)絡(luò)不斷重發(fā) Connect Reply 等待終端的 WTP Ack(這種現(xiàn)象占據(jù)絕大多數(shù)比例，達(dá)到 WAPGW 響應(yīng)用戶連接請求慢的 95%以上 ) ? 用戶發(fā)起 Connect 沒有得到 WAPGW 的任何響應(yīng) 用戶發(fā)起 Connect 幾乎同時發(fā)起 Session has been disconnected： 類似如上這種情況主要是由于用戶所持終端可能存在性問題導(dǎo)致在極短時間發(fā)起 Abort。 WAPGW響應(yīng)慢或不響應(yīng)用戶請求分析 我們?yōu)榱瞬檎?WAPGW 自身原因產(chǎn)生的不響應(yīng)用戶發(fā)起的 Connect 請求的原因，我們針對 Fw 出口至 WAPGW 間的 Gi 接口信令進(jì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)，例如當(dāng)用戶的終端僅支持 協(xié)議棧時，當(dāng)用戶將手機 APN 中的代理服務(wù)器端口號設(shè)置成面向連接的 9201 端口時，有可能產(chǎn)生發(fā)送的 Connect 請求消息存在協(xié)議棧支持問題。發(fā)生Abort 的情況下普遍是用戶發(fā)起 Conncet 之后在很長時間得不到需要的數(shù)據(jù)業(yè)務(wù)應(yīng)用而導(dǎo)致。在這個過程中由于用戶無法真實體驗到業(yè)務(wù)所以在此過程當(dāng)中很容易觸發(fā)各種類型的用戶原因 Abort。從這點可以明顯看出當(dāng)用戶在 APN=CMWAP 中設(shè)置了錯誤的 Proxy Server IP 實質(zhì)上在經(jīng)過 Fw 及 Router 時由于不符合設(shè)備上面ACL 中 定義的特定 Rule 所以將用戶發(fā)起的 Connect 請求丟棄掉而不在向WAPGW 進(jìn)行地址轉(zhuǎn)化后再轉(zhuǎn)發(fā)。Gi 信令針對用戶終端的APN 參數(shù)設(shè)置問題進(jìn)行統(tǒng)計如下： WAPGW_IP_Address Repeated_Connect_Total Connect_Request_Total Connect_Reply_Total 1147 127538 125653 2083 266 0 239 40 0 137 35 0 105 9 0 45 9 0 43 3 0 33 3 0 32 9 0 30 6 0 26 4 0 20 3 0 19 8 0 17 3 0 16 7 0 15 8 0 12 2 0 9 1 0 6 3 0 6 6 0 4 8 0 3 1 0 3 1 0 3 1 0 2 1 0 1 1 0 1 2 0 1 1 0 以上統(tǒng)計中為信令采集時段內(nèi)用戶發(fā)起的 的 Connect 請求消息的WAPGW 的 IP 地址的相關(guān)請求次數(shù)、請求重發(fā)次數(shù)及應(yīng)答次數(shù)的統(tǒng)計，從統(tǒng)計中可以明顯看出當(dāng)數(shù)據(jù)業(yè)務(wù)用戶將手機中 APN=CMWAP 中的 Proxy Server IP 設(shè)置為非 時，發(fā)出的所有向網(wǎng)關(guān)嘗試連接的請求全部都得不到任何響應(yīng)。這樣的連接請求顯然是得不到 WAPGW 的 Connect Reply(WSP)。出口信令采集點： Gi(Fw Outside)+Gw 信令 WAPGW響應(yīng)慢、無響應(yīng)情況分析 現(xiàn)網(wǎng) 的成功率為 %，其中發(fā)起連接請求后無響應(yīng)所占比例為%。 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)出現(xiàn)這種 Abort 的情況下對用戶感知的影響也是差異化的。 3) [WTP]GTR TTR Flag 標(biāo)志位為 last packet of message，對于彩信來說，它標(biāo)志著一個彩信的結(jié)尾，對于這類分段包，網(wǎng)關(guān)在收到后可以也可以 不回復(fù)確認(rèn)消息，但必須向彩信中心轉(zhuǎn)發(fā)（當(dāng)然前提是手機設(shè)置的彩信中心地址是正確的） 下圖為此次掛表數(shù)據(jù)中發(fā)現(xiàn)的由于未完成的 Session 而導(dǎo)致用戶以 Invalid TID 來終止新的連接請求的典型案例： 該次流程中 Segment14 的 GTR 標(biāo)識為 Last packet of packet group，但是始終沒有得到終端的確認(rèn)。 根據(jù)規(guī)范中的規(guī)定：對于分段包（ Segment）可以分為如下三個類型： 1) [WTP]GTR TTR Flag 標(biāo)志位為 not last packet，對于這類分段包，網(wǎng)關(guān)在收到后不回復(fù)確認(rèn)消息（ Ack）。 Connect 過程一直未收到終端發(fā)送的 Ack 歷時長達(dá) 30 秒 從中可以看出由于網(wǎng)絡(luò)原因未響應(yīng)終端側(cè)請求也會導(dǎo)致終端重發(fā)超時后發(fā)起Session has been disconnected 的 Abort。 CASE Analysis 續(xù) 1: Session has been disconnected(%)終端無響應(yīng) 下圖為此次掛表數(shù)據(jù)中發(fā)現(xiàn)的由于終端無響應(yīng)原因造成用戶端超時發(fā)起Session has been disconnected 的典型案例： 從以上可以流程可以看出終端 UA 為 MAUI MMS User Agent，