【正文】 nown 這種 Abort 的終端分類(lèi)如下表： Abort_Reason Mobile_Type_Main Abort_Reason_Total Abort觸發(fā)時(shí)間 (Avg) Unknow n Nokia3120 10 Unknow n Nokia3100 8 Unknow n Nokia6100 6 Unknow n Nokia3108 4 Unknow n MOTC261 4 Unknow n Nokia6108 3 Unknow n AlcatelTH4 3 Unknow n SAMSUNGSGHX608 2 69455 Unknow n SAMSUNGSGHE708 2 Unknow n LGKG98 ser 2 59537 Unknow n LGKG338 ser 2 59466 Unknow n VKVK800 1 60015 Unknow n Nokia6610I 1 27491 Unknow n Nokia3200 1 27459 Unknow n NECN700 1 59651 從中可以看出各個(gè)廠家的不同型號(hào)終端在觸發(fā) Unknown 這種 Abort 的情況下是存在規(guī)律性的，例如 NOKIA 品牌的終端出現(xiàn) Unknown 大約在 26 至 27 秒，而SAMSUNG 則在 69 秒以上。我們判斷 Unknown 和各品牌終端在軟件設(shè)計(jì)上存在 Bug 有關(guān)。 WAPGW數(shù)據(jù)采集方法 數(shù)據(jù)業(yè)務(wù)小組針對(duì) WAPGW 現(xiàn)網(wǎng)存在的 WSP Connect 請(qǐng)求無(wú)響應(yīng)的情況，采集以下接口信令用以做專(zhuān)題分析： WAPGW 入口信令采集點(diǎn)： Gn+Gi(Fw Inside) 信令 WAPGW 入口 amp。我們 通過(guò)對(duì)近期采集的現(xiàn)網(wǎng)數(shù)據(jù)的 WAPGW Connect 不響應(yīng)情況進(jìn)行深入分析后，大致可以將這種情況進(jìn)行歸類(lèi) 為三類(lèi)： ? 由于用戶的錯(cuò)誤設(shè)置導(dǎo)致無(wú)法與 WAPGW 進(jìn)行正常連接 ? 用戶行為主動(dòng)放棄連接 WAPGW 來(lái)不及回復(fù) Connect Reply ? WAPGW 設(shè)備性能導(dǎo)致未響應(yīng)用戶的 Connect 請(qǐng)求 用戶原因造成的 WAPGW無(wú)響應(yīng)分析 首先看一下用戶原因造成的 WAPGW 不響應(yīng)用戶發(fā)起的 Connect 請(qǐng)求現(xiàn)象的典型問(wèn)題流程： 如上流程可以看出用戶使用 APN 為 CMWAP 進(jìn)行 PDP 激活成功以后，分配了 IP 地址為 ，接下來(lái)用戶進(jìn)行與 WAPGW 的 的連接過(guò)程，可是從流程中來(lái)看用戶請(qǐng)求的 WAPGW 的 IP 地址并非 而是。 我們針對(duì)在 6 月 17 日的 15 點(diǎn)至 17 點(diǎn)間采集的 Gnamp。 結(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)換為 。 而從用戶終端的角度來(lái)看，其并不知道自已的設(shè)置存在問(wèn)題，用戶實(shí)際根據(jù)自已所持終端品牌的不同而間隔特定的時(shí) 間不斷向網(wǎng)絡(luò)重新發(fā)起 Connect 請(qǐng)求。 根據(jù)我們對(duì)采集時(shí)段信令針對(duì)不同終端品牌的統(tǒng)計(jì)如下： Mobile_Type_Main Abort_Reason Abort_Reason_Total ConnectAbort_Time(ms) Avg MAUI MMS User Agent Session has been disconnected 43 SY05 Session has been disconnected 16 T6 Session has been disconnected 7 Nokia6108 Unknow n 6 Nokia6100 Unknow n 4 Nokia3120 Unknow n 4 Nokia3100 Unknow n 4 LCT_X700B_01 Session has been disconnected 4 29428 SonyEricssonT628 Session has been disconnected 2 19234 WAPPER Session has been disconnected 1 28417 SZSGF420 Session has been disconnected 1 5499 SonyEricssonT618 Session has been disconnected 1 1277 SonyEricssonT610 Session has been disconnected 1 618 Nokia6108 Session has been disconnected 1 2172 MOTV3 User request 1 2576 通過(guò)排名在前的終端型號(hào)，可以看出在當(dāng)用戶長(zhǎng)時(shí)間無(wú)法享用業(yè)務(wù)時(shí)較容易觸發(fā)的 Abort 類(lèi)型有： Session has been disconnected 及 Unknown 這兩種。 基于以上理論可以判斷當(dāng)用戶 終端 的 APN=CMWAP 中的參數(shù) 設(shè)置錯(cuò)誤時(shí)，由于無(wú)法與 WAPGW 正常連接，從而 使所有與 WAPGW 相關(guān)的數(shù)據(jù)應(yīng)用業(yè)務(wù)都得不到享用，并且由于終端不斷在發(fā)起請(qǐng)求而不斷增加用戶點(diǎn)擊后的等待時(shí)長(zhǎng)，影響了用戶的數(shù)據(jù)業(yè)務(wù)感知，從中可以聯(lián)想到這種情況是極易引發(fā)數(shù)據(jù)業(yè)務(wù)用戶投訴的。 我們建議如果用戶設(shè)置了錯(cuò)誤的 APN 時(shí)發(fā)起的 Connect 消息時(shí)網(wǎng)絡(luò)能夠 利用類(lèi)似愛(ài)立信廠家提供的 ADC (Automatic Device Configure) Server 來(lái) 檢測(cè)到終端APN 設(shè)置 中的 存在問(wèn)題并 智能的通過(guò) PUSH 消息 通知的形式指導(dǎo)用戶正確配置APN。由于用戶的發(fā)起請(qǐng)求的 WAPGW IP 地址已經(jīng)經(jīng)過(guò)地址轉(zhuǎn)換，只有在用戶 APN 設(shè)置正確的前提下才有可能經(jīng)過(guò) Fw 及 Router 設(shè)備的 NAT 后 再轉(zhuǎn)發(fā)給 WAPGW，這樣基本排除了用戶 APN 設(shè)置問(wèn)題產(chǎn)生的 WAPGW 不響應(yīng)終端請(qǐng)求的可能性。 用戶發(fā)起 Connect 得到 WAPGW 回復(fù)的 Reply，但由于其它接口原因致使終端未收到而不斷重發(fā) Connect： 從上圖流程中可以看出用戶發(fā)起的 Connect 請(qǐng)求在 Gi 接口上很快得到了WAPGW 返回的 Reply，但是接下來(lái)終端在一直重發(fā) Connect，說(shuō)明手機(jī)可能由于無(wú)線環(huán)境特別是下行較差或當(dāng)時(shí)其它接口性能存在問(wèn)題，而網(wǎng)絡(luò)也由于無(wú)法收到手機(jī)上發(fā)的 Acknowledge 而不斷重發(fā) Connect Reply，在經(jīng)過(guò)手機(jī)及網(wǎng)絡(luò)雙方向的多次重發(fā)之后，最終 WAPGW 才收到手上發(fā)的 Acknowledge。 從 WAPGW 能夠較快的回應(yīng)終端的 Connect 請(qǐng)求消息來(lái)看這種原因引發(fā)多次重傳與 WAPGW 本身的性能無(wú)關(guān)，根據(jù)以往經(jīng)驗(yàn)類(lèi)似情況主要多與無(wú)線側(cè)性能有關(guān)。 考慮到局方網(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)化策略。下面是對(duì) Get 過(guò)程時(shí)延情況的分布圖： 如上圖所示在 Get 過(guò)程時(shí)延分布圖中，近 50%的請(qǐng)求時(shí)延小于 100ms，大于500ms 的請(qǐng)求也達(dá)到了 %。 我們針對(duì)在 中明顯訪問(wèn)時(shí)長(zhǎng)過(guò)長(zhǎng) (大于 5 秒作出響應(yīng) )的 SP 站點(diǎn)進(jìn)行了如下歸類(lèi)，其中包含在信令采集期間一部份一直未對(duì)用戶請(qǐng)求做出任何響應(yīng)的 SP站點(diǎn)： abnormity 成功率分析 下表是 5 月 22 日 15:0017:00 的 Get KPI結(jié)果： 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 根據(jù)我們的統(tǒng)計(jì)，移動(dòng)現(xiàn)網(wǎng) Get 成功率平均為 %以上，從數(shù)據(jù)結(jié)果來(lái)看成功率較高。如下表所示： 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 從上 表 可看出本次采集過(guò)程當(dāng)中，在 Get 請(qǐng)求至網(wǎng)關(guān)下發(fā) Get Reply 間，上行方向 User 原因產(chǎn)生的 Abort 占到 98％ 以上，其中以 Peer Request、 User Request 和 Session has been disconnected 三種原因的 Abort 居多；下行方向Network 原因產(chǎn)生的 Abort 消息主要以 Protocol Error 及 No Response 、Message too large 等 Abort 消息為主。 從上圖 可以看出在 Get 過(guò)程中出現(xiàn) Abort Reason 為 Session has been disconected 的情況下有 %是集中于 10ms 以內(nèi)觸發(fā)的，另外有 %的情況下是長(zhǎng)時(shí)間沒(méi)有得到網(wǎng)絡(luò)的 Reply 而中止。 我們對(duì)信令采集期間在 10ms 內(nèi)發(fā)起 Session has been disconected 的所有終端進(jìn)行統(tǒng)計(jì)如下： 排名 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 從我們的統(tǒng)計(jì)中發(fā)現(xiàn) 10ms 內(nèi)發(fā)起 Session has been disconected 的數(shù)據(jù)業(yè)務(wù)終端類(lèi)型有 80%以上是中電、波導(dǎo)、 TCL、聯(lián)想等國(guó)產(chǎn)型號(hào)終端，四大主流品牌終端在其中所占比例非常小。可以看到用戶在訪問(wèn) 上面的一些 gif 圖片內(nèi)容。 而這種行為也是大多數(shù)上網(wǎng)用戶的習(xí)慣性行為特征，是完全附合用戶使用邏輯的。 CASE Analysis： Peer Request (%)續(xù) — 網(wǎng)絡(luò)引發(fā) 以上流程就是典型的由于網(wǎng)絡(luò)原因影響了 用戶感知，而引致用戶主動(dòng)發(fā)起Peer Request 的典型案例。 在 Get 過(guò)程中出現(xiàn)的 Abort 比例相對(duì)較高的還有 Protocol Error、 No Response、 Unknown、 Message too large、 Network error 這幾種，總共占到Abort 比例當(dāng)中的 %。足見(jiàn)這款終端對(duì)亂序包的處理性能非常差，可能手機(jī)軟件設(shè)計(jì)上存在 Bug 導(dǎo)致。可以看出 LGKG328 的終端在處理重發(fā)包片的進(jìn)程中存在 Bug。其中應(yīng)答碼為 2XX, 3XX 的非異常原因值所占比例也相對(duì)較大，合計(jì)為%左右。終端一般會(huì)向此新地址重新提出請(qǐng)求，但某些終端會(huì)無(wú)法響應(yīng)新地址，造成業(yè)務(wù)最終失敗。屬于正常情況。 404 狀態(tài)碼并不指明狀況是臨時(shí)性的還是永久性的。 403 Forbidden 961 % 該狀態(tài)碼一般用于服務(wù)器端不想公布請(qǐng)求被拒絕的細(xì)節(jié)或沒(méi)有其 它的回應(yīng)可用。 301 Moved Permanently 581 % 請(qǐng)求到的資源都會(huì)分配一個(gè)永久的 URL，這樣就可以在將來(lái)通過(guò)該 URL 來(lái)訪問(wèn)此資源。