点对点
使用点对点通信的游戏可以在游戏代码、游戏引擎或中间件中采用自定义的 QoS 实现。 对于所有实现，游戏都应确保遵守以下准则。- 安全通信最佳实践。 无论内容是什么，游戏都应遵循最佳实践来保护所有网络通信。这同样适用于点对点 UDP QoS 探测。这些探测应通过安全协议连接来执行。有关安全协议最佳实践的更多信息，请参阅 面向 Microsoft 游戏开发工具包游戏的安全 Game Mesh 通信 (NDA 主题)。
- UDP 数据包大小。 对于 UDP 通信，游戏应确保不超过平台的最大传输单元 (MTU)。对于 XBOX 主机和 Windows 10 上的 Microsoft 游戏开发工具包 (GDK) 游戏，每个数据包默认最大 UDP 有效负载为 1,384 字节。超过 MTU 的数据包很可能被分片，从而导致额外的延迟或丢包。
- 匹配的协议与通信通道。 点对点 QoS 应始终通过与游戏流量相同的通信通道和协议执行。这能确保所有测量都能反映游戏流量的行为，包括延迟与带宽。
- 会话浏览 QoS 行为。 在会话浏览列表中使用 QoS 的游戏可能会意外造成热门主机的 QoS 洪泛。当会话浏览列表在所有用户看来都相同并包含自动 QoS 测试时就会出现这种情况。这时所有查看会话浏览列表的用户都会对列表顶部的主机进行 QoS 测试。这会带来沉重的负载并可能对某个主机或服务器造成洪泛。建议游戏对会话浏览列表进行部分随机化以降低此问题。
- 其他游戏带宽占用。 任何 QoS 测量都会受到其他本地或远程网络行为的影响。游戏无法影响其他平台或子网的流量行为。但游戏内部流量仍可控制。游戏应确保这一点，在执行 QoS 测量时应最小化游戏下载或其他网络使用。多个并行 QoS 测量也是同样的原则。
客户端/服务器
使用客户端/服务器通信的游戏可以在游戏代码、游戏引擎或中间件中采用自定义的 QoS 实现。与点对点 QoS 测量不同，客户端/服务器 QoS 测量的典型目标是确定到某特定数据中心的延迟。此场景下的游戏应确保遵循与点对点 QoS 测量相同的准则。 使用 Azure PlayFab 多人游戏服务器的游戏应始终使用所提供的 QoS 测量 API。有关详细信息，请参阅 使用 QoS 信标测量玩家到 Azure 的延迟。QoS 指标注意事项
用于判断连接质量的两种最常见 QoS 指标是数据包 延迟 和可用链路 带宽。- 延迟测试。 延迟通常在两个端点之间按每包进行测试。最佳实践是向远程端点发送少量小于本地 MTU 的数据包，让该端点将数据包回显回本地设备。这样可以测得数据包的往返时间。测量时应取多个数据包的平均值。延迟测量可以快速完成。
- 带宽测试。 带宽通常通过以增长的频率向另一端点发送大量数据来测试，以将本地链路饱和。可以根据本地发送和/或接收缓冲区的状态推断出链路带宽。缓冲区使用增加意味着链路已饱和。带宽测量需要较长的测试时间，且可能会影响本地链路质量。