【導讀】此報告主要介紹了本次項目中數據業(yè)務組在項目執(zhí)行期間的所有工作內容。

　　

【正文】 的 Reply，當然也存在像第二種流程樣例中的WAPGW 響應 Acknowledge 后沒有任何后續(xù)回應的動作，這幾種類流程的觸發(fā)主要與當時的 WAPGW 的并發(fā)進程數及系統資源調度，板卡 CP 負荷容量有較大關聯。 考慮到局方網絡的數據量在特定時段較大 (例如手機早晚報下發(fā)時段 )，建議首先檢查 WAPGW 的運行狀況，例如進程調度情況， CPU、內存占用情況，再決定優(yōu)化策略。 6 訪問性能分析 Get 過程分析 Get 時延分析 在 WAP 業(yè) 務中， WSP/WTP Get 過程在核心網上的信令流程如下圖： WAP 時延是在 Gn 或 Gi 接口從手機上發(fā) Get Request 開始，到在 Gn或 Gi 接口收到 WAP 網關下發(fā) Get Reply 信令之間的時間差。下面是對 Get 過程時延情況的分布圖： 如上圖所示在 Get 過程時延分布圖中，近 50%的請求時延小于 100ms，大于500ms 的請求也達到了 %。這些大的時延與用戶請求的 SP 服務器性能有很大關系，部份 SP 提供的 Content Server 存在問題從而造成 WAP 業(yè)務訪 問整體時延的下降，進而影響用戶數據業(yè)務體驗。 我們針對在 中明顯訪問時長過長 (大于 5 秒作出響應 )的 SP 站點進行了如下歸類，其中包含在信令采集期間一部份一直未對用戶請求做出任何響應的 SP站點： abnormity 成功率分析 下表是 5 月 22 日 15:0017:00 的 Get KPI結果： Times Reply Total Ack Total Abort_Total Succ(%) Relpy_Time Abort_PCT(%) Segment_Count Page_Delay 2020522 15:00 94218 91896 88561 4821 % % 49371 2020522 16:00 268329 262420 251188 13178 % % 137831 2020522 17:00 9555 9319 8901 445 % % 4156 根據我們的統計，移動現網 Get 成功率平均為 %以上，從數據結果來看成功率較高。但仍然有一些異常的 Abort 影響了 Get 的連接成功率，我們對在 Get 過程中出現的 Abort 進行了如下歸類。如下表所示： Get Abort_Reason Abort_Reason_Count Abort_Peretage(%) Abort_Time(Avg) Abort_Type Peer request 13420 % User User request 2731 % User Session has been disconnected 1928 % User Protocol Error 144 % Provider No Response 72 % Provider Unknow n 66 % Provider Message too large 33 % Provider Netw ork error 21 % User The session connect failed 12 % User Invalid TID 10 % Provider Capacity Temporarily Exceeded 5 % Provider No Response 1 % 52459 User Invalid TID 1 % 58 User 從上 表 可看出本次采集過程當中，在 Get 請求至網關下發(fā) Get Reply 間，上行方向 User 原因產生的 Abort 占到 98％ 以上，其中以 Peer Request、 User Request 和 Session has been disconnected 三種原因的 Abort 居多；下行方向Network 原因產生的 Abort 消息主要以 Protocol Error 及 No Response 、Message too large 等 Abort 消息為主。 我們對要集時段終端發(fā)起 Get 到 WAPGW 返回 Reply 過程中產生的 Reply，按照終端收到 Reply 之前與之后所產生的 Abort 進行類比如下： 從中可以看出占據 Abort Reason 絕大多數比例的 Peer Request(%)、User Request(%)及 Session has been disconected(%)在得到WAPGW 回復 Reply 前后的分布比例有明顯差異， User Request 及 Peer Request在 WAPGW 響應 Reply 之后觸發(fā)的概率明顯要高于終端發(fā)起 Get 等待 WAPGW響應 Reply 之前的觸發(fā)次數，而 Session has been disconected 則與前兩者相反。 從上圖 可以看出在 Get 過程中出現 Abort Reason 為 Session has been disconected 的情況下有 %是集中于 10ms 以內觸發(fā)的，另外有 %的情況下是長時間沒有得到網絡的 Reply 而中止。 對于在 10ms 以內觸發(fā)的 Session has been disconected 可以想象用戶很難在極短的時間內主動要求放棄 Session，我們判斷 Session has been disconected這種 Abort 主要 與用戶手中所持的品牌終端性能有很大關系。 我們對信令采集期間在 10ms 內發(fā)起 Session has been disconected 的所有終端進行統計如下： 排名 TOP10 的終端如下： Mobile_Type_Main Abort_Reason Abort_Reason_Num Abort_time(Avg) CECT A1000 Session has been disconnected 22 TSDT9029 Session has been disconnected 17 LCT_X700B_01 Session has been disconnected 16 LENOVOi716 Session has been disconnected 14 3ms UNTRUSTED Session has been disconnected 11 LENOVOi370 Session has been disconnected 11 MAUI_WAP_Brow ser Session has been disconnected 10 HQD508 Session has been disconnected 10 Nokia7610 Session has been disconnected 7 HQD308 Session has been disconnected 7 從我們的統計中發(fā)現 10ms 內發(fā)起 Session has been disconected 的數據業(yè)務終端類型有 80%以上是中電、波導、 TCL、聯想等國產型號終端，四大主流品牌終端在其中所占比例非常小。 Session has been CASE Analysis： Peer Request (%) — 用戶主動發(fā)起 232 peer request 及 234 user request 錯誤主要是用戶側主動發(fā)起中斷引起的，如上圖是一個典型的 Peer request 例子?？梢钥吹接脩粼谠L問 上面的一些 gif 圖片內容。 但是當用戶看到大部分圖片或是網頁上已經顯示的內容大體滿足其當時瀏覽的需求時就會主動斷開連接。 而這種行為也是大多數上網用戶的習慣性行為特征，是完全附合用戶使用邏輯的。所以此類錯誤在這種用戶使用習慣影響下造成的 Abort 并不是由于網絡原因引起的，不應該加到成功率的計算當中。 CASE Analysis： Peer Request (%)續(xù) — 網絡引發(fā) 以上流程就是典型的由于網絡原因影響了 用戶感知，而引致用戶主動發(fā)起Peer Request 的典型案例。從中可以看出用戶發(fā)起 Get 一直無法得到網絡響應的Reply，而以間隔 5 秒的周期不斷的向網絡重發(fā) Get 請求，在間隔了 41 秒后用戶放棄請求，發(fā)起 Abort 中止此次 Session。 在 Get 過程中出現的 Abort 比例相對較高的還有 Protocol Error、 No Response、 Unknown、 Message too large、 Network error 這幾種，總共占到Abort 比例當中的 %。 我們通過 IBS 信令分析軟件對這幾種類型的 Abort 進行了如下 案例 分析： CASE Analysis： Protocol Error (%) —終端數據包亂序整合能力差引起 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 根據統計發(fā)現產生 85%的 Protocol Error 是 NEC 一款型號為 N600/ HopenOS/ 的終端造成。足見這款終端對亂序包的處理性能非常差，可能手機軟件設計上存在 Bug 導致。 CASE Analysis： No Response (%) —終端異常造成 從上圖流程可以看出用戶發(fā)起 Get 請求接收一條彩信， WAPGW 將彩信內容進行分段，分段的 Packet Sequence 為 14，由于用戶未能正常接收此條彩信，要求 WAPGW 對彩信內容的分段進行重新下發(fā)，但是 Negtive ack 消息中攜帶的要求進行重發(fā)的包片為 03， WAPGW 在后續(xù)流程僅針對 Packet Sequence 為 13的包進行了重發(fā)，而終端由于誤報了 Packet Sequence 0，而始終端不能得到網絡重發(fā)的 Packet Sequence 0，最終采取以 Abort Reason 為 No Response 來終止此次會話?？梢钥闯?LGKG328 的終端在處理重發(fā)包片的進程中存在 Bug。 CASE Analysis： Message too large (%) —終端異常造成 Reply 狀態(tài)碼分析 在數據采集時段中， 得到的 Reply 返回碼的各原因值的次數以及在總失敗中所占的比例見下表，網關返回的 200,OK,Success 的正常碼比例達到%。其中應答碼為 2XX, 3XX 的非異常原因值所占比例也相對較大，合計為%左右。 過程應答碼分布： 我們對于每種非正常的應答碼均給出了問題產生的大致原因，從而為后期的優(yōu)化為參考依據： Get Reply_Status Reply_Status_Num Reply_Status(%) Reply_Status 原因分析 200 OK 332017 % 服務器成功接受客戶端請求 302 Moved Temporarily 19530 % 請求的網頁鏈接地址被臨時取消，網絡會在返回消息中告知新地址。終端一般會向此新地址重新提出請求，但某些終端會無法響應新地址，造成業(yè)務最終失敗。 206 Partial Content 3668 % 服務器成功接受客戶端請求 304 Not Modified 3291 % 請求的內容已有緩存時，終端發(fā)送帶條件的請求消息，返回 值 304表示沒有滿足更新條件的內容，終端可以直接調用緩存。屬于正常情況。 404 Not Found 2142 % 服務器沒有找到與請求 URI 相符的資源。 404 狀態(tài)碼并不指明狀況是臨時性的還是永久性的。如果服務器不希望為客戶端提供這方面的信息，還回應 403（禁止）狀態(tài)碼。 403 Forbidden 961 % 該狀態(tài)碼一般用于服務器端不想公布請求被拒絕的細節(jié)或沒有其 它的回應可用。 500 Internal Server Error 758 % 服務器碰到了意外情況，使其無法繼 續(xù)回應請求。 301 Moved Permanently 581 % 請求到的資源都會分配一個永久的 URL，這樣就可以在將來通過該 URL 來訪問此資源。有編輯鏈接功能的客戶端會盡可能地根據服務器端傳回的新鏈接而自動更新請求 URI。