來源：bang，
blog.cnbang.net/tech/3531/
一般開發(fā)一個 APP，會直接調(diào)用系統(tǒng)提供的網(wǎng)絡(luò)請求接口去服務(wù)端請求數(shù)據(jù)，再針對返回的數(shù)據(jù)進行一些處理，或者使用AFNetworking/OKHttp這樣的網(wǎng)絡(luò)庫，管理好請求線程和隊列，再自動做一些數(shù)據(jù)解析，就結(jié)束了。
但對于一些大型 APP，還會想針對網(wǎng)絡(luò)的一些問題進行進一步優(yōu)化，包括：
速度：網(wǎng)絡(luò)請求的速度怎樣能進一步提升？
弱網(wǎng)：移動端網(wǎng)絡(luò)環(huán)境隨時變化，經(jīng)常出現(xiàn)網(wǎng)絡(luò)連接很不穩(wěn)定可用性差的情況，怎樣在這種情況下最大限度最快地成功請求？
安全：怎樣防止被第三方竊聽/篡改或冒充，防止運營商劫持，同時又不影響性能？
對基于瀏覽器的前端開發(fā)來說，網(wǎng)絡(luò)這塊能做的事情很少，但對于客戶端 APP 來說，整個網(wǎng)絡(luò)請求過程是自由控制的，可以做很多事情，很多大型 APP 都針對這三個問題做了很多網(wǎng)絡(luò)層的優(yōu)化，一些新的網(wǎng)絡(luò)層協(xié)議像 HTTP2 / QUIC 也是在這些方面進行了不少優(yōu)化，在這里邊學(xué)習(xí)邊整理，大致列舉一下常見的做法。
速度
正常一條網(wǎng)絡(luò)請求需要經(jīng)過的流程是這樣：
DNS 解析，請求DNS服務(wù)器，獲取域名對應(yīng)的 IP 地址。
與服務(wù)端建立連接，包括 tcp 三次握手，安全協(xié)議同步流程。
連接建立完成，發(fā)送和接收數(shù)據(jù)，解碼數(shù)據(jù)。
這里有明顯的三個優(yōu)化點：
直接使用 IP 地址，去除 DNS 解析步驟。
不要每次請求都重新建立連接，復(fù)用連接或一直使用同一條連接(長連接)。
壓縮數(shù)據(jù)，減小傳輸?shù)臄?shù)據(jù)大小。
逐條來看能做什么。
1.DNS
DNS 完整的解析流程很長，會先從本地系統(tǒng)緩存取，若沒有就到最近的 DNS 服務(wù)器取，若沒有再到主域名服務(wù)器取，每一層都有緩存，但為了域名解析的實時性，每一層緩存都有過期時間，這種 DNS 解析機制有幾個缺點：
緩存時間設(shè)置得長，域名更新不及時，設(shè)置得短，大量 DNS 解析請求影響請求速度。
域名劫持，容易被中間人攻擊，或被運營商劫持，把域名解析到第三方 IP 地址，據(jù)統(tǒng)計劫持率會達到7%。
DNS 解析過程不受控制，無法保證解析到最快的IP
一次請求只能解析一個域名。
為了解決這些問題，就有了 HTTPDNS，原理很簡單，就是自己做域名解析的工作，通過 HTTP 請求后臺去拿到域名對應(yīng)的 IP 地址，直接解決上述所有問題：
域名解析與請求分離，所有請求都直接用IP地址，無需 DNS 解析，APP 定時請求 HTTPDNS 服務(wù)器更新IP地址即可。
通過簽名等方式，保證 HTTPDNS 請求的安全，避免被劫持。
DNS 解析由自己控制，可以確保根據(jù)用戶所在地返回就近的 IP 地址，或根據(jù)客戶端測速結(jié)果使用速度最快的 IP。
一次請求可以解析多個域名。
其余細節(jié)就不多說了，HTTPDNS 優(yōu)點這么多，幾乎成為中大型 APP 的標配。至此解決了第一個問題 — DNS 解析耗時的問題，順便把一部分安全問題 — DNS 劫持也解決了。
2.連接
第二個問題，連接建立耗時的問題，這里主要的優(yōu)化思路是復(fù)用連接，不用每次請求都重新建立連接，如何更有效率地復(fù)用連接，可以說是網(wǎng)絡(luò)請求速度優(yōu)化里最主要的點了，并且這里的優(yōu)化仍在演進過程中，值得了解下。
keep-alive
HTTP 協(xié)議里有個 keep-alive，HTTP1.1默認開啟，一定程度上緩解了每次請求都要進行TCP三次握手建立連接的耗時。原理是請求完成后不立即釋放連接，而是放入連接池中，若這時有另一個請求要發(fā)出，請求的域名和端口是一樣的，就直接拿出連接池中的連接進行發(fā)送和接收數(shù)據(jù)，少了建立連接的耗時。
實際上現(xiàn)在無論是客戶端還是瀏覽器都默認開啟了keep-alive，對同個域名不會再有每發(fā)一個請求就進行一次建連的情況，純短連接已經(jīng)不存在了。但有個問題，就是這個 keep-alive 的連接一次只能發(fā)送接收一個請求，在上一個請求處理完成之前，無法接受新的請求。若同時發(fā)起多個請求，就有兩種情況：
若串行發(fā)送請求，可以一直復(fù)用一個連接，但速度很慢，每個請求都要等待上個請求完成再進行發(fā)送。
若并行發(fā)送這些請求，那么首次每個請求都要進行tcp三次握手建立新的連接，雖然第二次可以復(fù)用連接池里這堆連接，但若連接池里保持的連接過多，對服務(wù)端資源產(chǎn)生較大浪費，若限制了保持的連接數(shù)，并行請求里超出的連接仍每次要建連。
對這個問題，新一代協(xié)議 HTTP2 提出了多路復(fù)用去解決。
多路復(fù)用
HTTP2 的多路復(fù)用機制一樣是復(fù)用連接，但它復(fù)用的這條連接支持同時處理多條請求，所有請求都可以并發(fā)在這條連接上進行，也就解決了上面說的并發(fā)請求需要建立多條連接帶來的問題，網(wǎng)絡(luò)上有張圖可以較形象地表現(xiàn)這個過程：
?
HTTP1.1的協(xié)議里，在一個連接里傳送數(shù)據(jù)都是串行順序傳送的，必須等上一個請求全部處理完后，下一個請求才能進行處理，導(dǎo)致這些請求期間這條連接并不是滿帶寬傳輸?shù)模词故荋TTP1.1的pipelining可以同時發(fā)送多個request，但response仍是按請求的順序串行返回，只要其中一個請求的response稍微大一點或發(fā)生錯誤，就會阻塞住后面的請求。
HTTP2 這里的多路復(fù)用協(xié)議解決了這些問題，它把在連接里傳輸?shù)臄?shù)據(jù)都封裝成一個個stream，每個stream都有標識，stream的發(fā)送和接收可以是亂序的，不依賴順序，也就不會有阻塞的問題，接收端可以根據(jù)stream的標識去區(qū)分屬于哪個請求，再進行數(shù)據(jù)拼接，得到最終數(shù)據(jù)。
解釋下多路復(fù)用這個詞，多路可以認為是多個連接，多個操作，復(fù)用就是字面上的意思，復(fù)用一條連接或一個線程。HTTP2這里是連接的多路復(fù)用，網(wǎng)絡(luò)相關(guān)的還有一個I/O的多路復(fù)用(select/epoll)，指通過事件驅(qū)動的方式讓多個網(wǎng)絡(luò)請求返回的數(shù)據(jù)在同一條線程里完成讀寫。
客戶端來說，iOS9 以上 NSURLSession 原生支持 HTTP2，只要服務(wù)端也支持就可以直接使用，Android 的 okhttp3 以上也支持了 HTTP2，國內(nèi)一些大型 APP 會自建網(wǎng)絡(luò)層，支持 HTTP2 的多路復(fù)用，避免系統(tǒng)的限制以及根據(jù)自身業(yè)務(wù)需要增加一些特性，例如微信的開源網(wǎng)絡(luò)庫 mars，做到一條長連接處理微信上的大部分請求，多路復(fù)用的特性上基本跟 HTTP2 一致。
TCP隊頭阻塞
HTTP2 的多路復(fù)用看起來是完美的解決方案，但還有個問題，就是隊頭阻塞，這是受限于 TCP 協(xié)議，TCP 協(xié)議為了保證數(shù)據(jù)的可靠性，若傳輸過程中一個 TCP 包丟失，會等待這個包重傳后，才會處理后續(xù)的包。HTTP2的多路復(fù)用讓所有請求都在同一條連接進行，中間有一個包丟失，就會阻塞等待重傳，所有請求也就被阻塞了。
對于這個問題不改變 TCP 協(xié)議就無法優(yōu)化，但 TCP 協(xié)議依賴操作系統(tǒng)實現(xiàn)以及部分硬件的定制，改進緩慢，于是 GOOGLE 提出 QUIC 協(xié)議，相當于在 UDP 協(xié)議之上再定義一套可靠傳輸協(xié)議，解決 TCP 的一些缺陷，包括隊頭阻塞。具體解決原理網(wǎng)上資料較多，可以看看。
QUIC 處于起步階段，少有客戶端接入，QUIC 協(xié)議相對于 HTTP2 最大的優(yōu)勢是對TCP隊頭阻塞的解決，其他的像安全握手 0RTT / 證書壓縮等優(yōu)化 TLS1.3 已跟進，可以用于 HTTP2，并不是獨有特性。TCP 隊頭阻塞在 HTTP2 上對性能的影響有多大，在速度上 QUIC 能帶來多大提升待研究。
3.數(shù)據(jù)
第三個問題，傳輸數(shù)據(jù)大小的問題。數(shù)據(jù)對請求速度的影響分兩方面，一是壓縮率，二是解壓序列化反序列化的速度。目前最流行的兩種數(shù)據(jù)格式是 json 和 protobuf，json 是字符串，protobuf 是二進制，即使用各種壓縮算法壓縮后，protobuf 仍會比 json 小，數(shù)據(jù)量上 protobuf 有優(yōu)勢，序列化速度 protobuf 也有一些優(yōu)勢，這兩者的對比就不細說了。
壓縮算法多種多樣，也在不斷演進，最新出的 Brotli 和Z-standard實現(xiàn)了更高的壓縮率，Z-standard 可以根據(jù)業(yè)務(wù)數(shù)據(jù)樣本訓(xùn)練出適合的字典，進一步提高壓縮率，目前壓縮率表現(xiàn)最好的算法。
除了傳輸?shù)?body 數(shù)據(jù)，每個請求 HTTP 協(xié)議頭的數(shù)據(jù)也是不可忽視，HTTP2 里對 HTTP 協(xié)議頭也進行了壓縮，HTTP 頭大多是重復(fù)數(shù)據(jù)，固定的字段如 method 可以用靜態(tài)字典，不固定但多個請求重復(fù)的字段例如 cookie 用動態(tài)字典，可以達到非常高的壓縮率，這里有詳細介紹。
通過 HTTPDNS，連接多路復(fù)用，更好的數(shù)據(jù)壓縮算法，可以把網(wǎng)絡(luò)請求的速度優(yōu)化到較不錯的程度了，接下來再看看弱網(wǎng)和安全上可以做的事情。
弱網(wǎng)
手機無線網(wǎng)絡(luò)環(huán)境不穩(wěn)定，針對弱網(wǎng)的優(yōu)化，微信有較多實踐和分享，包括：
提升連接成功率
復(fù)合連接，建立連接時，階梯式并發(fā)連接，其中一條連通后其他連接都關(guān)閉。這個方案結(jié)合串行和并發(fā)的優(yōu)勢，提高弱網(wǎng)下的連接成功率，同時又不會增加服務(wù)器資源消耗：
?
制定最合適的超時時間
對總讀寫超時(從請求到響應(yīng)的超時)、首包超時、包包超時(兩個數(shù)據(jù)段之間的超時)時間制定不同的計算方案，加快對超時的判斷，減少等待時間，盡早重試。這里的超時時間還可以根據(jù)網(wǎng)絡(luò)狀態(tài)動態(tài)設(shè)定。
調(diào)優(yōu)TCP參數(shù)，使用TCP優(yōu)化算法。
對服務(wù)端的TCP協(xié)議參數(shù)進行調(diào)優(yōu)，以及開啟各種優(yōu)化算法，使得適合業(yè)務(wù)特性和移動端網(wǎng)絡(luò)環(huán)境，包括RTO初始值，混合慢啟動，TLP，F(xiàn)-RTO等。
針對弱網(wǎng)的這些細致優(yōu)化未成為標準，系統(tǒng)網(wǎng)絡(luò)庫沒有內(nèi)置，不過前兩個客戶端優(yōu)化微信的開源網(wǎng)絡(luò)庫 mars 有實現(xiàn)，若有需要可以使用。
安全
標準協(xié)議 TLS 保證了網(wǎng)絡(luò)傳輸?shù)陌踩?，前身?SSL，不斷在演進，目前最新是 TLS1.3。常見的 HTTPS 就是 HTTP 協(xié)議加上 TLS 安全協(xié)議。
安全協(xié)議概括性地說解決兩個問題：1.保證安全 2. 降低加密成本
在保證安全上：
使用加密算法組合對傳輸數(shù)據(jù)加密，避免被竊聽和篡改。
認證對方身份，避免被第三方冒充。
加密算法保持靈活可更新，防止定死算法被破解后無法更換，禁用已被破解的算法。
降低加密成本上：
用對稱加密算法加密傳輸數(shù)據(jù)，解決非對稱加密算法的性能低以及長度限制問題。
緩存安全協(xié)議握手后的密鑰等數(shù)據(jù)，加快第二次建連的速度。
加快握手過程：2RTT-> 0RTT。加快握手的思路，就是原本客戶端和服務(wù)端需要協(xié)商使用什么算法后才能加密發(fā)送數(shù)據(jù)，變成通過內(nèi)置的公鑰和默認的算法，在握手的同時就把數(shù)據(jù)發(fā)出去，也就是不需要等待握手就開始發(fā)送數(shù)據(jù)，達到0RTT。
這些點涉及的細節(jié)非常多，對 TLS 的介紹有一篇雄文，說得很詳細，在此推薦。
https://blog.helong.info/blog/2015/09/07/tls-protocol-analysis-and-crypto-protocol-design/
目前基本主流都支持 TLS1.2，iOS 網(wǎng)絡(luò)庫默認使用 TLS1.2，Android4.4 以上支持 1.2。TLS1.3 iOS 還處于測試階段，Android 未查到消息。對于普通 APP，只要正確配置證書，TLS1.2 已經(jīng)能保證傳輸安全，只是在建連速度上會有所損耗，有一些大型 APP 像微信就自行實現(xiàn)了 TLS1.3 的部分協(xié)議，早一步全平臺支持。
最后
網(wǎng)絡(luò)優(yōu)化這個話題非常龐大，本文只是在學(xué)習(xí)過程中從優(yōu)化思路上列舉了目前業(yè)界常見的優(yōu)化點，還有很多細節(jié)很多更深入的優(yōu)化沒涉及到，網(wǎng)絡(luò)層實踐開發(fā)經(jīng)驗不足，若有錯誤歡迎指出。
看完本文有收獲？請轉(zhuǎn)發(fā)分享給更多人
關(guān)注「ImportNew」，提升Java技能
聯(lián)系客服
