기술 자료

​
​

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분
최근 업데이트: 15일 전

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
법률 정보개인정보 처리방침쿠키Documentation Terms of Use개인 정보 판매 또는 공유 금지개인정보 보호 선택(쿠키 설정)

'Unity', Unity 로고 및 기타 Unity 상표는 미국 및 기타 지역 내 Unity Technologies 또는 그 계열사의 상표 또는 등록상표입니다(자세한 내용은 여기에서 확인하세요). 기타 명칭 또는 브랜드는 해당 소유자의 상표입니다.

일부 페이지는 편의를 위해 기계 번역되었으며 부정확한 내용이 있을 수 있습니다. 정보가 상충되는 경우, 영어 버전을 우선으로 참조하세요.

  • 보고 있는 페이지
    • QoS rules

      • Relaxations

    • QoS considerations

      • Party matchmaking and QoS

      • Determine acceptable QoS limits

      • QoS best practices

    • Additional resources


이 페이지의 문제 보고