游戏服务器与聊天服务器的区别

在游戏玩家和游戏开发者考虑多人游戏时，经常会遇到一个共同的问题。我是否应该重新利用现有的游戏服务器来处理聊天？或者，我是否应该隔离我的游戏服务器，在专用服务器中独立运行聊天？

那么，我们可以在以下两种情况中做出选择：

利用现有游戏服务器运行聊天
配置独立运行聊天的专用服务器

从表面上看，最大限度地利用现有资源似乎是一个合乎逻辑的选择。毕竟，它们只是聊天消息，对吗？向单个用户或一个小群发送的小消息，还不如直接利用已有的东西呢？有什么坏处呢？虽然一开始利用已有的东西似乎是个不错的选择，但选择这种设计模式可能会产生一些问题。

独立运行游戏服务器和聊天功能的好处

我们将向您介绍为什么要独立运行游戏服务器和社交功能（最重要的是聊天），这对游戏开发者和最终用户都有好处。这样，您就能提高游戏本身的性能和可扩展性，并在未来轻松扩展社交功能。

什么是 TCP 和 UDP？

从本质上讲，TCP 和 UDP 是用于互联网数据传输的网络协议。TCP 是一种面向连接的互联网协议，而 UDP 则是一种无连接协议。

关于多人游戏协议的最大争论是，什么时候应该使用 UDP（用户数据报协议），什么时候应该使用 TCP（传输控制协议），什么时候使用这两种协议最好？

在讨论这个问题之前，我们先来讨论一下在线游戏的架构。

简化您的在线游戏：UDP 与 TCP 游戏服务器

面向微服务的架构将大型应用程序（这里指的是您的游戏）分解成小的、独立版本的模块化服务，并通过简单、普遍可访问的应用程序接口相互通信。这使得构建新功能和维护已构建的带宽和功能变得更加容易。

将游戏服务器与聊天功能分离，可以使整个基础架构更易于管理，并更接近完全面向微服务的架构。在这种情况下，让我们具体看看游戏中的聊天功能，以及它与支持多人游戏的游戏服务器之间的关系。

在单体架构下，您的开发团队现在被锁定在一个单一的技术堆栈中–使用与游戏相同的编程语言、数据库和软件环境。在引入新的开发人员或希望对新技术和系统进行原型开发时，微服务架构更容易实现快速移动。

单体架构的依赖性也更为明显。如果单个应用功能出现故障，整个游戏就会瘫痪。将游戏拆分为微服务后，如果单个模块出现故障，就更容易隔离故障并加以修复。

您的游戏服务器是为实时提供玩家移动和状态而构建的，而且它们做得很好。如果将相同的技术和设计用于聊天消息，则根本无法达到最佳效果。

游戏基础架构示例：聊天与游戏服务器分离。我们还可以在游戏服务器之外运行其他服务，包括授权、存在、统计和排行榜。

保证无缝游戏体验和聊天性能：UDP 与 TCP 游戏服务器

整体游戏性能是多人游戏的一个重要考虑因素。采用整体架构的游戏在实验室中可能表现良好，但当游戏发布到一个由快速交流的大型游戏玩家组成的在线社区时，您可能会开始注意到延迟和延时的增加。这会影响聊天信息的传递和整体游戏体验。

将两者分开可确保更有效地使用 CPU 和网络资源。游戏服务器的主要目的是为游戏中的每个用户提供无缝体验。因此，处理能力应该用于最大限度地提高性能。

假设您有一款在线竞技场游戏，如《堡垒之夜》或《我的世界》。在一个世界中，同一时间可能有数百名玩家。每个玩家创建的每个输入都会通过游戏服务器发送成千上万条信息。然后再加上聊天信息。由于所有信息的优先级相同，玩家完全有可能在聊天频道中发送垃圾信息，故意拖慢游戏服务器的运行速度。

游戏服务器已经在处理密集型游戏体验——物理、图形、声音。再加上聊天信息：一对一、群组、团队，解析信息并将其发送给正确的用户，所有这些信息在大型游戏中都会慢慢积累，并损害游戏的整体性能。将聊天频道与多人游戏频道分开运行是一个简单易行的方法。这样做会窃取重要的处理能力，而这些能力可以更好地用于解决比路由聊天信息更复杂的问题。

平衡两者的需求：TCP 与 UDP

快节奏的多人游戏（第一人称射击游戏、竞技场游戏等）使用 UDP 协议来同步玩家移动和更新游戏状态。UDP 标头非常适合以快得离谱的速度发送这些游戏更新，但信息却无法保证（因为下一条信息很快就会到达）。

为什么 UDP 比 TCP 更受青睐？反之亦然？

TCP 连接能保证信息传递，因此是聊天的最佳选择。在 UDP 上运行游戏，在 TCP 上运行社交功能，都会有很好的表现。

不过，对于不那么激烈的多人游戏，如回合制游戏，TCP 是游戏和聊天的合适选择。因为 TCP 可以保证信息传递，而且在每一步都很重要的游戏中（如拼字游戏或井字游戏），它是支持多人游戏的最佳选择。当然，您仍然需要将聊天与游戏服务器连接分开，尤其是当您的游戏起飞，同时有成千上万的用户连接时。

在选择使用 TCP 和 UDP 实现不同功能时考虑延迟问题

延迟是另一个需要考虑的问题，因为多人游戏功能与社交功能的延迟标准不同。对于确保游戏状态和提供玩家输入的多人游戏来说，行业标准是不超过 20 毫秒。而对于聊天应用来说，发送聊天信息的最大延迟为 250 毫秒。因此，网络游戏有两种不同类型的实时信息传送，有两种不同的标准。让它们单独运行，就可以根据需要管理每种类型。

使用 TCP 或 UDP 协议轻松添加新的社交功能

将聊天作为独立服务运行，并选择行业标准网络协议（XMPP、WebSockets、ngrok）或托管服务（PubNub），就有机会轻松添加新的强大社交功能。

从核心聊天功能开始，允许用户进行个人和群组聊天。有了这些，你就有了底层基础架构以及基本的发布/订阅，你还可以在此基础上轻松创建许多其他社交功能。只需极少的代码，您就可以添加表桩聊天功能，如打字指示器、显示在线和离线玩家的存在以及未读消息计数器–这些都是用户所期待的功能。