點對點
使用點對點通訊的遊戲，可以在遊戲程式碼、遊戲引擎或中介軟體中使用自訂 QoS 實作。 對於所有實作，遊戲都應確保符合下列指導方針。- 安全通訊最佳做法。 無論內容為何，遊戲都應遵循保護所有網路通訊的最佳做法。這也應適用於點對點 UDP QoS 探查。這些探查應透過安全通訊協定連線執行。如需安全通訊協定最佳做法的詳細資訊，請參閱 Microsoft Game Development Kit 遊戲的安全遊戲網狀通訊 (NDA 主題)。
- 使用者資料包通訊協定 (UDP) 封包大小。 對於 UDP 通訊，遊戲應確保不超過平台的最大傳輸單位 (MTU) 上限。在 XBOX 主機和 Windows 10 上，Microsoft Game Development Kit (GDK) 遊戲每個封包的預設最大 UDP 承載為 1,384 位元組。超過 MTU 的封包很可能會被分割，這可能會導致額外的延遲或封包遺失。
- 相符的通訊協定和通訊通道。 點對點 QoS 應一律透過與遊戲流量相同的通訊通道和通訊協定執行。這可確保所有測量都能反映遊戲流量的行為，包括延遲和頻寬。
- 工作階段瀏覽 QoS 行為。 在工作階段瀏覽清單中使用 QoS 的遊戲，可能會意外對熱門主機造成 QoS 洪泛。當所有使用者的工作階段瀏覽清單完全相同且包含自動 QoS 測試時，就會發生此情況。在此情況下，所有檢視工作階段瀏覽清單的使用者，都會對清單中排名最前面的主機執行 QoS 測試。這可能導致沉重的負載，並可能使主機或伺服器遭到洪泛。建議遊戲將工作階段瀏覽清單部分隨機化，以減少此問題。
- 遊戲的其他頻寬使用量。 任何 QoS 測量都會受到其他本機或遠端網路行為的影響。遊戲無法影響其他平台或子網路的流量行為。不過，仍然可以控制遊戲內部的流量。遊戲應確保在執行 QoS 測量時，將遊戲下載或其他網路使用量降至最低。這同樣適用於多個平行的 QoS 測量。
用戶端/伺服器
使用用戶端/伺服器通訊的遊戲，可以在遊戲程式碼、遊戲引擎或中介軟體中使用自訂 QoS 實作。與點對點 QoS 測量不同，用戶端/伺服器 QoS 測量的典型目標是判斷到特定資料中心的延遲。此情況下的遊戲應確保遵守與點對點 QoS 測量相同的指導方針。 使用 Azure PlayFab 多人遊戲伺服器的遊戲，應一律使用所提供的 API 進行 QoS 測量。如需詳細資訊，請參閱使用服務品質 (QoS) 信標測量玩家到 Azure 的延遲。QoS 計量考量
決定連線品質的兩個最常見 QoS 計量是封包延遲和可用的連結頻寬。- 延遲測試。 延遲通常是在兩個端點之間以每個封包為基礎進行測試。最佳做法是將少量低於本機 MTU 大小的封包傳送至遠端端點，再由遠端端點將封包回傳至本機裝置。這可判斷封包的來回時間。進行測量時，應將多個封包加以平均。延遲測量可以快速執行。
- 頻寬測試。 頻寬通常是透過以遞增的頻率將大量資料傳送至另一個端點來測試，以使本機連結飽和。連結頻寬可以根據本機傳送和/或接收緩衝區的狀態推斷。緩衝區使用量增加表示連結已飽和。頻寬測量需要較長的測試時間，而且可能會影響本機連結品質。