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

在第一类议题中，我们看到很多已经在手淘中的类似实践，或标准或自研，说明手淘在网络技术的开发与应用上还是较为深入和前沿的，基本走在全球业界前列。根据我们手淘的业务特点，笔者重点关注第一类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 一直缺乏后台服务能力，这种特定网络环境的触发唤醒，极大的补充了这一能力。

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数Java工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年Java开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Java开发知识点，真正体系化！

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！

如果你觉得这些内容对你有帮助，可以扫码获取！！（备注Java获取）

总结

至此，文章终于到了尾声。总结一下，我们谈论了简历制作过程中需要注意的以下三个部分，并分别给出了一些建议：

1. 技术能力：先写岗位所需能力，再写加分能力，不要写无关能力；
2. 项目经历：只写明星项目，描述遵循 STAR 法则；
3. 简历印象：简历遵循三大原则：清晰，简短，必要，要有的放矢，不要海投；

以及最后为大家准备的福利时间：简历模板+Java面试题+热门技术系列教程视频

《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取！
关能力；
2. 项目经历：只写明星项目，描述遵循 STAR 法则；
3. 简历印象：简历遵循三大原则：清晰，简短，必要，要有的放矢，不要海投；

以及最后为大家准备的福利时间：简历模板+Java面试题+热门技术系列教程视频

[外链图片转存中…(img-LE3yoRFf-1713438767105)]

[外链图片转存中…(img-NlBvV6wJ-1713438767105)]

[外链图片转存中…(img-RuwFFuPD-1713438767105)]

《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取！