一般開發(fā)一個(gè) APP，會(huì)直接調(diào)用系統(tǒng)提供的網(wǎng)絡(luò)請求接口去服務(wù)端請求數(shù)據(jù)，再針對返回的數(shù)據(jù)進(jìn)行一些處理，或者使用AFNetworking/OKHttp這樣的網(wǎng)絡(luò)庫，管理好請求線程和隊(duì)列，再自動(dòng)做一些數(shù)據(jù)解析，就結(jié)束了。

但對于一些大型 APP，還會(huì)想針對網(wǎng)絡(luò)的一些問題進(jìn)行進(jìn)一步優(yōu)化，包括：

1. 速度：網(wǎng)絡(luò)請求的速度怎樣能進(jìn)一步提升?
2. 弱網(wǎng)：移動(dòng)端網(wǎng)絡(luò)環(huán)境隨時(shí)變化，經(jīng)常出現(xiàn)網(wǎng)絡(luò)連接很不穩(wěn)定可用性差的情況，怎樣在這種情況下最大限度最快地成功請求?
3. 安全：怎樣防止被第三方竊聽/篡改或冒充，防止運(yùn)營商劫持，同時(shí)又不影響性能?

對基于瀏覽器的前端開發(fā)來說，網(wǎng)絡(luò)這塊能做的事情很少，但對于客戶端 APP 來說，整個(gè)網(wǎng)絡(luò)請求過程是自由控制的，可以做很多事情，很多大型 APP 都針對這三個(gè)問題做了很多網(wǎng)絡(luò)層的優(yōu)化，一些新的網(wǎng)絡(luò)層協(xié)議像 HTTP2 / QUIC 也是在這些方面進(jìn)行了不少優(yōu)化，在這里邊學(xué)習(xí)邊整理，大致列舉一下常見的做法。

速度

正常一條網(wǎng)絡(luò)請求需要經(jīng)過的流程是這樣：

• DNS 解析，請求DNS服務(wù)器，獲取域名對應(yīng)的 IP 地址。
• 與服務(wù)端建立連接，包括 tcp 三次握手，安全協(xié)議同步流程。
• 連接建立完成，發(fā)送和接收數(shù)據(jù)，解碼數(shù)據(jù)。

這里有明顯的三個(gè)優(yōu)化點(diǎn)：

• 直接使用 IP 地址，去除 DNS 解析步驟。
• 不要每次請求都重新建立連接，復(fù)用連接或一直使用同一條連接(長連接)。
• 壓縮數(shù)據(jù)，減小傳輸?shù)臄?shù)據(jù)大小。

逐條來看能做什么。

1.DNS

DNS 完整的解析流程很長，會(huì)先從本地系統(tǒng)緩存取，若沒有就到最近的 DNS 服務(wù)器取，若沒有再到主域名服務(wù)器取，每一層都有緩存，但為了域名解析的實(shí)時(shí)性，每一層緩存都有過期時(shí)間，這種 DNS 解析機(jī)制有幾個(gè)缺點(diǎn)：

緩存時(shí)間設(shè)置得長，域名更新不及時(shí)，設(shè)置得短，大量 DNS 解析請求影響請求速度。

域名劫持，容易被中間人攻擊，或被運(yùn)營商劫持，把域名解析到第三方 IP 地址，據(jù)統(tǒng)計(jì)劫持率會(huì)達(dá)到7%。

DNS 解析過程不受控制，無法保證解析到最快的IP

一次請求只能解析一個(gè)域名。

為了解決這些問題，就有了 HTTPDNS，原理很簡單，就是自己做域名解析的工作，通過 HTTP 請求后臺(tái)去拿到域名對應(yīng)的 IP 地址，直接解決上述所有問題：

域名解析與請求分離，所有請求都直接用IP地址，無需 DNS 解析，APP 定時(shí)請求 HTTPDNS 服務(wù)器更新IP地址即可。

通過簽名等方式，保證 HTTPDNS 請求的安全，避免被劫持。

DNS 解析由自己控制，可以確保根據(jù)用戶所在地返回就近的 IP 地址，或根據(jù)客戶端測速結(jié)果使用速度最快的 IP。

一次請求可以解析多個(gè)域名。

其余細(xì)節(jié)就不多說了，HTTPDNS 優(yōu)點(diǎn)這么多，幾乎成為中大型 APP 的標(biāo)配。至此解決了第一個(gè)問題 — DNS 解析耗時(shí)的問題，順便把一部分安全問題 — DNS 劫持也解決了。

2.連接

第二個(gè)問題，連接建立耗時(shí)的問題，這里主要的優(yōu)化思路是復(fù)用連接，不用每次請求都重新建立連接，如何更有效率地復(fù)用連接，可以說是網(wǎng)絡(luò)請求速度優(yōu)化里最主要的點(diǎn)了，并且這里的優(yōu)化仍在演進(jìn)過程中，值得了解下。

keep-alive

HTTP 協(xié)議里有個(gè) keep-alive，HTTP1.1默認(rèn)開啟，一定程度上緩解了每次請求都要進(jìn)行TCP三次握手建立連接的耗時(shí)。原理是請求完成后不立即釋放連接，而是放入連接池中，若這時(shí)有另一個(gè)請求要發(fā)出，請求的域名和端口是一樣的，就直接拿出連接池中的連接進(jìn)行發(fā)送和接收數(shù)據(jù)，少了建立連接的耗時(shí)。

實(shí)際上現(xiàn)在無論是客戶端還是瀏覽器都默認(rèn)開啟了keep-alive，對同個(gè)域名不會(huì)再有每發(fā)一個(gè)請求就進(jìn)行一次建連的情況，純短連接已經(jīng)不存在了。但有個(gè)問題，就是這個(gè) keep-alive 的連接一次只能發(fā)送接收一個(gè)請求，在上一個(gè)請求處理完成之前，無法接受新的請求。若同時(shí)發(fā)起多個(gè)請求，就有兩種情況：

若串行發(fā)送請求，可以一直復(fù)用一個(gè)連接，但速度很慢，每個(gè)請求都要等待上個(gè)請求完成再進(jìn)行發(fā)送。

若并行發(fā)送這些請求，那么首次每個(gè)請求都要進(jìn)行tcp三次握手建立新的連接，雖然第二次可以復(fù)用連接池里這堆連接，但若連接池里保持的連接過多，對服務(wù)端資源產(chǎn)生較大浪費(fèi)，若限制了保持的連接數(shù)，并行請求里超出的連接仍每次要建連。

對這個(gè)問題，新一代協(xié)議 HTTP2 提出了多路復(fù)用去解決。

多路復(fù)用

HTTP2 的多路復(fù)用機(jī)制一樣是復(fù)用連接，但它復(fù)用的這條連接支持同時(shí)處理多條請求，所有請求都可以并發(fā)在這條連接上進(jìn)行，也就解決了上面說的并發(fā)請求需要建立多條連接帶來的問題，網(wǎng)絡(luò)上有張圖可以較形象地表現(xiàn)這個(gè)過程：

HTTP1.1的協(xié)議里，在一個(gè)連接里傳送數(shù)據(jù)都是串行順序傳送的，必須等上一個(gè)請求全部處理完后，下一個(gè)請求才能進(jìn)行處理，導(dǎo)致這些請求期間這條連接并不是滿帶寬傳輸?shù)模词故荋TTP1.1的pipelining可以同時(shí)發(fā)送多個(gè)request，但response仍是按請求的順序串行返回，只要其中一個(gè)請求的response稍微大一點(diǎn)或發(fā)生錯(cuò)誤，就會(huì)阻塞住后面的請求。

HTTP2 這里的多路復(fù)用協(xié)議解決了這些問題，它把在連接里傳輸?shù)臄?shù)據(jù)都封裝成一個(gè)個(gè)stream，每個(gè)stream都有標(biāo)識(shí)，stream的發(fā)送和接收可以是亂序的，不依賴順序，也就不會(huì)有阻塞的問題，接收端可以根據(jù)stream的標(biāo)識(shí)去區(qū)分屬于哪個(gè)請求，再進(jìn)行數(shù)據(jù)拼接，得到最終數(shù)據(jù)。

解釋下多路復(fù)用這個(gè)詞，多路可以認(rèn)為是多個(gè)連接，多個(gè)操作，復(fù)用就是字面上的意思，復(fù)用一條連接或一個(gè)線程。HTTP2這里是連接的多路復(fù)用，網(wǎng)絡(luò)相關(guān)的還有一個(gè)I/O的多路復(fù)用(select/epoll)，指通過事件驅(qū)動(dòng)的方式讓多個(gè)網(wǎng)絡(luò)請求返回的數(shù)據(jù)在同一條線程里完成讀寫。

客戶端來說，iOS9 以上 NSURLSession 原生支持 HTTP2，只要服務(wù)端也支持就可以直接使用，Android 的 okhttp3 以上也支持了 HTTP2，國內(nèi)一些大型 APP 會(huì)自建網(wǎng)絡(luò)層，支持 HTTP2 的多路復(fù)用，避免系統(tǒng)的限制以及根據(jù)自身業(yè)務(wù)需要增加一些特性，例如微信的開源網(wǎng)絡(luò)庫 mars，做到一條長連接處理微信上的大部分請求，多路復(fù)用的特性上基本跟 HTTP2 一致。

TCP隊(duì)頭阻塞

HTTP2 的多路復(fù)用看起來是完美的解決方案，但還有個(gè)問題，就是隊(duì)頭阻塞，這是受限于 TCP 協(xié)議，TCP 協(xié)議為了保證數(shù)據(jù)的可靠性，若傳輸過程中一個(gè) TCP 包丟失，會(huì)等待這個(gè)包重傳后，才會(huì)處理后續(xù)的包。HTTP2的多路復(fù)用讓所有請求都在同一條連接進(jìn)行，中間有一個(gè)包丟失，就會(huì)阻塞等待重傳，所有請求也就被阻塞了。

對于這個(gè)問題不改變 TCP 協(xié)議就無法優(yōu)化，但 TCP 協(xié)議依賴操作系統(tǒng)實(shí)現(xiàn)以及部分硬件的定制，改進(jìn)緩慢，于是 GOOGLE 提出 QUIC 協(xié)議，相當(dāng)于在 UDP 協(xié)議之上再定義一套可靠傳輸協(xié)議，解決 TCP 的一些缺陷，包括隊(duì)頭阻塞。具體解決原理網(wǎng)上資料較多，可以看看。

QUIC 處于起步階段，少有客戶端接入，QUIC 協(xié)議相對于 HTTP2 最大的優(yōu)勢是對TCP隊(duì)頭阻塞的解決，其他的像安全握手 0RTT / 證書壓縮等優(yōu)化 TLS1.3 已跟進(jìn)，可以用于 HTTP2，并不是獨(dú)有特性。TCP 隊(duì)頭阻塞在 HTTP2 上對性能的影響有多大，在速度上 QUIC 能帶來多大提升待研究。

3.數(shù)據(jù)

第三個(gè)問題，傳輸數(shù)據(jù)大小的問題。數(shù)據(jù)對請求速度的影響分兩方面，一是壓縮率，二是解壓序列化反序列化的速度。目前最流行的兩種數(shù)據(jù)格式是 json 和 protobuf，json 是字符串，protobuf 是二進(jìn)制，即使用各種壓縮算法壓縮后，protobuf 仍會(huì)比 json 小，數(shù)據(jù)量上 protobuf 有優(yōu)勢，序列化速度 protobuf 也有一些優(yōu)勢，這兩者的對比就不細(xì)說了。

壓縮算法多種多樣，也在不斷演進(jìn)，最新出的 Brotli 和Z-standard實(shí)現(xiàn)了更高的壓縮率，Z-standard 可以根據(jù)業(yè)務(wù)數(shù)據(jù)樣本訓(xùn)練出適合的字典，進(jìn)一步提高壓縮率，目前壓縮率表現(xiàn)最好的算法。

除了傳輸?shù)?body 數(shù)據(jù)，每個(gè)請求 HTTP 協(xié)議頭的數(shù)據(jù)也是不可忽視，HTTP2 里對 HTTP 協(xié)議頭也進(jìn)行了壓縮，HTTP 頭大多是重復(fù)數(shù)據(jù)，固定的字段如 method 可以用靜態(tài)字典，不固定但多個(gè)請求重復(fù)的字段例如 cookie 用動(dòng)態(tài)字典，可以達(dá)到非常高的壓縮率，這里有詳細(xì)介紹。

通過 HTTPDNS，連接多路復(fù)用，更好的數(shù)據(jù)壓縮算法，可以把網(wǎng)絡(luò)請求的速度優(yōu)化到較不錯(cuò)的程度了，接下來再看看弱網(wǎng)和安全上可以做的事情。

弱網(wǎng)

手機(jī)無線網(wǎng)絡(luò)環(huán)境不穩(wěn)定，針對弱網(wǎng)的優(yōu)化，微信有較多實(shí)踐和分享，包括：

提升連接成功率

復(fù)合連接，建立連接時(shí)，階梯式并發(fā)連接，其中一條連通后其他連接都關(guān)閉。這個(gè)方案結(jié)合串行和并發(fā)的優(yōu)勢，提高弱網(wǎng)下的連接成功率，同時(shí)又不會(huì)增加服務(wù)器資源消耗：

制定最合適的超時(shí)時(shí)間

對總讀寫超時(shí)(從請求到響應(yīng)的超時(shí))、首包超時(shí)、包包超時(shí)(兩個(gè)數(shù)據(jù)段之間的超時(shí))時(shí)間制定不同的計(jì)算方案，加快對超時(shí)的判斷，減少等待時(shí)間，盡早重試。這里的超時(shí)時(shí)間還可以根據(jù)網(wǎng)絡(luò)狀態(tài)動(dòng)態(tài)設(shè)定。

• 調(diào)優(yōu)TCP參數(shù)，使用TCP優(yōu)化算法。
• 對服務(wù)端的TCP協(xié)議參數(shù)進(jìn)行調(diào)優(yōu)，以及開啟各種優(yōu)化算法，使得適合業(yè)務(wù)特性和移動(dòng)端網(wǎng)絡(luò)環(huán)境，包括RTO初始值，混合慢啟動(dòng)，TLP，F(xiàn)-RTO等。
• 針對弱網(wǎng)的這些細(xì)致優(yōu)化未成為標(biāo)準(zhǔn)，系統(tǒng)網(wǎng)絡(luò)庫沒有內(nèi)置，不過前兩個(gè)客戶端優(yōu)化微信的開源網(wǎng)絡(luò)庫 mars 有實(shí)現(xiàn)，若有需要可以使用。

安全

標(biāo)準(zhǔn)協(xié)議 TLS 保證了網(wǎng)絡(luò)傳輸?shù)陌踩?，前身?SSL，不斷在演進(jìn)，目前最新是 TLS1.3。常見的 HTTPS 就是 HTTP 協(xié)議加上 TLS 安全協(xié)議。

安全協(xié)議概括性地說解決兩個(gè)問題：1.保證安全 2. 降低加密成本

在保證安全上：

1. 使用加密算法組合對傳輸數(shù)據(jù)加密，避免被竊聽和篡改。
2. 認(rèn)證對方身份，避免被第三方冒充。
3. 加密算法保持靈活可更新，防止定死算法被破解后無法更換，禁用已被破解的算法。

降低加密成本上：

1. 用對稱加密算法加密傳輸數(shù)據(jù)，解決非對稱加密算法的性能低以及長度限制問題。
2. 緩存安全協(xié)議握手后的密鑰等數(shù)據(jù)，加快第二次建連的速度。
3. 加快握手過程：2RTT-> 0RTT。加快握手的思路，就是原本客戶端和服務(wù)端需要協(xié)商使用什么算法后才能加密發(fā)送數(shù)據(jù)，變成通過內(nèi)置的公鑰和默認(rèn)的算法，在握手的同時(shí)就把數(shù)據(jù)發(fā)出去，也就是不需要等待握手就開始發(fā)送數(shù)據(jù)，達(dá)到0RTT。

這些點(diǎn)涉及的細(xì)節(jié)非常多，對 TLS 的介紹有一篇雄文，說得很詳細(xì)，在此推薦。

目前基本主流都支持 TLS1.2，iOS 網(wǎng)絡(luò)庫默認(rèn)使用 TLS1.2，Android4.4 以上支持 1.2。TLS1.3 iOS 還處于測試階段，Android 未查到消息。對于普通 APP，只要正確配置證書，TLS1.2 已經(jīng)能保證傳輸安全，只是在建連速度上會(huì)有所損耗，有一些大型 APP 像微信就自行實(shí)現(xiàn)了 TLS1.3 的部分協(xié)議，早一步全平臺(tái)支持。

最后

網(wǎng)絡(luò)優(yōu)化這個(gè)話題非常龐大，本文只是在學(xué)習(xí)過程中從優(yōu)化思路上列舉了目前業(yè)界常見的優(yōu)化點(diǎn)，還有很多細(xì)節(jié)很多更深入的優(yōu)化沒涉及到，網(wǎng)絡(luò)層實(shí)踐開發(fā)經(jīng)驗(yàn)不足，若有錯(cuò)誤歡迎指出。