[Diving into WWDC 2017] Advances in Networking, Part 1

网络优化技术进阶

为了给用户提供更好的用户体验,在网络优化和新技术使用方面,苹果一直都保持着很积极的态度,近两年也多次通过加强审核的方式大力推广 IPv6 和 https;每年的 WWDC 都有若干网络优化的 session,介绍和讨论新的网络技术和使用情况; 今年的 Advances in Networking 进一步分享了 ECN/IPV6/MPTCP 等几项技术带来的收益,以及苹果网络相关 API 的一些新特性;

主要内容

  • ECN
  • IPv6
  • Networking stack changes
  • New NetworkExtension facilities
  • Multipath protocols for Multipath Devices

ECN

什么是 ECN

Recall

当网络拥塞发生时,因为发送方无法及时知晓网络情况,在发现丢包时会不断的重发,导致网络情况更加糟糕,而 ECN 的出现就解决了这个问题,ECN 是 TCP IP 协议的扩展,其实现是在 ip header 中加入 1 bit 的拥塞状态值,由接收方回传给发送方;发送方收到这个消息时既停止发送数据包,直到拥塞解除;

15 年的 session 中 有一个实验对比图:没有 ECN 时 在传输初段出现了明显的网络拥塞,而且持续了很久才恢复正常;而在使用了 ECN + CoDel 算法优化后,没有出现明显的数据终端和因拥塞导致的丢包和重传;

首先所有的网络协议 都是为了最大化的使用网络资源,一直到网络出现拥塞; 出现拥塞时会导致丢包,而 TCP 默认的处理是对丢包进行重传;这种方法代价非常大,发送方持续重试可能导致耗电,设备的网络资源也会被无端占用,而网络也可能更加拥塞,需要很长时间才能恢复; 有效的优化拥塞和避免拥塞将减少重传,减少延迟,并极大提升用户体验;在使用 ECN 的同时,需要结合使用 SQM 算法来进行数据缓存,他会保证是真正的拥塞出现前告知发送者当前的网络这块,最大程度上的避免拥塞出现;


ECN 需要客户端 服务端和网络三方面的支持,自 2013 年来 Server 对 ECN 的支持已经从 35% 提升至 74%(因为 ECN 也是 Linux 内核的一部分)。

客户端方面,iOS 10.3 开始,50% 的通过 Wifi 和少量通过移动网络进行的 TCP 链接已经打开了 ECN,没有收到相关问题的报告; 通过也收集到了一些国家出现网络拥塞的情况,美国 0.2%、中国 1%、法国 5%、阿根廷 30%;

综上,客户端从 iOS 11 开始,所有 TCP 请求都会支持 ECN(全部Wifi 和部分白名单移动运营商);服务端有 74% 的网站支持了 ECN,也会有越来越多的网络服务商开始支持 ECN 来进一步提升用户体验;(服务商只需要在你的网络接入点支持 ECN 即可);

IPv6

相比 IPv4,IPv6 有更大的地址空间,更小的路由表,更高安全性等优势。

World IPv6 Launch 始于 2016 年 6 月 6 日,包括中国在内的若干国家开始启用 IPv6(事实上中国进展缓慢)。支持 IPv6 的设备从 5 年前的不到 1% 提升到今天的接近 20%。欧美大多数的移动运营商也已同时支持 IPv6 和 IPv4。经过策略改进,HTTPS 请求在 IPv6 下提升了 15%-30%。

15 年的 session 里已经提到了 NAT64,如果服务端只支持 IPv4, 在 IPv6 环境下,可以通过 NAT64 DNS64 技术去正常访问。

16 年 6 月起,苹果也开始要求所有 App 提交时必须经过 NAT64 测试,支持 IPv6 网络;现在因为 IPv6 被拒的 App 已经很少了。

Networking stack changes

传统的网络分层模型中,接口层和传输层 TCP/IP 都在内核态;剩下的协议处理在用户态;数据在这两者间传输时需要做一些上下文切换。

为了提升性能,iOS 11中协议栈都被放入了用户态;这将使得网络调度更加合理,CPU 和线程使用更加优化;使用 NSURLSession CFNetwork 等高层 API 就可以直接享受这些便利;直接使用 BSD sockets 将没有这项优化;

New NetworkExtension facilities

自 iOS 9 开始,新增了 NetworkExtention.framework, 他提供了 4 种扩展形式,参见这里

  1. 移动wifi热点接入;
  2. 个人VPN接入;
  3. 企业VPN 服务器接入;
  4. 数据内容过滤;

iOS 11 新增了 2 个 Network Extension:NSHotspotConfiguration 和 NSDNSProxyProvider。

  • NSHotspotConfiguration

帮助你将同一个 Wifi 网络内的智能设备接入 Wifi;举了一个智能相机的例子;过去你只能在相机里查找 Wifi并接入,而现在通过这个 Extionsion,可以直接在 App 里进行智能硬件的接入;

硬件的接入时长可以是永久的可以是临时的,可以精确控制在 App 周期内;同时支持认证接入;

接入代码也很简单:

  • NSDNSProxyProvider

增强了 DNS 的处理能力,你可以自己定义 DNS 的解析服务器,也可以指定访问 DNS 的协议为 TLS 或者 HTTP。

Multipath protocols for Multipath Devices

移动设备经常会遇到 Wifi 和移动网络频繁切换的场景,如果 Wifi 信号很弱,请求会经常出现中断和丢包重传的情况,而此时移动网络通道并未被使用;因为 TCP/IP 协议是几十年前的产物,设计时并没有考虑到移动网络和多通道的场景;苹果很早就开始注意到这个问题,并持续优化;早在 iOS 9 中苹果加入了 Wifi assist。iOS 11 中苹果推出了 MultiPath TCP 和相关的 API 来提升用户体验;

Multipath TCP 建立在 TCP 的基础之上(RFC6824,Jan 2013),提供更好的链接可靠性和拥塞控制;支持 Wifi 和移动网络的无缝切换,对延时敏感的数据流选择最优通道进行数据交互; 简言之,MP TCP 会在客户端到服务端间建立 Wifi 和移动链接两套通道,当 Wifi 信号变弱时会启用移动链接,而 Wifi 信号恢复时,切回 Wifi 网络。

这项技术 iOS 7 开始就已经在 Siri 中投入使用;在 Wifi 信号非常弱的 PCT95 情况下速度提升了 20%,相应成功率提升了 5 倍。

部署

Server Support 服务端支持需要 MPTC-capable 的服务器,新的Linux Kernel(https://multupac-tcp.org)都已经支持这项技术,直接部署在 Nginx 等 Load-Balancers 上即可。

客户端 API 上提供了 2 种类型 Handover Mode 和 Interactive Mode。

Handover Mode 提供更高的可用性,它不会在一开始就建立双通道,当 Wifi 信号变差时才建立移动链接,从而节省移动流量;在失败重试代价很高的网络请求下非常建议使用;切记不要用来下载大块数据。

Interactive Mode 适用于需要更短延时的场景,通常它会直接建立 2 条通道,即使 Wifi 网络也很好;Siri 使用的就是这种 Mode。

在 NSURLSession 上支持这两种 mode 非常简单。

只需要设置 URLSessionConfiguration 的 multipathServiceType 属性即可。

最后还介绍了一直 Aggregation Mode 聚合模式,目前还在试验阶段,可以在开发者选项里打开这种模式。

总结:

经过 2 年多的实验,苹果终于将 ECN 在系统层面上支持,这将有效的优化网络拥塞和最大化利用网络资源;IPv6 也将逐渐发挥优势成为主流;MP-TCP 技术从某种程度上是对“古老的” TCP 协议的扩展,更好的利用起了移动设备多通道;

相信随着 QUIC,TLS1.3 等新技术的发展,下一代网络通信协议会给我们带来更快的响应速度和更高的安全性;

References

https://developer.apple.com/videos/play/wwdc2017/707/
https://en.wikipedia.org/wiki/Explicit_Congestion_Notification