大多数浏览器和
Developer App 均支持流媒体播放。
-
缩短网络延迟以提高 App 的响应速度
在尝试获取当代网络吞吐速率的益处的同时,了解网络延迟将如何对您 App 产生影响。学习如何改变您的 App 和服务器以便提高响应速度,以及如何让您的 App 做好准备,以利用因网络优化而实现的端到端延迟缩短。
资源
- Network Quality test in Go
- Network Speedtest by Ookla
- Responsiveness Test Server configuration instructions
- Waveform bufferbloat test
相关视频
WWDC23
WWDC22
WWDC21
-
下载
♪ 柔和乐器演奏的嘻哈音乐 ♪ ♪ 嗨 我是 Vidhi Goel 在这个视频中 我将为您介绍降低 App 网络延迟的方法 使其更快做出响应 首先 我会解释为什么降低延迟 对 App 的快速响应至关重要 其次 我将介绍 您在 App 和服务器中 为消除不必要的延迟 可以做的一系列工作 最后 我将向您展示为降低延迟 可在网络上执行的操作 网络延迟是数据从一个端点到达 另一个端点所需的时间 它决定了内容传递到 您 App 的速度 所有使用网络的 App 都可能受到 缓慢网络事务的影响 从而导致 App 体验不佳 例如 视频通话有时会卡顿 或反应迟钝 导致会议中断 为解决该问题 人们经常致电 服务供应商要求升级带宽 但问题依然存在 为找出问题的根本 您需了解 App 中的数据包 在网络中的传输方式 当您的 App 或框架 从服务器请求数据时 数据包由网络栈发出 通常认为数据包直接发送至 服务器 在网络中没有延迟 但实际上 网络中最慢的链路 通常有很长的数据包队列需要处理 因此 来自您 App 的数据包 实际上也排在这个长队列后面 要等到前面的数据包处理完毕 在最慢链路上排队增加了数据包在 您的 App 和服务器之间 每次往返的时间 当需要多次往返才能首次响应 您 App 发出的请求时 该问题会更加严重 例如 在 TCP 上 使用 TLS 1.2 时 得到第一个响应包的时间 是每次往返时间 乘以四 由于在网络中排队 单次往返时间已经增加 最终总耗时只能更长 有两个因素共同决定了 您 App 的响应能力 即每次往返的时间和往返次数 减少这两个因素 可降低您 App 的延迟 提高其响应能力 有一项研究测试了 增加带宽速度与降低延迟 对页面加载时间的影响 在第一个测试中 延迟固定不变 带宽速度从 1 增加到 10Mb/s 首先 将带宽速度 从 1 增加到 2Mb/s 页面加载时间减少近 40% 效果显著 但宽带速度增至 4Mb/s 后 每次增速 对页面加载时间的影响几乎为零 这就是为什么即使升级到千兆互联网 App 运行仍然会慢 第二个延迟测试的结果显示 延迟每减少 20 毫秒 页面加载时间随之线性递减 以上结果适用于您 App 中的 所有网络活动 现在 我来为您介绍 可采取哪些简单操作 来减少延迟 使您的 App 更快响应 您可采用新版协议显著降低 App 的延迟 例如 IPv6 TLS 1.3 和 HTTP/3 您只需在 App 中的使用 URLSession和 Network.framework API 一旦上述协议在您的服务器上被启用 就能自动被使用 自协议推出以来 我们看到 HTTP/3 的使用量 不断增加 短短一年 20% 的网络流量 都在使用 HTTP/3 协议 且数据仍在增长 对比不同 HTTP 版本的 Safari 浏览器流量 HTTP/3 的速度最快 在将请求完成时间的中位数看做是 往返时间的倍数时 HTTP/3 请求所花费的 时间只有 HTTP/1 的 一半多一点 这意味着您 App 发送的请求会更快得到响应 当设备从 Wi-Fi 移动到蜂窝网络时 需要花时间重新建立新连接 这可能会 使您的 App 处于卡顿状态 使用连接迁移可消除卡顿 要选择接入 请在您的 URLSession 或 NWParameters 上 将 multipathServiceType 属性 设置为 .handover 启用此选项 并确保其适用您的 App 如果您直接 用 UDP 设计自己的协议 iOS 16 和 macOS Ventura 引进了更好的方法 来发送数据报文 QUIC 数据报文 比普通 UDP 优点更多 最重要的是 QUIC 数据报文 可对网络拥堵做出反应 进而维持较低往返时间 并减少数据包损失 要选择接入客户端 需在您的 QUIC 选项上 将 isDatagram 设置为 true 并设置您要使用的 maxDatagramFrameSize 创建数据报文流后 您可像任何其它 QUIC 流 一样在上面发送和接收 现在您知道了在 App 中 降低延迟的方法 接下来我将解释服务器如何影响 您 App 的响应能力 尽管常在顶级硬件上运行 您的服务器仍然可能 拖慢您的 App 我们在 macOS Monterey 中 引进了网络质量工具 您可利用该工具 在您的服务供应商网络以及服务器上 测试缓冲区膨胀情况 您需配置您的服务器为 网络质量工具的目标 配置完成后 运行 networkQuality 工具 首先针对 Apple 的默认服务器 然后针对您自己配置的服务器 如果该工具在默认服务器上得分良好 但在您自己的服务器上得分较差 那可能您的服务器响应能力 有待提高 现在 我来向您展示 我们如何利用该技术 改进现在大家都在做的事情 流媒体视频
您可能有过这样的经历 您想将视频向前跳到某一位置 却要花很长时间等待缓冲 于是 我们在随机访问中调查了 缓冲较慢的原因 我们利用网络质量工具 测试流媒体服务器 发现其响应能力得分很差 我在右侧 播放了一个 WWDC 视频 然后 前跳该视频 视频在缓冲时 屏幕未显示任何画面 几秒钟后 画面才出现 借助 macOS 上 网络质量工具的输出详解 我们发现服务器上的队列很长 所以我们看了一下服务器配置 具体来说 我们查看了 TCP TLS 和 HTTP 缓冲区大小 配置分别为 4MB 256K 和 4MB 因为 RAM 充足 所以缓冲区很大 但缓冲有用 并不代表缓冲越多越好 响应能力测试突出了实际的问题 即在较大的缓冲区中 新生成的数据包 会排在旧数据后面 导致在传输最新数据包时 造成了很多额外延迟 因此 我们将 HTTP 缓冲区大小减至 256K TLS 减至 16K TCP 减至 128K
这是 Apache Traffic Server 的配置文件 显示的是已配置的选项 TCP 未发送低水位标记 设置为 128K 同时启用其他选项以降低缓冲 对于 TLS 我们启用了动态记录大小 对于 HTTP/2 我们降低了低水位标记 和缓冲区块大小 我们建议 您的 Apache Traffic Server 也使用相同配置 如果您使用的是其他网络服务器 请寻找等效选项 配置完成后 再次运行网络质量工具 这次获得了较高的 RPM 分数! 我在右侧播放相同视频 但这次前跳视频时 视频立即开始继续播放 消除了服务器上不必要的排队 随机访问响应就更快 无论您的 App 如何使用网络 在服务器上更改上述配置 都可让您的 App 更快响应 提供更好的用户体验 以上就是改进您的 App 并更新服务器的方法 还有第三个因素会极大影响响应能力 即网络本身 Apple 在 iOS 15 和 macOS Monterey 中 引进网络质量工具后 也有其他使用相同的方法 开展网络质量测试的 Waveform 发布了 Bufferbloat 测试 Go 编写了开源的 响应能力测试 Ookla 也在 其 Speedtest App 中 添加了响应测试 Ookla 的 App 以毫秒为单位显示往返时间 如果用 60000 除以往返时间 就会得到 每分钟的往返次数 或 RPM 您可以利用以上工具来测试 自己的网络性能 了解网络延迟的最佳方法 就是使用延迟敏感的 App 所以 我将向您展示 在远程计算机上的 屏幕共享的体验 我设置了网络条件 用于模仿一个有代表性的接入网络 并有来自其他设备的流量共享该网络 在此 我使用屏幕共享 登录到我的远程计算机
我点击了不同的访达菜单 但每个菜单显示得都比较迟钝 为了检查这种 互动行为的网络延迟情况 我在本地计算 启动了一个显示时间的 App 并在远程计算机上 启动了相同的 App 即便两台计算机的时间同步 但远程屏幕并未按时更新 显示的时间延迟了几秒钟 延迟更新的原因 是在网络最慢的链路上 有一个较长的队列 来自屏幕共享 App 的数据包 卡在了该队列中
为解决该队列问题 Apple 正与网络社区合作 共同开发 一项名为 L4S 的新技术 该技术将在 iOS 16 和 macOS Ventura 中以 Beta 版提供 L4S 可显著降低排队延迟 还可实现零拥堵损失 为维持较短排队时间 网络会明确发出拥堵信号 而不是丢弃数据包 发送器会根据网络拥堵反馈 调整发送速率 这就可以在网络中 维持非常短的排队时间 而不丢失数据包 进而让您的 App 快速响应 现在 我们来看看 L4S 如何改进屏幕共享 这里我用了相同的计算机和网络 不同的是 我启用了 L4S 我在点击各个访达菜单时 都可立即打开 我在两台计算机上 都启动了 Time App 现在 远程屏幕上的时间 和本地计算机上的几乎完全同步 L4S 技术不仅改进了屏幕共享 还改进了现今所有的 App 并为未来更加先进的 App 开放了大门 这张表绘制的是监控下 屏幕共享 App 数据包的 平均往返时间 该 App 与同一网络下的 其他设备同时消耗流量 对比常规排队与 L4S 排队 可看出启用 L4S 后 往返时间大大减少 这是屏幕共享体验显著改善的 主要原因 要用您的 App 在 HTTP/3 或 QUIC 上测试 L4S 您可在 iOS 16 中的 开发者设置中启用 L4S 或在 macOS Ventura 上 通过 defaults write 来启用 L4S 要用 Linux 服务器进行测试 您的 QUIC 实现 需要支持 Accurate ECN 和可扩展的拥堵控制算法 在部署支持 L4S 的网络时 要确保您已做好准备 测试您的 App 与 L4S 的兼容性 并就可能遇到的任何问题提供反馈 您已了解了降低延迟是 提高您 App 响应能力的关键 因此 采用 HTTP/3 和 QUIC 来减少往返次数 并将内容更快速地 传输到您的 App 消除服务器上不必要的排队 可提高交互时的响应能力 通过在开发者设置中启用 L4S 可测试您的 App 与 L4S 的兼容性并提供反馈 最后 再和您的 服务器供应商谈论一下 启用 L4S 的支持问题即可 感谢收看! ♪
-
-
6:21 - Enable connection migration on URLSessionConfiguration for HTTP/3
let configuration = URLSessionConfiguration.default configuration.multipathServiceType = .handover
-
6:29 - Enable connection migration on NWParameters for QUIC
let parameters = NWParameters.quic(alpn: ["myproto"]) parameters.multipathServiceType = .handover
-
7:08 - Opt-in to QUIC datagrams
// Only one datagram flow can be created per connection let options = NWProtocolQUIC.Options() options.isDatagram = true options.maxDatagramFrameSize = 65535
-
8:12 - Network quality tool in MacOS
networkQuality -s -C https://myserver.example.com/config
-
10:59 - Recommended configuration for Apache Traffic Server
% cat /opt/ats/etc/trafficserver/records.config # Set not-sent low-water mark trigger threshold to 128 kilobytes CONFIG proxy.config.net.sock_notsent_lowat INT 131072 # Set Socket Options flag to the sum of the options we want # TCP_NODELAY(1) + TCP_FASTOPEN(8) + TCP_NOTSENT_LOWAT(64) = 73 CONFIG proxy.config.net.sock_option_flag_in INT 73 ... # Enable Dynamic TLS record sizes CONFIG proxy.config.ssl.max_record_size INT -1 ... # Reduce low-water mark and buffer block size for HTTP/2 CONFIG proxy.config.http2.default_buffer_water_mark INT 32768 CONFIG proxy.config.http2.write_buffer_block_size INT 262144
-
12:52 - Responsiveness tests
https://www.waveform.com/tools/bufferbloat https://github.com/network-quality/goresponsiveness https://www.speedtest.net/
-
17:12 - Enable L4S for QUIC on Mac
defaults write -g network_enable_l4s -bool true
-
-
正在查找特定内容?在上方输入一个主题,就能直接跳转到相应的精彩内容。
提交你查询的内容时出现错误。请检查互联网连接,然后再试一次。