圖片

運營商D客服部進行網頁訪問測試，采用以下6個網頁輪詢測試，測試場景配置參見表1。

表1 測試場景配置

從摸底測試結果看，HTTP網頁訪問時延偏大，其中baidu、sina、sohu等平均時延基本在1.5 s以上，參見表2。

表2 頁面測試結果

在相同的測試站點下，保持測試點信號條件不變。分別使用了運營商D和運營商L的SIM卡對比測試，能看到使用運營商L卡的時延結果明顯優(yōu)于使用運營商D卡的結果，參見表3。

表3 運營商對比測試結果

sina多次測試的采樣統(tǒng)計結果參見表4，能看到運營商D卡測試的結果波動較大。20次訪問中，有8次的訪問時延大于1.5 s，運營商L卡測試的結果整體比較穩(wěn)定。

表4 sina多次測試的采樣統(tǒng)計結果

baidu對比測試結果類似，參見表5。運營商D卡的測試平均時延2.28 s，運營商L卡平均時延1.36 s。網頁傳輸大小的結果基本一致。

表5 baidu多次測試的采樣統(tǒng)計結果

圖片

分析流程圖如下圖所示。

圖片

分析流程

在基站側用戶面抓包分析，造成網頁時延偏大的原因主要與以下異常有關：

• DNS無響應或響應端口號錯誤導致TCP流延時建立（本應該同時建立的多個TCP流，其中1-2個延時1-2 s才發(fā)起建立）
• TCP建鏈SYN無響應
• TCP建鏈SYN ACK序號異常

在基站、核心網、防火墻和公網CE聯(lián)合抓包情況下，分析確認所有TCP建鏈異常和DNS查詢異常與防火墻端口映射有關，防火墻將并發(fā)的不同的TCP/UDP會話映射了相同公網端口，導致一系列網頁訪問流程異常。

防火墻進一步抓取日志確認，根本原因是本來主備工作方式端口分配一側分配奇，另一側分配偶。但由于配置原因有一側沒有進行主備檢測，導致這一側奇偶都分，所以導致端口沖突。

防火墻修正配置后，重新進行測試指標大幅改善，確認問題解決：

1. 新浪網頁30次頁面打開時延非常穩(wěn)定，沒有出現(xiàn)大于1 s的時延情況，平均0.59 s。相對于之前測試的1.42 s，改善58.5%，測試結果參見下圖。

配置修正后sina.com采樣統(tǒng)計結果

2. 7個網頁輪詢30次匯總平均結果，總體平均時延0.7 s。相對于之前1.63 s，改善57%，測試結果參見表6。

表6 配置修正后7個網頁輪詢30次匯總結果

表6 配置修正后7個網頁輪詢30次匯總結果

（百度受自身網頁流程原因，各地及不同運營商測試結果均偏大，當前1.13 s相對于之前平均2.68s 改善57.84%。）