WWDC20：無線網絡優化實踐，帶來哪些啓發？

0. 引

網絡技術做爲互聯網應用賴以存在的技術基礎，速度與安全永遠是其核心使命，本次WWDC的網絡類topic涵蓋內容基本仍是圍繞這兩個點來展開。本次WWDC網絡類session在基礎網絡技術上譬如新協議、新算法方面着墨並很少；也未提出新的相似NSURLSession / Network.framework之類的新網絡組件。站在應用視角，本次WWDC網絡類session可分爲兩大類：

• 無線網絡體驗優化實踐在系統層面的標準化；
• 本地網絡應用的權限管控加強。

在第一類議題中，咱們看到不少已經在手淘中的相似實踐，或標準或自研，說明手淘在網絡技術的開發與應用上仍是較爲深刻和前沿的，基本走在全球業界前列。根據咱們手淘的業務特色，筆者重點關注第一類session，並簡單探討該新技術能夠咱們帶來什麼樣啓發和變化。

（ WWDC 2020精彩內容思否專欄：https://segmentfault.com/blog...  

本篇內容來自於阿里巴巴淘系技術部，無線開發專家 無宸。
更多精彩內容可關注【淘系技術】公衆號。）

1. 使用加密DNS

DNS解析是網絡的鏈接的第一步，這裏提到的"加密DNS"是什麼、它解決什麼問題？

1.1 解決什麼問題

一是傳統Local DNS的查詢與回覆均基於非加密UDP，咱們常見的DNS劫持問題

二是Local DNS Server自己不可信，或者本地Local DNS 服務不可用

其實針對DNS解析過程當中以上兩個問題，在實踐中早就有了解決方案，就是HTTPDNS, 各大雲廠商也都有成熟產品售賣，那蘋果這裏的加密DNS與咱們的現有HTTPDNS有何不一樣呢？現有HTTPDNS有兩個很大的問題：一是對業務的侵入性，即若是某個網絡鏈接須要使用HTTPDNS的能力，首先他須要集成服務商提供的SDK, 引入相應的Class，而後修改網絡鏈接的階段的代碼；二是面臨各類技術坑，好比302場景的IP直連處理、WebView下IP直連如何處理Cookie、以及iOS上的老大難的SNI問題等，這些都須要業務開發者付出極大的努力和嘗試。

iOS 14 上的 Encrypted DNS 功能很好的解決了現有HTTPDNS的存在的問題。

1.2 規範與標準

iOS 14 開始系統原生支持兩種標準規範的 Encrypted DNS, 分別是 DNS over TLS 與 DNS over HTTPS.

具體協議標準能夠參見：rfc7858 (DoT) 、rfc8484 (DoH)

1.3 如何實現

iOS 14 提供了兩種設置加密DNS的方法。第一種方式是選擇一個DNS服務器做爲系統全局全部App默認的DNS解析器，若是你提供的是一個公共DNS服務器，你可使用NEDNSSettingsManager API編寫一個NetworkExtension App完成系統全局加密DNS設置。或者若是你使用MDM(Mobile Device Management)管理設備的企業設置；你能夠推送一個包含DNSSettings paload的profile文件完成加密DNS設置。

使用NetworkExtension設置系統域全局DNS服務器示例代碼：

上述代碼首先經過NEDNSSettingsManager加載配置，加載成功後，建立一個基於DoH協議的NEDNSOverHTTPSSettings實例，對其配置DNS IP地址和域名，DNS IP地址是可選配置的。而後將NEDNSOverHTTPSSettings實例配置到NEDNSSettingsManager共享實例的dnsSettings屬性，最後保存配置。

一條DNS配置包括DNS服務器地址、DoT/DoH協議、一組網絡規則。網絡規則確保DNS設置兼容不一樣的網絡。由於公共DNS服務器是沒法解析本地網絡的私有域名，好比只有企業WiFi網絡內的DNS服務器能夠解析員工訪問的私有域名，這類狀況就須要手動指定網絡規則兼容企業WiFi網。網絡規則能夠針對不一樣網絡類型定義行爲，好比蜂窩網、WiFi、或者具體的WiFi SSID。在匹配的網絡下，你能夠禁用配置的全局DNS設置，或者對私有域名不使用DNS設置。而在一些狀況下，兼容性會自動處理。好比強制門戶網絡(captive portal), 手機在鏈接上某個WiFi的時候，自動彈出一個頁面輸入帳號密碼才能鏈接網絡。這種狀況下系統域全局DNS配置會作例外處理。

網絡規則設置示例代碼：

上述代碼設置了三個網絡規則，第一個規則表示DNS配置應該在SSID="MyWorkWiFi"的WiFi網絡生效，但對私有企業域名enterprise.example.net不開啓。 第二個規則表示規則在蜂窩網下應該被禁止使用;第三個NEOnDemandRuleConnect表示DNS配置應該默認開啓;由於配置DNS是系統支持的，因此在編寫NetworkExtension App時不須要實現Extension程序，只須要在Network Extensions中勾選DNS Settings選項。

運行NetworkExtension App，DNS配置將會被安裝到系統，爲了讓DNS配置生效，須要前往設置->通用 & Network->DNS手動啓用。

一些網絡可能會經過策略阻止你使用加密的DNS服務器。這些網絡嘗試分析DNS查詢請求來過濾流量。對於此類網絡，系統會被標記隱私警告提示，在該網絡下的網絡鏈接將會失敗。

第二種方式是針對單個App的全部鏈接或部分鏈接啓用加密DNS。

若是你只想爲你的App使用加密DNS，而非涉及整個系統域。你能夠適配Network framework的PrivacyContext，對你的整個App開啓加密DNS，或者僅對某一鏈接開啓。無論使用的是URLSessionTask，或Network framework鏈接或getaddrinfo的POSIX API，這種方式都有效。

對單個鏈接使用加密DNS示例代碼：

驗證請求是否使用加密DNS：

若是你想在App範圍內使用加密DNS，你能夠配置默認的PrivacyContext；App內發起的每一個DNS解析都會使用這個配置。無論是URLSessionTask，仍是相似getaddrinfo的底層API。

1.4 現有實踐對比及啓發

• 與現有實踐對比

上文已經提到過HTTPDNS產品，手淘的域名解析，採用的是相似於HTTPDNS原理，但更加複雜的調度方案。可是相比於這種系統層面的標準化方案，解決了現有實踐中的兩大難題：

• 對業務的侵入性：業務必須修改現有網絡鏈接的階段的代碼；
• 交互的標準兼容性不足：IP直連下的302問題、Cookie問題、SNI問題等
• 帶來的變化

一是在應用內部，咱們能夠對業務透明提供提供全局的域名調度或者域名兜底解析能力, 再也不是隻有用到特定組件或SDK才能夠。二是蘋果放開系統級別DNS接管後，用戶設備上的服務相比原Local DNS的「中立性」如何管控？對特定業務是否甚至會形成惡化？若是對外部應用的這種「中立性」疑問或擔憂確實存在，則這種系統標準化的加密DNS對手淘這種大型應用則是必選項。

2. 受限網絡中推送

2.1 解決什麼問題

當向iOS設備推送消息時，業務服務器須要將消息先發送給APNS服務器，APNS服務器再將消息轉換爲通知payload推送給目標設備。若是設備所在的WiFi網絡沒有鏈接互聯網或者當前網絡受限，好比在遊艇、醫院、野營地這些地方，設備沒有與APNS服務器創建有效鏈接，APNS消息投遞將會失敗。

對於一些App來講，接收推送消息是App的一項很是重要的功能，即便在沒有互聯網鏈接的狀況下也須要持續穩定工做。爲了知足這一需求，iOS 14中增長了本地推送鏈接(Local Push Connectivity)API，這是NetworkExtension家族中新的API。本地推送鏈接API容許開發者建立本身的推送鏈接服務，經過開發一個App Extension，在指定的WiFi網絡下能夠直接與本地業務服務器通訊。

上圖中，App Extension主要負責保持與本地業務服務器之間的鏈接，以及接收業務服務器發來的通知。由於沒有了APNS，開發者須要爲業務服務器與App Extension定義本身的通訊協議。主App須要配置具體在哪一個WiFi網絡下使用本地推送鏈接。當App加入到指定的WiFi網絡，系統會拉起App Extension, 並在後臺持續運行。當App斷開與指定WiFi網絡的鏈接，系統將中止App Extension運行。

2.2 如何實現

本地推送鏈接對那些推送功能很是重要，而設備所在網絡受限的場景很是適合。而對於常規的推送需求，依然推薦使用PushKit或UserNotification API處理APNS推送消息。每臺設備和APNS服務器之間只創建一條APNS鏈接，設備上全部App都公用這一條鏈接，因此APNS很是省電。

APNS與本地推送鏈接對比：

新的本地推送鏈接API由兩個類組成：NEAppPushManager和NEAppPushProvider。NEAppPushManager在主App中使用，主App使用NEAppPushManager建立一個配置，配置中指定具體哪一個WiFi網絡下運行本地推送鏈接。你可使用NEAppPushManager加載/移除/保存配置。NEAppPushProvider則在App Extension使用。在App Extension中實現一個NEAppPushProvider的子類，子類中須要覆蓋生命週期管理方法，這些方法在App Extension運行和中止時被調用。

App Extension主要處理兩類推送，一類是常規的推送通知，一類是VoIP呼叫通知。若是是常規的推送通知，App Extension收到消息後，可使用UserNotification API構造一個本地推送顯示推送信息。若是是VoIP呼叫通知，App Extension使用NEAppPushProvider類將呼叫信息報告給系統。若是此時主App不在運行，系統將喚醒主App，並將消息投遞給它，最後主App再使用CallKit API顯示呼叫界面。

下面是在主App中使用NEAppPushManager的示例代碼：

上述代碼建立了一個NEAppPushManager實例，並配置實例的各個屬性值。matchSSIDs表示在指定的WiFi網絡下才啓用本地推送鏈接。providerBundleIdentifier表示App Extension的包名，providerConfiguration是傳給App Extension的一些配置，在App Extension內能夠經過NEAppPushProvider的providerConfiguration屬性獲取。isEnabled表示使用這個配置開啓本地推送鏈接。最後調用saveToPreferences方法持久化配置。下面是App Extension實現NEAppPushProvider子類的示例代碼：

系統調用start(completionHandler:)方法啓動App Extension，在這個方法內App Extension與本地業務服務器創建鏈接。當App Extension中止運行，系統調用stop(with:)方法, 在這個方法內App Extension斷開與業務服務器的鏈接。handleIncomingVoIPCall(callInfo:)方法在收到VoIP呼叫時被調用，在方法內App Extension調用reportIncomingCall(userInfo:)將該事件上報給系統。隨後系統將會喚醒主App，並將呼叫信息傳遞給主App。主App處理系統傳入的呼叫信息示例代碼：

以上代碼在AppDelegate的didFinishLaunchingWithOptions方法內使用NEAppPushManager加載全部配置，並設置每一個NEAppPushManager示例的代理屬性。系統會在主線程中將接收到呼叫信息經過didReceiveIncomingCallWithUserInfo方法投遞給主App。主App必須經過CallKit API將呼入信息上報給CallKit展現呼叫界面。

2.3 價值場景

若是隻考慮推送自己，對於手淘或者大部分消費類應用來講，筆者認爲價值並不大，由於此類APP不可能在一個封閉的本地網絡裏去部署資源來提供服務能力。這裏一個可應用的點在於：設備一旦進入特定網絡環境，觸發App Extension, 進而喚起主App，應用可在後臺完成必定事務。由於 iOS App 一直缺少後臺服務能力，這種特定網絡環境的觸發喚醒，極大的補充了這一能力。

3. 現代網絡技術的應用

蘋果在此次WWDC中，把一些較新的網絡技術，對應用的體驗提高，作了一個簡單綜述，包括IPv六、HTTP/二、TLS1.3, MTCP、以及HTTP/3。這些技術在手淘基本都有涉及，有些是已是大規模部署、有些是正在逐步推動中。對各個應用來講，若是已經在應用這些技術了，則雲端均儘量標準化，便於進一步推廣和複用。這裏簡單的對蘋果的綜述作一個搬運：

3.1 IPv6

蘋果根據最新統計，蘋果全球設備TCP鏈接佔比中，IPv6佔比26%，IPv4佔比74%，其中74%的佔比中有20%是由於服務端沒有開啓IPv6支持。在建連時間方面，因爲減小了NAT使用，提升了路由效率，IPv6的建連時間比IPv4快1.4倍。開發者只需使用URLSession和Network.framework API，IPv6網絡適配將自動支持。

以上是蘋果的數據。阿里巴巴集團從18年開始大力推動IPv6的建設，目前咱們在IPv6總體應用規模上在業界是屬於頭部大廠。但根據咱們應用的實際效果數據，以及業界友商的應用數據，性能提高並不明顯。以及工信部的IPv6建設目標來看，性能提高也不是IPv6建設的目標，只要達到IPv4同等水平便可。IPv6 的意義就在解決IPv4地址空間枯竭的問題，更多的在規模、安全，而不是性能提高。就企業而言，例如能夠下降IPv4地址的購買費用；就國家而言，IPv6 突破了IPv4中國境內無DNS根結點的風險。IPv6目前階段在國內尚處於發展中，基礎運營商覆蓋、家用網絡接入設備支持、應用服務的支持，正在快速發展中。

3.2 HTTP/2

HTTP/2的多路複用特性使得對同一服務器的多個請求複用到單個鏈接上，沒必要等待前一個請求響應結束才能發送下一個請求，不只節省了時間也提高了性能。頭部壓縮特性提高了帶寬利用率，經過簡化消息內容，從而下降消息的大小。根據最新統計，在Safari中HTTP2 Web流量佔比79%，HTTP/2比HTTP/1.1快1.8倍。若是服務端支持HTTP/2，URLSession將默認使用HTTP/2。

在手淘業務中，全面應用HTTP2已經有三四年之久，其使用規模比蘋果統計的結果要高的多，取得了巨大的體驗提高收穫。手淘的核心流量分爲兩類：API請求MTOP於圖片CDN請求，這兩類的HTTP2的流量佔比約超過 98%，基本實現核心流量所有長連化。但當前手淘的HTTP2技術在設備支持以前即大規模應用，協議棧徹底自研，爲進一步提高建聯速度，又作了一些預置證書的優化。下一步將逐步使基礎網絡依賴標準化平臺能力，下降對私有協議棧的依賴，可下降包大小以及提高產品複用體驗。

3.3 TLS1.3

TLS1.3經過減小一次握手減小了建連時間，經過形式化驗證(Formal Verification)與減小被錯誤配置的可能性，提升了通訊安全。從iOS 13.4開始，TLS1.3默認在URLSession和Network.framework開啓。根據最新統計，在最新的iOS系統上，大約49%的鏈接使用TLS1.3。使用TLS1.3比使用TLS1.2建連時間快1.3倍。若是服務端支持TLS1.3，URLSession將默認使用TLS1.3。

目前手淘的HTTP/2 的TLS version仍然仍是基於TLS1.2，不過爲了解決低版本TLS的性能之殤，手淘網絡經過預置證書與自定義 SSL 握手流程，創新自研了slight-ssl協議，實現了 0rtt 的效果。TLS 1.3 標準在系統層面的全面支持，對應用來講是一個明確的技術趨勢信號，咱們的網絡協議需儘快標準化，對網絡管道兩端來講，客戶端應用層網絡接口需全面升級到NSURLSession或Network.framework, 實現對系統標準能力的應用；雲端也許全面支持TLS1.3，可不依賴端側SDK便可提供更新安全、高效、標準的網鏈接。

3.4 MultiPath TCP

MultiPath TCP 容許在一條TCP鏈路中創建多個子通道。當設備切換網絡時，單個TCP鏈接依然能夠繼續使用。蘋果的Apple Music與Siri服務都使用了MultiPath TCP。Apple Music在使用MultiPath TCP以後,音樂播放卡頓次數減小了13%,卡頓持續時間減小了22%。開啓MultiPath TCP須要客戶端和服務端都支持才能生效，服務端支持MultiPath TCP可參考：http://multipath-tcp.org/

其實手淘在這方面也有相似的優化嘗試：多網卡：同時經過Wi-Fi與蜂窩網鏈接目標服務器，提高數據傳輸速度。其技術原理與MTCP不同，但也是想在上層起到相似做用：經過多路鏈接，提高數據交換帶寬。 業界也有相似的產品，例如華爲的 LinkTurbo。

3.5 HTTP/3

HTTP/3是下一代HTTP協議，它是構建在新的QUIC傳輸協議之上，QUIC協議內建了對TLS1.3的支持，並提供了與HTTP/2同樣的多路複用功能，並進一步減小了隊頭阻塞的發生，讓單個請求或相應的丟失不影響到其餘請求。使用QUIC的HTTP/3還具備較高的保真度信息，以提供改進的擁塞控制和丟包恢復。同時也包括內建的移動性支持，這樣網絡切換不會致使正在進行的操做失敗，能夠無縫在不一樣網絡之間切換。不過HTTP/3目前還處於草案階段，iOS 14和MacOS Big Sur包括了一個對使用URLSession的HTTP/3的實驗預覽支持，這個功能能夠在開發者設置中開啓。同時Safari的HTTP/3支持也可在開發者設置中開啓。

在手淘中，咱們的QUIC應用應該會早於蘋果系統先行支持，目前已經在灰度中。

（ WWDC 2020精彩內容思否專欄：https://segmentfault.com/blog...  

本篇內容來自於阿里巴巴淘系技術部，無線開發專家 無宸。
更多精彩內容可關注【淘系技術】公衆號。）

——————————————————————————————————————————————————

手淘客戶端團隊正在進行社招招聘，崗位有iOS Android客戶端開發工程師等，歡迎推薦。

簡歷投遞：junzhan.yzw@taobao.com