從測試的角度，應該建立實時監控的web portal。其實測試的目的除了保證產品釋出的質量。更重要的是為優化提供依據，所以report最後一部分都是issue list 和optmize advice，當然測試最難的部分也是優化

行動網路和傳統網路另一個很大的區別是Connection Migration問題。定義一個Socket連線是四元組（客戶端IP，客戶端Port，服務端IP，服務端Port），當用戶的網路在WIFI/4G/3G/2G型別中切換時，其客戶端IP會發生變化，如果此時正在進行網路服務通訊，那麼Socket連線自身已經失效，最終也會導致網路服務失敗。

常見的網路效能問題有如下幾種：

問題一：DNS問題

DNS出問題的概率其實比大家感覺的要大，首先是DNS被劫持或者失效，2015年初業內比較知名的就有Apple內部DNS問題導致App Store、iTunesConnect賬戶無法登入；京東因為CDN域名付費問題導致服務停擺。攜程在去年11月也遇到過DNS問題，主域名被國外服務商誤列入黑名單，導致主站和H5等所有站點無法訪問，但是App客戶端的Native服務都正常，原因後面介紹。

另一個常見問題就是DNS解析慢或者失敗，例如國內中國運營商網路的DNS就很慢，一次DNS查詢的耗時甚至都能趕上一次連線的耗時，尤其2G網路情況下，DNS解析失敗是很常見的。因此如果直接使用DNS，對於首次網路服務請求耗時和整體服務成功率都有非常大的影響。

問題二：TCP連線問題

DNS成功後拿到IP，便可以發起TCP連線。HTTP協議的網路層也是TCP連線，因此TCP連線的成功和耗時也成為網路效能的一個因素。我們發現常見的問題有TCP埠被封（例如上海長寬對非HTTP常見埠80、8080、443的封鎖），以及TCP連線超時時長問題。埠被封，直接導致無法連線；連線超時時長過短，在低速網路上可能總是無法連線成果；連線超時過長，又有可能導致使用者長時間等待，使用者體驗差。很多時候儘快失敗重新發起一次連線會很快，這也是行動網路頻寬不穩定情況下的一個常見情況。

問題三：Write/Read問題

DNS Lookup和TCP連線成功後，就會開始傳送Request，服務端處理後返回Response，如果是HTTP連線，業內大部分App是使用第三方SDK或者系統提供的API來實現，那麼只能設定些快取策略和超時時間。iOS上的NSURLConnection超時時間在不同版本上還有不同的定義，很多時候需要自己設定Timer來實現；如果是直接使用TCP連線實現網路服務，就要自己對讀寫超時時間負責，與網路連線超時時長引數類似，太小了在低速網路很容易讀寫失敗，太大了又可能影響使用者體驗，因此需要非常小心地處理。

我們還遇到另一類問題，某些酒店Wi-Fi對使用非80、8080和443等常見HTTP埠的服務進行了限制，即使傳送Request是正常的，服務端能夠正常收到，但是Response卻被酒店網路proxy或防火牆攔截，客戶端最終會等待讀取超時。

問題四：傳輸Payload過大

傳的多就傳的慢，如果沒做過特別優化，傳輸Payload可能會比實際所需要的大很多，那麼對於整體網路服務耗時影響非常大。

問題五：複雜的國內外網路情況

國內運營商互聯和海外訪問國內頻寬低傳輸慢的問題也令人難非常頭疼。