细粒度速率限制术语
公平使用
XBOX 认为,无论用户玩什么游戏(或应用),每位用户都应获得相同的高质量体验。 细粒度速率限制 (FGRL) 解决了以下场景: 开发者 A 刚刚发布了一款遵循所有 XBOX 服务最佳实践的标题,可确保最佳地使用服务;而开发者 B 也刚刚发布了一款标题,但存在未知错误。 此错误导致该标题及每个用户不断发送 Presence 请求,使服务承受重负载。 服务变慢并最终停止,破坏了开发者 A 用户的体验,尽管问题是由开发者 B 的错误引起的。 如果实施了 FGRL,该服务本可停止接收来自行为异常标题的请求,从而使开发者 A 的标题能够获得其应有的资源份额。标题与用户粒度
之所以选择”标题与用户”作为关键,是为了确保 XBOX 资源的公平使用。 仅跟踪用户会造成用户体验受制于每个标题集成方式的场景。 例如,大多数标题已使用 people 服务,在此假设情况下,假定细粒度速率限制在 people 服务上设置为 5 分钟内不超过 100 次请求。 如果用户玩一款在 1 分钟内发出 100 次请求的游戏,则会超过限制,用户将无法再向 people 服务发出更多请求;设想在同一时段内用户随后返回主屏幕并点击好友列表:由于用户已经超过限制,该好友列表调用将失败,直到 5 分钟间隔过去,即使主屏幕并未导致用户进入受限状态。 或者,仅基于标题限制也会产生同样不公平的结果。 按标题设置限制会忽略标题的热门程度,请求将只是按先到先得的顺序处理,直到达到限制。 用户与标题的配对可确保任何标题都不会使用超出其活跃用户数量所对应的适当资源,同时也让每位用户获得一致的资源份额。
- 如果请求低于限制,则按正常方式处理。
- 如果发现请求达到或超过限制,则服务将丢弃该请求并返回 429 响应。
突发和持续限制
传统上,速率限制包含每个端点在给定时间段内跟踪的一个限制。 此时间段代表跟踪实体请求计数的持续时长。 在此期间结束时,实体计数将重置为 0,以便重新开始跟踪。 此方法适用于大多数 API;但是,这种方法对调用 XBOX 服务的游戏和应用来说不够稳健。 上述解决方案假设人们以稳定、一致、可预测的方式调用。 对于 XBOX 服务的情况,根据服务和请求标题的不同,调用模式差别很大。 在这种情况下只选择一个限制,需要在调用模式频谱的两端都作出妥协。 XBOX 服务解决方案使用两个时间段和两个限制。 较短的时间段称为突发 (Burst) 时段,较长的称为持续 (Sustain) 时段。 FGRL 的突发时段始终为 15 秒,而持续时段始终为 300 秒(5 分钟)。 因此,在 5 分钟的持续时段内,有 20 个突发时段。 突发和持续限制同时进行跟踪,因此也同时统计请求。 突发和持续限制均在服务上设置,这意味着每个服务都有自己的突发和持续计数。 为帮助您理解这两种限制如何协同工作,下表显示了一个用户玩某标题时向已实施 FGRL 的服务发出的一系列请求。 在此情况下,突发限制为 15 秒 30 次请求,持续限制为 5 分钟 100 次请求。
该表显示,在前 15 秒内用户通过发出 35 次请求触发了突发限制。
多出的 5 次请求被丢弃并发出 5 条 429 响应。
这 5 次请求虽然被限流,但仍计入持续限制。
一旦其中一项限制被触发,任何请求都不会被放行,如在 45 秒标记处两个限制都被触发时以及在 285 秒标记处仅发出 4 次请求时所示。
HTTP 429 响应对象
当关联的用户和标题计数达到或超过突发或持续限制时,服务将不再处理请求,而是返回 HTTP 429 响应。使用 XSAPI 时,这等同于 HRESULT 0x801901AD。 HTTP 429 代码表示”请求过多”,并附带包含”X 秒后重试”值的标头。 FGRL 429 响应对象包含一个”retry after”标头,用于指定调用方在重试前应等待的时间。 使用 XSAPI 的开发者无需担心,因为 XSAPI 会遵循并处理 Retry-After 标头。 实际响应将包含以下字段:已实施的限制
以下服务已实施 FGRL 限制,自 2016 年 5 月起开始实施这些限制。 这些限制在所有沙盒和标题之间相同。 任何通过 XBOX Developer Platform 或 Partner Center 发布并在 2016 年 5 月之前发货的标题都将被视为遗留标题,因此不受此限制。
上表代表当前选择用于 FGRL 的服务列表。
该列表并非最终版本,因为可能会添加新服务或现有服务。
当要添加服务时,该表将会更新,并将发布公告。
表中的限制可能会更改。
随着服务的变化和演进,限制也会随之调整;但会通知您,并作出必要的遗留豁免。
服务映射和速率限制对标题的影响
注意: 最新的 API 映射会定期更新,可在 Live 跟踪分析器 API 映射中查看。