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