從測試的角度，應該建立實時監控的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、iTunes Connect賬戶無法登錄；京東因為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可能會比實際所需要的大很多，那么對于整體網絡服務耗時影響非常大。
問題五：復雜的國內外網絡情況
國內運營商互聯和海外訪問國內帶寬低傳輸慢的問題也令人難非常頭疼。
TestBird
