當(dāng)我們開始關(guān)注 App 的用戶體驗(yàn)后，網(wǎng)絡(luò)通暢性和界面的流暢性是保證 App 好用的重要指標(biāo)熊户。近期對項(xiàng)目中的網(wǎng)絡(luò)數(shù)據(jù)進(jìn)行了簡單的分析萍膛，又對業(yè)界的一些方案做了調(diào)研，故寫此文做一下知識梳理嚷堡。
當(dāng)我們使用 App 的 時(shí)候蝗罗，如經(jīng)常遇到加載失敗或者小圈轉(zhuǎn)個(gè)不停的情況，那么很可能 App 的網(wǎng)絡(luò)性能出現(xiàn)了問題麦到，急需研發(fā)同學(xué)來進(jìn)行優(yōu)化绿饵。而對于開發(fā)人員來說，定位網(wǎng)絡(luò)問題又是十分艱難瓶颠，因?yàn)槌霈F(xiàn)網(wǎng)絡(luò)問題的用戶往往遙在天邊，你沒辦法進(jìn)行調(diào)試定位刺桃。那么建立完善的網(wǎng)絡(luò)監(jiān)控體系就顯得十分重要粹淋，通過海量數(shù)據(jù)的分析來對網(wǎng)絡(luò)問題精確定位。
通過對數(shù)據(jù)的分析以及調(diào)研瑟慈、用戶反饋桃移，發(fā)現(xiàn)移動端網(wǎng)絡(luò)常常存在如下的問題：
- 網(wǎng)絡(luò)成功率低，經(jīng)常請求失敗
- 用戶反饋 DNS 劫持葛碧，數(shù)據(jù)被篡改借杰，出現(xiàn)廣告和請求超時(shí)等情況
- 網(wǎng)絡(luò)延遲較長，且存在較多的長尾數(shù)據(jù)
- 經(jīng)過數(shù)據(jù)分析进泼，發(fā)現(xiàn)長連的時(shí)間明顯比短連的時(shí)間少 100ms 左右（短連指的是蔗衡，經(jīng)過DNS解析纤虽、 TCP 握手、 SSL 握手等一系列的過程建立連接绞惦，長連指的是直接復(fù)用前者的連接通道）
- 網(wǎng)絡(luò)經(jīng)常出現(xiàn)抖動逼纸，本來大部分請求都是 100ms 左右，突然冒出來一兩千毫秒的济蝉，甚至有10杰刽、20秒的延遲情況
-
HTTP 1.1的head of blocking情況存在，一個(gè)網(wǎng)絡(luò)抖動王滤，很容易影響后續(xù)的請求贺嫂，導(dǎo)致一連串的延遲較高請求（head of blocking：指的是在 HTTP 1.1 中，如果你發(fā)出1雁乡、2第喳、3 三個(gè)網(wǎng)絡(luò)請求，那么Response的順序 2蔗怠、3 要在第一個(gè)網(wǎng)絡(luò)請求之后） - 傳輸?shù)?
Payload太大墩弯，延遲高，易超時(shí) - 蘋果要求
HTTPS寞射，此時(shí)加入的SSL握手較耗時(shí)
針對上面一系列的問題渔工，業(yè)界已經(jīng)有很多解決方案，我在這里簡單列舉一些
面對這樣的網(wǎng)絡(luò)桥温，如何解決引矩？
對于 DNS 劫持的情況，業(yè)界的主要做法是 HTTPDNS 或者內(nèi)置 Server IP 列表侵浸⊥拢客戶端直接訪問 HttpDNS 接口，獲取業(yè)務(wù)在域名配置管理系統(tǒng)上配置的訪問延遲最優(yōu)的IP掏觉，獲取到IP后就直接往此IP發(fā)送業(yè)務(wù)協(xié)議請求区端，不需要使用本地運(yùn)營商解析域名，所以從根本避免了劫持問題澳腹，同時(shí)可以降低網(wǎng)絡(luò)延遲织盼，提高連接成功率。而建立 Server IP 列表酱塔，是在本地緩存一個(gè) IP 的映射表沥邻，此表可在App啟動時(shí)動態(tài)下發(fā)更新，訪問服務(wù)器時(shí)直接拿出 IP 發(fā)出請求羊娃。
傳輸?shù)?Payload 也直接影響了延遲唐全，并且對成功率有影響，對于數(shù)據(jù)的壓縮蕊玷，業(yè)界很多公司已經(jīng)開始使用 ProtoBuf 協(xié)議邮利，對于優(yōu)化的百分比我還沒有準(zhǔn)確的說數(shù)據(jù)結(jié)論弥雹，但是從大家的反饋來說，優(yōu)化效果明顯近弟。對于數(shù)據(jù)的壓縮缅糟，還可以考慮接入 HTTP 2.0，畢竟這是一個(gè)趨勢祷愉，也有較多公司已經(jīng)加入 HTTP 2.0窗宦，HTTP 2.0 通過頭部壓縮等方式也幫你減小了傳輸?shù)?Payload。
上面的問題其實(shí)很多是涉及到長連與短連的問題二鳄，對這個(gè)問題有較多的問題可以考慮
- 域名合并：淘寶赴涵、美團(tuán)等公司公布的方案中都有提到，就是將公司原來很多域名的情況订讼，合并為較少的幾個(gè)域名髓窜，為什么這么做呢？HTTP 的通道復(fù)用是基于域名劃分的欺殿，如果域名只有幾個(gè)寄纵，那么多數(shù)請求都可以在長連接通道進(jìn)行，這樣就可以降低延遲脖苏、增加成功率程拭。
- 盡早建立長連接，這樣其他的業(yè)務(wù)請求就可以復(fù)用長連接通道棍潘，加快訪問速度恃鞋。對于建立連接的時(shí)機(jī)，可以考慮多個(gè)方面亦歉，比如冷啟動恤浪，前后臺切換、網(wǎng)絡(luò)切換等
- 考慮接入
HTTP2.0肴楷，他們兩個(gè)都解決了HTTP 1.1的head of blocking水由，降低了網(wǎng)絡(luò)延遲，提供了更強(qiáng)大的多路復(fù)用技術(shù)赛蔫，還加入了流量控制绷杜、新的二進(jìn)制格式、Server Push濒募、請求優(yōu)先級和依賴等特性』幔或者接入 SPDY 瑰剃，但是目前覺得好像直接上 HTTP 2.0 比較合適 - 建立多通道，比如攜程筝野、美團(tuán)等公司都有自己
TCP晌姚、UDP通道粤剧，具有多域名共用通道，成功率三個(gè)九等誘人的功效挥唠。同時(shí)各大廠也對新的網(wǎng)絡(luò)協(xié)議抵恋，比如QUIC，進(jìn)行嘗試宝磨。Facebook還出一分享弧关，對QUIC改進(jìn)，實(shí)現(xiàn)TLS的0-RTT
再者還有一些其他可以考慮的點(diǎn)
- 加入 CDN 加速唤锉，動靜資源分離
- 對于埋點(diǎn)的數(shù)據(jù)世囊，也可以合并請求，減少流量
- App 網(wǎng)絡(luò)診斷
- 根據(jù)網(wǎng)絡(luò)情況窿祥，動態(tài)設(shè)置超時(shí)時(shí)間等
大禮包
- 2016年攜程App網(wǎng)絡(luò)服務(wù)通道治理和性能優(yōu)化實(shí)踐
- 萬人低頭時(shí)代株憾，支付寶APP無線網(wǎng)絡(luò)性能該如何保障
- 移動網(wǎng)絡(luò)下的性能優(yōu)化之網(wǎng)絡(luò)篇
- 深度優(yōu)化iOS網(wǎng)絡(luò)模塊
- 美團(tuán)點(diǎn)評移動網(wǎng)絡(luò)優(yōu)化實(shí)踐
- 全局精確流量調(diào)度新思路-HttpDNS服務(wù)詳解
- 對于網(wǎng)絡(luò)監(jiān)控、優(yōu)化的知識聚合
- 美柚：女性移動APP安全攻防戰(zhàn)
- 手機(jī)淘寶性能優(yōu)化
- iOS網(wǎng)絡(luò)請求優(yōu)化之DNS映射
