網絡技術作爲互聯網應用賴以存在的技術基礎，速度與安全永遠是其核心使命，本次WWDC的網絡類topic涵蓋內容基本還是圍繞這兩個點來展開。本次WWDC網絡類session在基礎網絡技術上譬如新協議、新算法方面着墨並不多；也未提出新的類似NSURLSession / Network.framework之類的新網絡組件。站在應用視角，本次WWDC網絡類session可分爲兩大類：
- 無線網絡體驗優化實踐在系統層面的標準化；
- 本地網絡應用的權限管控增強。
在第一類議題中，我們看到很多已經在手淘中的類似實踐，或標準或自研，說明手淘在網絡技術的開發與應用上還是較爲深入和前沿的，基本走在全球業界前列。根據我們手淘的業務特點，筆者重點關注第一類session，並簡單探討該新技術可以我們帶來什麼樣啓發和變化。
使用加密DNS
DNS解析是網絡的連接的第一步，這裏提到的"加密DNS"是什麼、它解決什麼問題？
解決什麼問題
一是傳統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的存在的問題。
規範與標準
iOS 14 開始系統原生支持兩種標準規範的 Encrypted DNS, 分別是 DNS over TLS 與 DNS over HTTPS.
具體協議標準可以參見：rfc7858 (DoT) 、rfc8484 (DoH)
如何實現
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配置會做例外處理。相類似的，對於VPN網絡，在VPN隧道內的解析將使用VPN的DNS設置，而不使用系統域DNS配置。
網絡規則設置示例代碼：
上述代碼設置了三個網絡規則，第一個規則表示DNS配置應該在SSID="MyWorkWiFi"的WiFi網絡生效，但對私有企業域名enterprise.example.net不開啓。第二個規則表示規則在蜂窩網下應該被禁止使用;第三個NEOnDemandRuleConnect表示DNS配置應該默認開啓;因爲配置DNS是系統支持的，所以在編寫NetworkExtension App時不需要實現Extension程序，只需要在Network Extensions中勾選DNS Settings選項。
運行NetworkExtension App，DNS配置將會被安裝到系統，爲了讓DNS配置生效，需要前往設置->通用->VPN & 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。
現有實踐對比及啓發
-
與現有實踐對比
上文已經提到過HTTPDNS產品，手淘的域名解析，採用的是類似於HTTPDNS原理，但更加複雜的調度方案。但是相比於這種系統層面的標準化方案，解決了現有實踐中的兩大難題：
- 對業務的侵入性：業務必須修改現有網絡連接的階段的代碼；
- 交互的標準兼容性不足：IP直連下的302問題、Cookie問題、SNI問題等
-
帶來的變化
一是在應用內部，我們可以對業務透明提供提供全局的域名調度或者域名兜底解析能力, 不再是隻有用到特定組件或SDK纔可以。二是蘋果放開系統級別DNS接管後，用戶設備上的服務相比原Local DNS的“中立性”如何管控？對特定業務是否甚至會造成惡化？如果對外部應用的這種“中立性”疑問或擔心確實存在，則這種系統標準化的加密DNS對手淘這種大型應用則是必選項。
受限網絡中推送
解決什麼問題
當向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運行。
如何實現
本地推送連接對那些推送功能非常重要，而設備所在網絡受限的場景非常適合。而對於常規的推送需求，依然推薦使用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展示呼叫界面。
價值場景
如果只考慮推送本身，對於手淘或者大部分消費類應用來說，筆者認爲價值並不大，因爲此類APP不可能在一個封閉的本地網絡裏去部署資源來提供服務能力。這裏一個可應用的點在於：設備一旦進入特定網絡環境，觸發App Extension, 進而喚起主App，應用可在後臺完成一定事務。因爲 iOS App 一直缺乏後臺服務能力，這種特定網絡環境的觸發喚醒，極大的補充了這一能力。
現代網絡技術的應用
蘋果在這次WWDC中，把一些較新的網絡技術，對應用的體驗提升，做了一個簡單綜述，包括IPv6、HTTP/2、TLS1.3, MTCP、以及HTTP/3。這些技術在手淘基本都有涉及，有些是已經是大規模部署、有些是正在逐步推進中。對各個應用來說，如果已經在應用這些技術了，則雲端均儘可能標準化，便於進一步推廣和複用。這裏簡單的對蘋果的綜述做一個搬運：
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目前階段在國內尚處於發展中，基礎運營商覆蓋、家用網絡接入設備支持、應用服務的支持，正在快速發展中。
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技術在設備支持之前即大規模應用，協議棧完全自研，爲進一步提升建聯速度，又做了一些預置證書的優化。下一步將逐步使基礎網絡依賴標準化平臺能力，降低對私有協議棧的依賴，可降低包大小以及提升產品複用體驗。
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即可提供更新安全、高效、標準的網連接。
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。
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應用應該會早於蘋果系統先行支持，目前已經在灰度中。
本文轉載自公衆號淘系技術（ID：AlibabaMTT）。
原文鏈接：