WWDC：无线网络优化实践，带来哪些启发？

4lqedz

网络技术做为互联网应用赖以存在的技术基本，速度与安全永远是其核心使命，这次WWDC的网络类topic涵盖内容基本还是围绕这两个点来展开。这次WWDC网络类session在基本网络技术上譬如新协议、新算法方面着墨并不多；亦未提出新的类似NSURLSession / Network.framework之类的新网络组件。站在应用视角，这次WWDC网络类session可分为两大类：

无线网络体验优化实践在系统层面的标准化；

本地网络应用的权限管控加强。

在第1类议题中，咱们看到非常多已然在手淘中的类似实践，或标准或自研，说明手淘在网络技术的研发与应用上还是较为深入和前沿的，基本走在全世界业界前列。按照咱们手淘的业务特点，笔者重点关注第1类session，并简单探讨该新技术能够咱们带来什么样启发和变化。

运用加密DNS

DNS解析是网络的连接的第1步，这儿说到的"加密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的办法。第1种方式是选取一个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配置。

网络规则设置示例代码：

以上代码设置了三个网络规则，第1个规则暗示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应用应该会早于苹果系统先行支持，日前已然在灰度中。

手淘客户端团队手淘客户端团队正在进行社招招聘，岗位有iOS Android客户端研发工程师、欢迎 转岗举荐。简历投递：junzhan.yzw@taobao.com✿  拓展阅读作者|徐杰(无宸)编辑|橙子君出品|阿里巴巴新零售淘系技术

qzmjef

你的见解真是独到，让我受益匪浅。