文档

​
​

Development

User Acquisition

Monetization

工业

Multiplayer Services SDK

All Services

Multiplayer Services SDK

此页面不支持所选语言。
Multiplayer
​
​
Multiplayer Services SDK
  • Overview
  • Get started
  • Use multiplayer sessions
  • Manage sessions
  • Connect players through a relay
  • Networking
  • Matchmaking
    • Get started with matchmaking
    • Manage and configure matchmaking
      • Matchmaking rules
      • Matchmaking rule relaxation
      • Matchmaking with Quality of Service
      • Player segmentation
      • Matchmaker backfill
      • Matchmaking rule samples
      • Matchmaker A/B testing
    • Matchmaker troubleshooting
    • Integrations with other UGS services
    • Deploy Matchmaker configurations
  • Monitor and debug sessions
  • Tutorials
  • Reference
  1. Multiplayer Services SDK

Quality of Service

Use Quality of Service results to match players in regions with acceptable connection quality.
阅读时间4 分钟
最后更新于 16 天前

Quality of service (QoS) service helps to dynamically determine the available regions where a client would expect to get the best connection for their online session.
Matchmaker allows game clients to provide QoS results information for each player in a matchmaking ticket. The QoS results contain information about the connection quality from the clients to the QoS servers that reside near the game servers that could potentially host a game. The Qos results are defined by region and contain the latency and packet loss ratio values. Matchmaker uses these results to match players together in regions where the connection quality satisfies the requirements of a game.
注意
The QoS results contain server IPs. These IPs are not game server IPs, but QoS server IPs.

QoS rules

QoS rules use the QoS results on a ticket to define what a good connection quality for their match should be.
Consider the following example where the latency of all the players in the match must be under 100:
"MatchRules": [ { "Name": "QoS", "Type": "LessThanEqual", "Source": "Players.QosResults.Latency", "Reference": 100, "Not": false, "EnableRule": true }]

Relaxations

When using QoS rules, it is important to apply some relaxation to allow matchmaking to happen even if the player population in a region is low.
Consider the following example to relax the latency rule after 30 seconds:
"MatchRules": [ { "Name": "QoS", "Type": "LessThanEqual", "Source": "Players.QosResults.Latency", "Reference": 100, "Not": false, "EnableRule": true, "Relaxations": [ { "Type": "ReferenceControl.Replace", "AgeType": "Oldest", "Value": 150, "AtSeconds": 30 } ] }]

QoS considerations

Party matchmaking and QoS

For parties where more than one player is on a ticket, several strategies are possible to provide QoS information.
  • Have the different clients of the party provide their QoS results and then add those values to the ticket.
  • Have the different clients of the party provide their QoS results, make an average of the QoS results and then add those values to the ticket.
  • Provide the QoS results of the party leader.

Determine acceptable QoS limits

Most real-time games have thresholds for latency and packet loss above which gameplay quality is considered degraded (when gameplay quality is reduced, but is still technically playable) or impossible (when players are unable to maintain connection or the game logic does not function properly). Using QoS results in matchmaking prevents players from playing in regions where QoS is poor.
When determining these limits, remember to consider both the experience of the player with a poor connection and the experience of other players when playing in a game alongside a player that has a poor connection. For example, some game engines provide a reasonably good experience for a player with high latency or packet loss, but to other players, that player might appear to teleport to a degree that makes gameplay with that player impossible. In practice, this means that you have to process the per-region QoS results that are gathered by the client and then filter out the regions that are unacceptable or impossible for them to play in.
  • If a player's best available QoS result is outside of the acceptable latency or loss range for your title, but is still technically possible, you might want to consider filtering out all results except for the player's best result. This allows the player to at least find a match even if it is not a match with a good quality connection. In these scenarios, providing a connection quality warning to the player can help to set expectations that there might be gameplay issues.
  • If a player's best available QoS result exceeds your impossible threshold, it is recommended that you provide appropriate error messaging and prevent the player from playing.

QoS best practices

Consider the following best practices when you work with a game server hosting service's QoS protocol.
  • The latency and packet loss values per region that are included in a ticket should generally be an average or flattening of all responses for each QoS server that is contacted within that region. A weighted average of results that gives more weight to the most recent results might be a more accurate depiction of the current network quality.
  • Review your packet loss versus latency ratio. For example, for real-time games, a very low latency connection that would normally result in a standard game session could be impacted by even minimal packet loss.

Additional resources

  • QosResult

Copyright © 2026 Unity Technologies
法律信息隐私政策CookiesDocumentation Terms of Use请勿出售或分享我的个人信息您的隐私选择(Cookie 设置)

“Unity”、Unity 徽标及其他 Unity 商标是 Unity Technologies 或其附属公司在美国和其他地方的商标或注册商标(此处查看更多信息)。其他名称或品牌是其各自所有者的商标。

为方便起见,一些页面是机器翻译的,可能包含不准确的内容。如有信息不一致的情况,以英文版本为准。

  • 在本页上
    • QoS rules

      • Relaxations

    • QoS considerations

      • Party matchmaking and QoS

      • Determine acceptable QoS limits

      • QoS best practices

    • Additional resources


报告此页面的问题