iOS 網路最佳化：iOS 14 網路層效能和安全性

前言

本 session 主要關注的是，如何使用一些蘋果內建的網路層技術，來達到提升效能、增強安全性、適配移動端網路特點的目標，並保護好使用者隱私。

IPv6

蘋果原生支援使用 IPv6，並且支援 IPv6 和 IPv4 混合使用（一個 App 內）或者僅使用 IPv6 網路，目前來看，使用 IPv6 能夠帶來更低的網路延遲，原因是不需要過多的 NAT，還有就是支援 IPv6 的硬體效能更好。好了，注意一下，IPv6 協議本身並沒有特別關注效能問題，只不過是甩掉了一些 IPv4 的歷史包袱，從而“意外”地獲得了效能提升。下面解釋一下蘋果提到的，使用 IPv6 以後帶來效能提升的原因

NAT（網路地址對映）

在 IPv4 時代，為了解決 IP 地址緊缺的問題，需要大量用到 NAT 技術，相信很多人都在體驗過，出口同一個公網 IP，經過路由器的處理，對內區分了192.168.xxx.xxx等內網 IP。以下的圖說明了這個過程

如果沒有 NAT 網路，假設每個接入子網都需要一組/24的 IP，而且還能對外連線，對外的路由至少要保留或申請1000個對外 IP 帶 NAT 網路，透過 NAT 轉換，接入子網可以使用私用 IP，對外連線時由路由繫結私用 IP 與對外 IP 的關係，修改傳輸的 IP 包上的地址，從而只需要255個對外 IP 就能滿足內部接入子網的對外連線需求

顯而易見，當 NAT 層數變多了以後，因為網路拓撲結構變複雜了，導致不同 NAT 網路之間的主機如果需要進行互相通訊的話，將需要經過非常多的結點才能做到。而 IPv6 協議下，因為 IP 地址空間足夠大，並不需要架設過多的 NAT 網路，基本可以認為大機率是透過 IP 直連的方式進行通訊

硬體效能

實際上，很多的舊裝置無法直接軟體升級支援 IPV6。要發揮 IPV6 的效能，對應的 MAC 地址編碼也是有所變化。另外由於要加密，所以對硬體能力也有要求，最好實現硬體加密，所以現有裝置無法直接升級。在落地 IPv6 的實際過程中，很多運營商採取直接更換硬體的方式進行部署，由於硬體效能的提升，對於 IPv6 網路整體而言也獲得了不少好處。

蘋果的資料

根據 Safari 中的資料，目前 IPv6 的請求分佈大概如下圖

跟 Google 的線上統計比例差不多

目前主流的 App Store 應用，有不少是已經開始試水 IPv6

隨便抓包一下網易新聞，可以看到確實有啟用了 IPv6 的場景

App 業界中有名的激進派，閒魚團隊，已經率先彙報他們的改造案例了

彙報一下，閒魚的ipv6改造之路

最後附帶一個重要資訊，為什麼必須正視 IPv6？因為 IPv4 地址已經分配完畢了，IPv6 落地是大勢所趨

最後一個 IPV4 地址分配完畢，正式向 IPV6 過渡！

HTTP/2

從 WWDC2018 開始，蘋果已經內建了 HTTP/2 協議的支援，上個月 Safari 的統計資料來看，已經有79%的網路請求，使用了 HTTP/2 協議了

根據 的統計，全球已經超過40%的網站使用 HTTP/2 協議了

HTTP/2 協議的特點和優勢可以看下面的知識點，這裡不再展開詳述

• 二進位制分幀層 (Binary Framing Layer)

• 多路複用 (MultiPlexing)

• 服務端推送 (Server Push)

• Header 壓縮 (HPACK)

• 應用層的重置連線

• 請求優先順序設定

• 流量控制

公開分享 HTTP/2 最佳化實踐的團隊不多，以下是來自2017年 QQ 空間團隊的資料

TLS1.3

關於 TLS1.3 的優勢，可以看回2018年的分析文章 ^[1]

直觀的流程對比如下所示

再貼一個圖，說明以下 TLS1.3 是怎麼實現 0-RTT 的，左圖是第一次握手建立，需要 1RTT，右圖是後續的網路請求，可以實現 0RTT

蘋果貼了一張基於線上裝置網路請求的對比圖，可以看到接近一半的網路請求已經使用了 TLS1.3 協議，並且確實獲得了效能提升

Netfilx分享了他們使用TLS1.3以後的一些經驗，可以參考一下 這篇文章，使用了TLS1.3以後，時延明顯下降

Multipath TCP 

多路 TCP 對於網路請求的體驗有極大的提升，眾所周知，手機包含兩種上網方式，蜂窩移動資料網路（2G，3G，4G）和 WIFI 網路。我們希望在有 WIFI 的時候儘量使用 WIFI，這樣可以節省成本，沒有 WIFI 的時候自動切換到蜂窩行動網路，避免斷連。同樣在 PC 端，我們希望有線網路卡和無線網路卡可以同時上網，提高網速。參考一下 Apple Music 的資料，當使用者在聽歌的時候，如果遇到了網路切換，如果是過去的 TCP 管理方式，就會需要重新建立連線，因此使用者就會遇到重新緩衝的情況。在應用多路 TCP 以後，減少了13%遇到重新緩衝的場景，另外在遇到重新緩衝的時候，提升了22%的緩衝時間

Local Network Privacy

這裡實際上是介紹了 Bonjour 協議的變化，主要是隱私性和安全性上面的提升，具體可以看看今年的 WWDC10110 ^[2]

Encrypted DNS 

DNS 是一個解析域名 IP 的一個技術，他的工作方式可以看下面的時序圖，當使用者想要訪問 twitter.com 的時候，需要先從DNS 伺服器獲得具體的伺服器 IP 地址，才能進行後續的網路通訊流程

最早期的 DNS 協議，並沒有定義加密流程，所以如果有一些惡意的 WIFI 結點，或者網路運營商進行使用者行為嗅探的話，能夠很明確地看到使用者的 DNS 請求資料，從而實現 DNS 劫持，對於特定的域名訪問，重定向到惡意的 IP 地址訪問，從而獲得不法的收益。如下圖所示，可以看到使用者透過不安全的埠（53）訪問 twitter.com，然後希望獲得的 IP 伺服器地址是104.244.42.129。此時可以篡改返回值，指向釣魚伺服器 IP

如果採用了 Encrypted DNS 以後，以上的攻擊行為將會變得無用武之地了，使用者的網路請求將會如下所示

如果簡單理解 Encrypted DNS 的流程，相當於在 DNS 流程上加上了 TLS 加密流程，從而使得 DNS 請求就像 HTTPS 請求一樣，安全性對比以前提升了好幾個等級

蘋果的建議

從 iOS14 開始，如果開發者的網站已經支援了 Encrypted DNS，可以直接在程式碼中開啟這個配置，這樣子客戶端的網路請求將會獲得安全性的收益

HTTP/3     

HTTP/3 協議可以認為是基於 QUIC 的新一代網    絡協議，基於 UDP 流程，解決了上一代網路協議基於 TCP 的諸多問題，HTTP/3 協議的新特性可以看下面的知識點，因為有很多還是在草案中，所以不展開討論

• 基於 TLS1.3 實現 0RTT

• 降低隊頭阻塞的問題

• 連線遷移

• 更好的擁塞控制演算法

• 更好的流量控制演算法 /sichuan/

當前的 HTTP/3 協議的進度還在草稿中，不過蘋果已經在 iOS14 中率先支援了 HTTP/3 協議，看起來很有可能在 iOS14 的其中一個大版本更新以後，將會正式支援。在 iOS14 系統更新以後，可以在手機開啟 HTTP/3 試用

也可以在 Mac 電腦開啟 HTTP/3 試用 /shenyang/

總結 /secondary/

在 iOS14 中，蘋果內建的網路技術，主要在以下幾個方面可以提升網路層的表現，並且提醒開發者注意伺服器端的配置，確保能夠前後端都採用最新的網路協議配合使用，達到最優體驗。

• IPv6：客戶端預設開啟，需要伺服器端支援

• HTTP/2：客戶端預設開啟，需要伺服器端支援

• TLS 1.3：客戶端預設開啟，需要伺服器端支援

• Multipath TCP：客戶端預設開啟，需要伺服器端支援

• Encrypted DNS：客戶端預設開啟，需要伺服器端支援

• HTTP/3：需要使用者在設定介面開啟，需要伺服器端支援