> ## Documentation Index
> Fetch the complete documentation index at: https://devdocs.xbox.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Medições de qualidade de serviço no GDK

> Medições de qualidade de serviço no Microsoft Game Development Kit

Use este tópico para entender como medir a qualidade de serviço (QoS) em um título do GDK. Para títulos multijogador, medir a latência de QoS é importante. Para conexões ponto a ponto, as medições de latência de QoS podem ser usadas para determinar se a jogabilidade com outro cliente é viável. Para conexões cliente/servidor, as medições de latência de QoS podem ser usadas para determinar o melhor local de datacenter para a jogabilidade.

Para títulos ERA do XBOX One, os soquetes seguros incluíam APIs de QoS para medições de latência e largura de banda. Os títulos do GDK podem obter a mesma funcionalidade, conforme descrito nas seções a seguir.

## Ponto a ponto

Os títulos que usam comunicação ponto a ponto podem usar uma implementação de QoS personalizada no código do título, no mecanismo de jogo ou no middleware.

Para todas as implementações, os títulos devem garantir que as diretrizes a seguir sejam atendidas.

* Práticas recomendadas de comunicação segura.
  Os títulos devem seguir a prática recomendada de proteger toda a comunicação de rede, independentemente do conteúdo. Isso também deve se aplicar às sondas de QoS UDP ponto a ponto. Essas sondas devem ser realizadas por meio de uma conexão de protocolo seguro. Para obter mais informações sobre as práticas recomendadas de protocolo seguro, confira [Comunicação segura da malha de jogo para títulos do Microsoft Game Development Kit (tópico sob NDA)](https://learn.microsoft.com/gaming/gdk/docs/gdk-dev/game-principles/security/communication-security/communication-security-impl/gc-secure-game-mesh-impl).
* Tamanho do pacote UDP (User Datagram Protocol).
  Para a comunicação UDP, os títulos devem garantir que não excedam a MTU (unidade máxima de transmissão) máxima da plataforma. O payload UDP máximo padrão por pacote é de 1.384 bytes para títulos do Microsoft Game Development Kit (GDK) em consoles XBOX e no Windows 10. Pacotes que excedem a MTU provavelmente serão fragmentados, o que pode levar a latência adicional ou pacotes descartados.
* Protocolo e canal de comunicação correspondentes.
  A QoS ponto a ponto deve sempre ser realizada pelo mesmo canal de comunicação e protocolo usados para o tráfego de jogabilidade. Isso garante que todas as medições reflitam o comportamento do tráfego de jogabilidade, incluindo atrasos e largura de banda.
* Comportamento de QoS na navegação de sessões.
  Os títulos que usam QoS como parte de listas de navegação de sessões podem acidentalmente criar uma inundação de QoS em hosts populares. Isso ocorre quando a lista de navegação de sessões é idêntica para todos os usuários e inclui testes automáticos de QoS. Nesse cenário, todos os usuários que exibirem uma lista de navegação de sessões realizarão testes de QoS nos principais hosts da lista. Isso pode levar a uma carga pesada e potencialmente inundar um host ou servidor. Recomendamos que os títulos randomizem parcialmente as listas de navegação de sessões para reduzir esse problema.
* Uso de largura de banda por outros recursos do título.
  Qualquer medição de QoS é afetada por outros comportamentos de rede locais ou remotos. Os títulos não podem afetar o comportamento do tráfego de outras plataformas ou sub-redes. No entanto, o controle do tráfego interno do título ainda é possível. Os títulos devem garantir isso, e os downloads do título ou outros usos da rede devem ser minimizados ao realizar medições de QoS. O mesmo se aplica a várias medições de QoS paralelas.

## Cliente/servidor

Os títulos que usam comunicação cliente/servidor podem usar uma implementação de QoS personalizada no código do título, no mecanismo de jogo ou no middleware. Ao contrário das medições de QoS ponto a ponto, o objetivo típico das medições de QoS cliente/servidor é determinar a latência para um datacenter específico. Os títulos nesse cenário devem garantir que sigam as mesmas diretrizes das medições de QoS ponto a ponto.

Os títulos que usam servidores multijogador do Azure PlayFab devem sempre usar as APIs fornecidas para medições de QoS. Para obter mais informações, confira [Usar beacons de QoS (qualidade de serviço) para medir a latência do jogador até o Azure](/pt-BR/services/playfab/multiplayer/servers/using-qos-beacons-to-measure-player-latency-to-azure).

## Considerações sobre métricas de QoS

As duas métricas de QoS mais comuns que determinam a qualidade da conexão são a *latência* dos pacotes e a *largura de banda* disponível no link.

* Teste de latência.
  A latência normalmente é testada por pacote entre dois pontos de extremidade. A prática recomendada é enviar um pequeno número de pacotes abaixo do tamanho da MTU local para um ponto de extremidade remoto, onde o pacote é ecoado de volta para o dispositivo local. Isso determina o tempo de ida e volta de um pacote. Para a medição, deve-se calcular a média de vários pacotes. A medição de latência pode ser realizada rapidamente.

* Teste de largura de banda.
  A largura de banda normalmente é testada enviando grandes volumes de dados com frequência crescente para outro ponto de extremidade para saturar o link local. A largura de banda do link pode ser inferida com base no estado do buffer local de envio e/ou recebimento. O aumento do uso do buffer indica que o link está saturado. As medições de largura de banda exigem uma duração de teste maior e podem afetar a qualidade do link local.

Latência e largura de banda geralmente estão fortemente relacionadas. A largura de banda limitada leva a uma latência de pacote maior, porque os pacotes são retidos localmente quando a rede está congestionada. A baixa latência indica mais largura de banda disponível, porque indica que os pacotes não estão sendo retidos localmente. Como resultado, os títulos devem realizar apenas medições de latência para fins de QoS do tráfego de jogabilidade. Testes de largura de banda geralmente não são necessários para o tráfego de jogabilidade.

## Teste de QoS

Os kits de desenvolvimento do XBOX One podem executar simulações de rede para simular largura de banda limitada, perda de pacotes e latência. É altamente recomendável usar essa funcionalidade para testar implementações de QoS personalizadas e para testes de ponta a ponta de toda a funcionalidade de QoS. Para obter mais informações, confira [Estresse de rede do XBOX One](/pt-BR/build/console-features/networking/tools/netstress-networking).

## Confira também

[Windows Sockets 2 (Winsock)](https://learn.microsoft.com/windows/desktop/WinSock/windows-sockets-start-page-2)

[PlayFab Party](/pt-BR/build/console-features/networking/game-mesh/playfab-party-intro-networking)

[Usar beacons de QoS (qualidade de serviço) para medir a latência do jogador até o Azure](/pt-BR/services/playfab/multiplayer/servers/using-qos-beacons-to-measure-player-latency-to-azure)


## Related topics

- [Visão geral de acessibilidade no GDK](/pt-BR/build/game-principles/accessibility/accessibility-overview.md)
- [XR-003 Qualidade do título para envio](/pt-BR/publishing/certification/xr/xr-003.md)
- [Notas de versão do PlayFab Party](/pt-BR/services/playfab/multiplayer/networking/release-notes.md)
- [XR-074 Perda de conectividade com os serviços XBOX e de parceiros](/pt-BR/publishing/certification/xr/xr-074.md)
- [Requisitos XBOX testados na certificação para jogos de console XBOX](/pt-BR/publishing/certification/console-cert-tested-requirements.md)
