减少 app 的网络延时

音乐 （减少App的网络延迟） 欢迎收看 “减少App的网络延迟” 我叫斯图尔特·切希尔 今天 我将讨论导致 网络App感觉缓慢的因素 然后由我的同事韦迪·格尔 介绍可以用来提高网络App 响应速度的技术和API 让我们先谈论一些您可能已经 在iOS的WWDC测试版中 遇到的情况 如果您查看开发者选项 您将在网络部分看到一个 名为“响应性”的新项目 虽然上传吞吐量 下载吞吐量 和ping的空闲值都很有趣 但影响网络App响应性的 主要因素是网络在 工作条件下的响应性 而不是空闲条件 您在未连接到互联网的情况下 可通过典型的互联网速度测试 空闲ping值测量结果 来了解当前网络连接的工作情况 但重要的是当您连入互联网时 其工作情况如何呢 点击测试 测试过程中 会有产生网络流量的警告 会测量网络几秒钟 然后网络在工作状态下的表现 就一目了然了 该工具以每分钟往返次数 或RPM（每分钟转数） 而不是毫秒来报告网络响应性 我们创建了这个新的RPM指标 因为毫秒对很多人来说是 一个相当抽象的概念 人们也更熟悉 越高越好的“指标” RPM指标产生的数字范围 从几百RPM到几千RPM 就像汽车发动机的RPM一样 在macOS上也有这个测试工具 的命令行版本 叫做“网络质量” 您可能认为家庭或工作网络 有很低的ping值 但那只是在空闲的时候 在iPhone或Mac上 运行这个网络质量测试 您可能会发现 当网络在使用的情况下 它的响应性会变得差很多 我的意思是它确实会变得差很多 您的网络可能存在 20毫秒的空闲往返时间 这听起来很好 但您可能会发现在工作条件下 往返时间高达600毫秒或更长 这糟糕了30倍 工作状态下的网络响应性 对App的用户体验至关重要 我们都经常遇到这个问题 尤其是在视频会议期间音频 和视频冻结和退出的情况下 高网络延迟对所有App 都会产生不利影响 但我们已经习惯了这一点 所以只有当它影响视频会议时 我们才会注意到它 当我们在视频会议中遇到问题时 我们认为可以 通过增强互联网连接性来解决 人们已经从每秒几兆比特发展到 千兆比特甚至更高 但是问题仍然存在 对于视频会议来说 每秒几兆应该足够了 那么为什么我们仍然有这些问题呢？ 在网络缓冲区过大的情况下 当它们被填满时 并不会提高吞吐量 但会增加延迟 我们通常认为互联网是这样运行的 数据包在网络中快速流动 但是如果我们仔细观察云内部 我们会发现它实际上更像这样工作 您看到的从网络中传输出的数据包 与接收到的数据包并不是同一个 数据包会花费大量时间 停留在过大的网络缓冲区中 这种缓冲区过大的现象 被称为“缓冲区溢出” 但是尽管它对日常网络使用有影响 直到现在也还没有被广泛测量 好消息是 有现代的队列管理算法 比如CoDel—— 控制延迟排队算法—— 可以消除缓冲区溢出 当网络排队队列较短时 数据包在网络中等待的时间 会大大减少 有可能同时获得高吞吐量和 低延迟 这不是非此即彼的选择 也不是零和博弈 我们正与业界合作 部署更智能的队列管理算法 并提高工作环境下的 网络响应性 但就目前而言 如果您想给用户带来出色的体验 您会想让App像今天这样 适应互联网 缓冲区溢出 是导致App 产生网络延迟的主要因素 但它不是延迟的唯一来源 还有软件和硬件处理时间 随着CPU变得越来越快 这一处理时间继续缩短 另外就是实际的数据传输时间 随着数据速率从 每秒千比特到每秒兆比特 再到每秒千兆比特的增加 传输时间继续缩短 然后是由于网络缓冲 造成的时间延迟 正如我所说的 我们正在与业界合作 以降低这些延迟 但是总会有 光速信号传播延迟 回到20世纪90年代 横跨美国 从斯坦福到麻省理工的ping值 （往返）已经不到100毫秒 这已经非常接近光速极限了 所以不会变得更好 我们正在努力减少其他三种延迟 但光速延迟永远不会消失 所以这就是为什么在设计App时 考虑网络往返时间很重要 当我们谈论 考虑网络往返时间时 我们在谈论什么样的App？ 众所周知，视频会议受到 高网络延迟的严重影响 同样，网络游戏也受到 高网络延迟的严重影响 但这影响了所有使用网络的App 我指的是获取天气预报 股票报价 行车方向 这会影响网页浏览 它会影响观看流媒体 视频时的向前跳转 想想有多少App在等待网络连接时 包含一些动画旋转 延迟指示 也许您的App也是如此 我们显示“请等待”指示 这样用户就不会 认为App已被挂起 在用户等待缓慢的网络时 我们花了这么多精力 做出一些东西给他们看 是非常不错的 但我们也应该付出同样的努力 来减少他们等待的时间 如果在等待来自网络的数据时 您的App会显示一个延迟指示 那么有一些技巧可以 用来减少等待时间 App等待网络数据的时间 取决于一次网络往返 需要多长时间 以及App需要多少次网络往返 作为App开发人员 为了改善底层网络往返时间 您能做到的事情并不多 但您可以控制App 需要多少次网络往返 让我来介绍一下我的同事 维迪·戈尔 让她来告诉您如何做到这一点 谢谢 斯图尔特 大家好 我是韦迪 今天我想和大家谈谈 作为开发人员 您可以做些什么来 减少App中的网络延迟 App响应性与 网络往返次数成反比 让我向您展示如何 通过采用现代网络协议 来减少这些网络往返 并使您的App超级敏捷 为了加速您的App 请采用现代网络协议 如HTTP/3 & QUIC TCP Fast Open TLS 1.3和 Multipath TCP 有了这些技术 您的App在向用户传递数据时 可能会实现多次往返减少 所有这些现代协议都 需要服务器端支持 因此请向提供商咨询 他们的准备情况 我们很高兴地告诉您 所有这些技术 都可以在iOS和 macOS上使用 让我们来看看这些技术 首先 我们有 HTTP/3和QUIC 它们在iOS 15和macOS Monterey中默认启用 QUIC是一种 建立连接速度比TCP 和TLS快得多的传输协议 通过减少首行阻塞 QUIC可以显著减少向 用户交付数据的延迟 最棒的是：如果您已经在使用 URLSession 那么您已经准备就绪 如果您使用网络框架API 提供自己的应用层 并希望利用QUIC 只需使用QUIC参数创建 一个NWConnection 并设置一个TLS应用层 协议或ALPN 请查看 “使用HTTP/3和 QUIC加速网络”环节 了解如何在您的App中使用 这些技术的更多信息 QUIC在许多场景中都很有用 然而 对于某些App来说 TCP可能仍然是正确的选择 使用TCP时 您可以 通过将App数据 与TCP握手一起发送来 消除整个往返过程 网络框架和套接字都 支持TCP Fast Open 要与NWConnections 一起使用 有两个选项： 第一个选项是在您的连接上 允许Fast Open 在这种情况下 App将提供 随握手发送出去的初始数据 要启用此功能 请将 allowFastOpen参数 设置为true并创建连接 然后 在调用start之前 您可以调用send来 发送您的初始数据 当使用TCP Fast Open时 您必须小心 您只能通过握手 发送幂等请求 幂等基本上意味着数据在网络上 重放是安全的 还有一种使用 TCP Fast Open的方法 不需要您的App发送 自己的初始数据 如果您的App正在 使用通过TCP的TLS 您可以选择发送TLS握手消息 作为初始数据 要启用此功能 请转到您的特定TCP的选项 并将enableFastOpen 设置为true 使用TCP Fast Open的 推荐方法 是通过网络框架API 但是如果您的App是 在套接字上构建的 那么您将使用相应的标志调用 connectx应用编程接口 以指定您想要通过握手发送 幂等数据 我几次提到幂等 让我解释一下这意味着什么 以及为什么握手时只 发送幂等请求很重要 幂等且重放安全的操作 如果执行多次 则没有额外的效果 例如 当用户访问 developer. apple.com网页时 该网页的HTTP GET请求 通过TCP握手发送出去 如果该请求的确认 在网络中被延迟或丢弃 设备将重新发送 HTTP GET请求 该请求可能被路由 到不同的服务器 这一次 确认和 HTTP响应一起到达 由于HTTP GET请求在 通过网络重新发送时没有 任何附加效果 因此它被视为 幂等请求 现在 假设用户 正在尝试购买一台 新的iPhone 12 为此操作发送的HTTP请求 不是幂等请求 如果每次在网络上重播数据时 请求都发送到不同的服务器 则可能会导致多次交易 记住这一点 让我们来谈谈TLS 1.3 与TLS 1.2相比 TLS 1.3消除了 握手的整个往返过程 它还提供了更强的安全性 自iOS 13.4以来 默认情况下 它为URLSession和 NWConnection启用 TLS 1.3协议定义了 早期的数据支持 通过将幂等请求与 TLS握手消息一起发送 可以节省又一次往返 让我们换个话题 看看Multipath TCP 它在减少网络延迟方面的 工作方式有点不同 当设备从一个网络切换到 另一个网络时 Multipath TCP 允许单个TCP连接继续 要获得MultipathTCP的 低延迟特性 请使用交互模式API 它将节省建立新连接 所需的所有往返行程 系统将自动为您的数据包 选择更快的网络路径 要从客户端选择加入 请在 您的URLSession配置或 NWParameters上将 multipath ServiceType属性 设置为交互式 为了让您了解使用这些现代技术 可以节省多少往返行程 让我们从一个参考点开始 假设您的App当前正在 通过TCP运行TLS1.2 在这种情况下 需要四次往返 才能将第一个字节传递给用户 如果您的服务器从TLS 1.2 切换到TLS 1.3 则您的连接将消除整个往返行程 如果您在您的连接上启用了 TCP Fast Open 您又将节省一个往返行程 在iOS 15中 通过QUIC的HTTP/3 可以减少到两次往返行程 QUIC协议还定义了 早期数据支持 这可以进一步减少到 一次往返行程 根据我们在Apple的测量 用户通常会看到往返时间 有时高达600毫秒 让我们看看这对 您的App来说意味着什么 600毫秒的四次往返 意味着您的用户等待数据到达的时间 几乎是两秒半 这算是花费了大量时间用于 等待和盯着网络旋转 通过采用现代网络协议 您可以将第一个 字节的时间从2.4秒 减少到大约半秒 当数据提前一秒半到达时 用户肯定会注意到差异 每个想要出色网络性能的开发人员 都应该注意往返次数 这是成功的关键所在 我谈到的所有技术 都有助于在现实网络环境下 减少App中的网络延迟 如果您在5G LTE或快速 Wi-Fi网络上测试您的App 您可能会觉得您的App 响应性不错 但是用户并不总是在最好的 网络条件下使用您的App 为了模拟真实的网络 开发者选项菜单中 提供了针对iOS的 Network Link Conditioner工具 对于macOS 可以从 Apple Developer 网站下载 该工具是一种可靠且可重复的方法 可在用户日常生活中可能经历的 不同网络条件下测试您的App 如果您还记得的话 斯图尔特之前提到过 对于减少网络往返时间 您无能为力 好吧 这不完全正确 让我解释一下 当您正确地向系统 通知您的App流量时 如何减少网络往返时间 大多数App都有自己 发送或接收的混合流量 运行多个App时 用户的设备会交换大量数据 在现实网络中 如家庭或办公室Wi-Fi 许多设备共享同一个网络 这些设备在使用一组App的同时 发送和接收大量数据 为了避免在这个共享 网络中建立长队列 您必须对您的App数据 进行适当的分类 以便系统能够有效地 管理您的流量 从而保持较低的网络延迟 当您让系统保持低网络延迟时 您的App的前台流量会更快 因此对用户来说最重要的数据 会更快传递 让我用一个例子来说明 许多App会预加载图形 音频文件等内容 以供日后使用 当App预加载大量数据时 网络可能就是这个样子 瓶颈队列可能会变满 如果此时用户启动了一个网络活动 比如查看他们的配置文件页面 那么这个请求的响应 将在网络队列的末尾排队 可能需要几秒钟才能显示配置文件 这并不是好的用户体验 现在 让我们看看 当我们将这些 非用户启动的预加载任务 标记为后台时 网络会发生什么 将这些非用户发起的传输标记为后台 将极大地减少网络队列的大小 该队列随后将可用于其他前台数据 因此 任何前台数据 即绿色数据包 将立即交付 以获得快速、愉快的体验 在iOS 15和 macOS Monterey中 后台服务类型有了显著的改进 我们为后台上传和下载增加了 新的拥塞控制算法 这些新算法不仅显著降低了网络延迟 以获得更好的用户体验 还确保后台传输与 其他流量几乎在同一时间完成 让我们看看您可以 采用哪些网络API 来利用 后台服务类型 当您的App处于前台 并执行非用户发起的传输时 您将使用 默认的URLSession 并将网址请求的 网络服务类型设置为后台 同样 这让系统保持低网络延迟 对于NWConnection 您可在NWParameters中 将服务类设置为后台 如果您的App启动了 长时间运行的传输 无论它是否为用户启动的 您都将创建一个 后台URLSession 来继续运行 即使您的App被挂起 对于时间不敏感的任务 您可将 isDiscretionary 属性设置为true 这将允许系统等待最佳条件 来执行传输 我们已经讨论了您的App 如何帮助缩短网络队列 另一个延迟来源可能是 发送设备本身 历史上 网络堆栈使用 非常大的发送缓冲区 这增加了许多不必要的延迟 有时大约几秒钟 甚至在数据包进入网络之前 早在2015年 我们就为 URLSession 和NWConnection 修复了这个问题 但是互联网上的大多数服务器 都运行在Linux上 使用BSD Sockets 请与您的服务器运营商联系 确保他们正在使用 TCP NotSent Low WaterMark套接字选项 来减少源端的延迟 采用现代网络协议 来消除多次往返 为下一步做好准备 使用后台模式预取资产 批量传输和非紧急任务 测试您的App在不同 网络条件下的性能 对此 网络链接调节器 是一个很好的工具 保持较低的网络延迟 可以提高App的响应速度 并增强整体用户体验 感谢收看 祝您参加WWDC愉快！ 音乐