1、DNS映射
無論是HTTP還是Socket長連接最爬，第一步都要經(jīng)過DNS解析出ip涉馁，然后再根據(jù)ip去拿對應的資源。在這個過程中爱致，如果LocalDNS中存在這個域名對應的ip烤送，就會直接返回這個ip，類似于App內(nèi)做的緩存糠悯。如果不存在胯努，才會去權威DNS查詢該訪問哪個ip，然后查詢到的ip會在LocalDNS中做緩存逢防。然而在iOS設備上幾乎每次斷網(wǎng)重連，重啟設備都會使LocalDNS緩存失效蒲讯，觸發(fā)重新查詢忘朝。
同時，LocalDNS緩存的存在還會引發(fā)一些問題判帮。如果之前訪問api.weibo.cn的是聯(lián)通用戶局嘁，現(xiàn)在新用戶使用電信來訪問api.weibo.cn，由于localDNS緩存的存在晦墙，不會去查詢新浪的權威DNS悦昵，這樣返回的ip是聯(lián)通這個運營商的ip，從而會使得用戶出現(xiàn)訪問變慢等狀況晌畅。
緩存還會導致一點就是但指，當權威DNS將域名與ip的映射發(fā)生改變之后，由于LocalDNS緩存沒有及時改變抗楔，用戶就會訪問到錯誤的服務器棋凳，或者直接訪問不到資源。還有很多三四級運營商會把域名解析指向他們的緩存服務器上连躏，并把網(wǎng)頁里面的廣告替換成他們自己的剩岳，或者內(nèi)嵌他們自己的廣告。
HttpDNS基于Http協(xié)議和域名解析的流量調(diào)度解決方案入热，可以在很大程度上防止上面的問題出現(xiàn)拍棕。
HttpDNS原理：
A、客戶端直接訪問HttpDNS接口勺良，獲取業(yè)務在域名配置管理系統(tǒng)上配置的訪問延遲最優(yōu)的IP绰播。（基于容錯考慮，app內(nèi)肯定是需要保留使用運營商LocalDNS解析域名方式的尚困。）
B幅垮、客戶端獲取到IP后就直接往此IP發(fā)送業(yè)務協(xié)議請求。以Http請求為例，通過在header中指定host字段忙芒，向HttpDNS返回的IP發(fā)送標準的Http請求即可示弓。
基于HttpDNS擴展：
A、在App內(nèi)維護一個Serve IP List呵萨。把每次App從HttpDNS取到的ip存儲進入該數(shù)組奏属，并設置權重，理論上來說從HttpDns解析下來的ip權重是最大的潮峦。這個List可以在App啟動的時候囱皿，進行更新，同時取出本地緩存的Serve IP List的權重最大的ip進行數(shù)據(jù)的初始化操作（如果第一次啟動忱嘹，沒有該List的話嘱腥，就使用LocalDNS進行解析）。Serve IP List里面的權重設置機制拘悦，很明顯的一點就是從DNS解析出來的ip具有最大的權重齿兔，每次從List里面取ip應該要取權重最大的ip。列表中的ip也是需要可以動態(tài)更新配置的础米，根據(jù)連接或者服務的成功失敗來進行動態(tài)調(diào)整分苇，這樣即使DNS解析失敗，用戶在一段時間后也會取到合適的ip進行訪問屁桑。
B医寿、對ip進行數(shù)據(jù)統(tǒng)計。在所有app內(nèi)統(tǒng)計每個ip進行請求所需平均時間蘑斧、最長時間靖秩、最短時間、請求成功次數(shù)竖瘾、失敗次數(shù)盆偿，需要注意的是，要區(qū)分網(wǎng)絡環(huán)境進行統(tǒng)計准浴，Wifi事扭、4G、3G乐横，對在不同的網(wǎng)絡環(huán)境下數(shù)據(jù)優(yōu)秀的ip進行存儲求橄，下發(fā)到App里面使用起來。這樣每次啟動App時可以對收集起來的ip根據(jù)不同的網(wǎng)絡環(huán)境進行測速葡公，選擇最好的ip進行請求罐农。需要注意的是，在網(wǎng)絡環(huán)境切換的時候催什，必須要重新進行速度測試涵亏。做到這一步，可以節(jié)約DNS解析時間，以及劫持的問題气筋。
C拆内、將圖片、音頻等資源放到單獨的服務器里面宠默，與其他資源分開麸恍。第一個是多個域名可以增加并行下載條數(shù)，因為客戶端對同一個域的域名下載條數(shù)是有限制的搀矫，所以多個域就會增加并行下載條數(shù)抹沪，從而加快加載速度。當然二級域名也不能使用太多瓤球，因為太多要考慮到dns的解析花費的時間融欧。第二個是方便管理，一般來說卦羡，圖片在站點的加載中是最占帶寬的噪馏，可以用獨立服務器方便后期管理；還可以使用異步加載的方式虹茶，增強用戶體驗。同時是圖片多是靜態(tài)內(nèi)容隅要，可以更好的使用CDN加速蝴罪。第三是如果使用了獨立服務器的話，在安全設置上可以有差別的針對設置步清，很是方便要门。
D、在防止劫持這一塊廓啊，需要注意把資源的后綴名去掉欢搜，比如說.mp3、.json這樣的后綴谴轮，以免擊中運營商的攔截炒瘟。
總的來說，采用HttpDNS來解析域名第步，就繞過了三四級運營商解析域名會出現(xiàn)的問題疮装，在HttpDNS返回了正確的ip之后，我們是直接采用ip去進行http請求粘都，只需要關注通信內(nèi)容的安全即可廓推。
2、資源優(yōu)化
資源優(yōu)化基本就是盡可能的縮小傳輸數(shù)據(jù)的大小翩隧，選擇合適的數(shù)據(jù)格式樊展。
1、首先是圖片大小的解決方案，在一定程度上使用webp來代替jpg专缠、png圖片雷酪，各種圖片同等質(zhì)量下的大小，webp是最小的藤肢。
2太闺、可以使用ProtocolBuffer代替Json進行數(shù)據(jù)傳輸，因為ProtocolBuffer數(shù)據(jù)比Json更小嘁圈，也是跨平臺的省骂，序列化與反序列化也很簡單。
3最住、請求壓縮
DNS查詢之后是TCP握手建立連接钞澳，并發(fā)送請求數(shù)據(jù)。對于TCP來說涨缚，單個IP包大小受限于MSS值轧粟，大部分用戶所處網(wǎng)絡環(huán)境下每個包的大小約在1.5KB，新建立的HTTP連接由于TCP的slow start特性脓魏，會導致本地的部分IP包被臨時緩存兰吟，從而增加了整體request的延遲。所以我們應該盡可能嘗試去壓縮我們的網(wǎng)絡請求業(yè)務數(shù)據(jù)茂翔，減少一個Request的IP包數(shù)量混蔼，或許可以讓用戶少經(jīng)歷一個RTT，降低請求延遲的用戶感知珊燎。
4惭嚣、請求合并
對于非關鍵性的業(yè)務數(shù)據(jù)，或者對實時性要求不高的請求來說悔政，通過合并請求的方式可以減少和服務器交互的次數(shù)晚吞，一則降低服務器壓力，二則合并之后再壓縮能節(jié)約客戶端的流量谋国。這類請求一般見于打點SDK槽地，crash日志收集等非業(yè)務型請求。
5芦瘾、請求的安全性
盡量使用HTTPS來保證基本的網(wǎng)絡安全闷盔。對于敏感數(shù)據(jù)，采用MD5旅急、AES逢勾、DES、RSA等加密方式來保證數(shù)據(jù)的安全傳輸藐吮，防止被攔截及篡改溺拱。
6逃贝、合理的并發(fā)數(shù)
有些業(yè)務場景會出現(xiàn)多個Request集中產(chǎn)生的情況，此時我們需要設置一個合理的并發(fā)數(shù)迫摔。并發(fā)數(shù)如果太小沐扳，會導致“劣質(zhì)”的請求block住“優(yōu)質(zhì)”的請求。如果并發(fā)數(shù)太大句占，帶寬有限的場景下沪摄，會增加請求的整體延遲。
7纱烘、數(shù)據(jù)緩存
1杨拐、使用HTTP緩存，減少請求次數(shù)擂啥，減小傳輸量（能不傳body就不傳）HTTP網(wǎng)絡緩存減少了需要向服務器發(fā)送請求的次數(shù)哄陶。當一個請求完成下載來自服務器的回應，一個緩存的回應將在本地保存哺壶。下一次同一個請求再發(fā)起時屋吨，本地保存的回應就會馬上返回，不需要連接服務器山宾。NSURLCache就干這個至扰，既可以緩存在Memory，又可以緩存在Disk上资锰。
2敢课、將Html，JS台妆，CSS等網(wǎng)頁靜態(tài)文件存在手機上翎猛，標記版本胖翰，建立合適的更新機制接剩。利用NSURLProtocol做網(wǎng)頁的緩存（第一次），將網(wǎng)絡IO改變?yōu)楸镜豂O萨咳，提高H5體驗懊缺。
8、可靠性保障
可靠性保障也是個容易被忽視的方面培他，在深入探討之前鹃两，可以先將Request按業(yè)務屬性分類。
- 第一類：關鍵核心的業(yè)務數(shù)據(jù)舀凛，期望能100%送達服務器俊扳。
- 第二類：重要內(nèi)容請求，需要較高的請求成功率猛遍。
- 第三類：一般性內(nèi)容請求馋记，對成功率無要求号坡。
之所以要將請求分為三類，是要在可靠性保障上做區(qū)分梯醒。理論上我們應該盡可能讓所有的請求成功率達到最高宽堆，但客戶端的流量，帶寬茸习，手機電量畜隶，服務器的壓力等都是有限的資源，所以我們采取的策略是只對關鍵性的網(wǎng)絡請求做高強度的可靠性保障号胚。
第一類請求類似大家用微信時發(fā)送的消息籽慢，消息數(shù)據(jù)一旦從輸入框發(fā)出，從用戶來的角度感知這個消息數(shù)據(jù)是一定會到達對方的涕刚。如果網(wǎng)絡環(huán)境差嗡综，網(wǎng)絡模塊會自動在后頭悄悄重試，一段時間后仍無法成功就通過產(chǎn)品交互的方式告知用戶發(fā)送失敗了杜漠，即使失敗极景，請求的數(shù)據(jù)（消息本身）一直存在客戶端。
對于這類請求的處理方式驾茴，第一步不是通過網(wǎng)絡發(fā)送盼樟，而是先將請求持久化到DB當中。一旦入了DB锈至，即使斷網(wǎng)晨缴，斷電，重啟峡捡，請求數(shù)據(jù)依然還在击碗，只需在App重啟的時候還原請求數(shù)據(jù)，再次發(fā)送即可们拙。第二步發(fā)送請求稍途，如果請求失敗則將請求加入重試隊列，成功則從重試隊列中移除砚婆。重試隊列背后也需要一套通用機制械拍，比如多久重試一次，重試幾次之后放棄装盯。遇到最惡劣的場景坷虑，請求發(fā)送失敗之后，App被kill埂奈。我們需要在App重啟之后從DB當中重新load所有失敗的請求再次重試迄损。
如果判斷為第一類請求，通過上述幾步基本上可以使請求的可靠性得到極大的保障账磺，但100%是很難實現(xiàn)的芹敌。如果請求失敗的時候用戶重裝App共屈，所有持久化的數(shù)據(jù)丟失，請求數(shù)據(jù)也就丟了党窜，不過這種極端的場景非常少拗引。
第二類請求的例子可以是我們App啟動時用戶看到的首頁，首頁的內(nèi)容從服務器獲取幌衣，如果第一次請求就失敗體驗較差矾削，這種場景下我們應該允許請求有機會多試幾次，增加一個retryCount即可豁护。一般3次的重試基本可以排除網(wǎng)絡抖動的情況哼凯。三次失敗之后即可認為請求失敗，通過產(chǎn)品交互告知用戶楚里。
第三類請求的重要性最低断部，比如進入Controller的UV采集打點。這類請求只需要做一次班缎，即使失敗也不會對產(chǎn)品體驗產(chǎn)生什么負面影響蝴光。
9、多通道
現(xiàn)在不少有技術條件的團隊都有自己的tcp長連接通道达址，技術再硬點的甚至配有UDP通道蔑祟，UDP在丟包率高的網(wǎng)絡環(huán)境下能極大的提高請求成功的概率。如果能同時具備HTTP沉唠，TCP疆虚，UDP三條網(wǎng)絡通道满葛，在某些場景下径簿，如果不考慮流量（比如wifi），可以針對某個網(wǎng)絡請求嘀韧，兩通道或者三通道齊發(fā)，對請求成功的速度和可靠性有明顯的療效乳蛾，不過客戶端和服務器都需要針對業(yè)務場景做去重。UDP在VOIP服務當中使用較多，不過據(jù)說淘寶這類大廠也部分啟用了UDP绩衷。
10激率、網(wǎng)絡環(huán)境監(jiān)控
現(xiàn)在網(wǎng)絡環(huán)境雖然越來越好，Wifi阎曹，4G，3G在一二線城市都有很好的普及嘉冒，但還是有不少場景會導致網(wǎng)絡狀態(tài)突然變差，比如進電梯咆繁，坐火車讳推，人多的集會場所，從公司回家4G切Wifi等等玩般，這些場景在生活當中并不少見银觅，健壯的網(wǎng)絡模塊需要仔細的檢測網(wǎng)絡的變化，針對性的做請求重試坏为。
11究驴、請求成功率監(jiān)控
網(wǎng)絡模塊應該能監(jiān)控當前App的網(wǎng)絡請求成功率，對于失敗率較高的請求匀伏，帶上業(yè)務數(shù)據(jù)纳胧，手機網(wǎng)絡環(huán)境，系統(tǒng)參數(shù)等等帘撰，在用戶不活躍的時候能打包上報給server端跑慕，一則能找出更多需要優(yōu)化的業(yè)務場景，二則能實時監(jiān)控server端的健康狀態(tài)摧找，三則能從數(shù)據(jù)層面精確判斷每一次網(wǎng)絡優(yōu)化是否有成效核行。
