從測(cè)試的角度，應(yīng)該建立實(shí)時(shí)監(jiān)控的web portal。其實(shí)測(cè)試的目的除了保證產(chǎn)品發(fā)布的質(zhì)量。更重要的是為優(yōu)化提供依據(jù)，所以report最后一部分都是issue list 和optmize advice，當(dāng)然測(cè)試最難的部分也是優(yōu)化
移動(dòng)網(wǎng)絡(luò)和傳統(tǒng)網(wǎng)絡(luò)另一個(gè)很大的區(qū)別是Connection Migration問(wèn)題。定義一個(gè)Socket連接是四元組（客戶端IP，客戶端Port，服務(wù)端IP，服務(wù)端Port），當(dāng)用戶的網(wǎng)絡(luò)在WIFI/4G/3G/2G類型中切換時(shí)，其客戶端IP會(huì)發(fā)生變化，如果此時(shí)正在進(jìn)行網(wǎng)絡(luò)服務(wù)通訊，那么Socket連接自身已經(jīng)失效，最終也會(huì)導(dǎo)致網(wǎng)絡(luò)服務(wù)失敗。
常見(jiàn)的網(wǎng)絡(luò)性能問(wèn)題有如下幾種：
問(wèn)題一：DNS問(wèn)題
DNS出問(wèn)題的概率其實(shí)比大家感覺(jué)的要大，首先是DNS被劫持或者失效，2015年初業(yè)內(nèi)比較知名的就有Apple內(nèi)部DNS問(wèn)題導(dǎo)致App Store、iTunes Connect賬戶無(wú)法登錄；京東因?yàn)镃DN域名付費(fèi)問(wèn)題導(dǎo)致服務(wù)停擺。攜程在去年11月也遇到過(guò)DNS問(wèn)題，主域名被國(guó)外服務(wù)商誤列入黑名單，導(dǎo)致主站和H5等所有站點(diǎn)無(wú)法訪問(wèn)，但是App客戶端的Native服務(wù)都正常，原因后面介紹。
另一個(gè)常見(jiàn)問(wèn)題就是DNS解析慢或者失敗，例如國(guó)內(nèi)中國(guó)運(yùn)營(yíng)商網(wǎng)絡(luò)的DNS就很慢，一次DNS查詢的耗時(shí)甚至都能趕上一次連接的耗時(shí)，尤其2G網(wǎng)絡(luò)情況下，DNS解析失敗是很常見(jiàn)的。因此如果直接使用DNS，對(duì)于首次網(wǎng)絡(luò)服務(wù)請(qǐng)求耗時(shí)和整體服務(wù)成功率都有非常大的影響。
問(wèn)題二：TCP連接問(wèn)題
DNS成功后拿到IP，便可以發(fā)起TCP連接。HTTP協(xié)議的網(wǎng)絡(luò)層也是TCP連接，因此TCP連接的成功和耗時(shí)也成為網(wǎng)絡(luò)性能的一個(gè)因素。我們發(fā)現(xiàn)常見(jiàn)的問(wèn)題有TCP端口被封（例如上海長(zhǎng)寬對(duì)非HTTP常見(jiàn)端口80、8080、443的封鎖），以及TCP連接超時(shí)時(shí)長(zhǎng)問(wèn)題。端口被封，直接導(dǎo)致無(wú)法連接；連接超時(shí)時(shí)長(zhǎng)過(guò)短，在低速網(wǎng)絡(luò)上可能總是無(wú)法連接成果；連接超時(shí)過(guò)長(zhǎng)，又有可能導(dǎo)致用戶長(zhǎng)時(shí)間等待，用戶體驗(yàn)差。很多時(shí)候盡快失敗重新發(fā)起一次連接會(huì)很快，這也是移動(dòng)網(wǎng)絡(luò)帶寬不穩(wěn)定情況下的一個(gè)常見(jiàn)情況。
問(wèn)題三：Write/Read問(wèn)題
DNS Lookup和TCP連接成功后，就會(huì)開(kāi)始發(fā)送Request，服務(wù)端處理后返回Response，如果是HTTP連接，業(yè)內(nèi)大部分App是使用第三方SDK或者系統(tǒng)提供的API來(lái)實(shí)現(xiàn)，那么只能設(shè)置些緩存策略和超時(shí)時(shí)間。iOS上的NSURLConnection超時(shí)時(shí)間在不同版本上還有不同的定義，很多時(shí)候需要自己設(shè)置Timer來(lái)實(shí)現(xiàn)；如果是直接使用TCP連接實(shí)現(xiàn)網(wǎng)絡(luò)服務(wù)，就要自己對(duì)讀寫超時(shí)時(shí)間負(fù)責(zé)，與網(wǎng)絡(luò)連接超時(shí)時(shí)長(zhǎng)參數(shù)類似，太小了在低速網(wǎng)絡(luò)很容易讀寫失敗，太大了又可能影響用戶體驗(yàn)，因此需要非常小心地處理。
我們還遇到另一類問(wèn)題，某些酒店Wi-Fi對(duì)使用非80、8080和443等常見(jiàn)HTTP端口的服務(wù)進(jìn)行了限制，即使發(fā)送Request是正常的，服務(wù)端能夠正常收到，但是Response卻被酒店網(wǎng)絡(luò)proxy或防火墻攔截，客戶端最終會(huì)等待讀取超時(shí)。
問(wèn)題四：傳輸Payload過(guò)大
傳的多就傳的慢，如果沒(méi)做過(guò)特別優(yōu)化，傳輸Payload可能會(huì)比實(shí)際所需要的大很多，那么對(duì)于整體網(wǎng)絡(luò)服務(wù)耗時(shí)影響非常大。
問(wèn)題五：復(fù)雜的國(guó)內(nèi)外網(wǎng)絡(luò)情況
國(guó)內(nèi)運(yùn)營(yíng)商互聯(lián)和海外訪問(wèn)國(guó)內(nèi)帶寬低傳輸慢的問(wèn)題也令人難非常頭疼。
TestBird
