java - 为回合制游戏服务器选择哪种协议(protocol)

Question

我正在用 Java 为回合制游戏编写游戏服务器。 这些是事实:

• 游戏的速度很慢，所以客户端需要发送数据，比方说每 8 秒发送一次数据，并且该数据大部分时间只是一个小的增量更新(几十个字节)，除了 join of the游戏或列出可用的游戏等。
• 服务器必须支持大量玩家，比方说 1000 人，他们玩几百个游戏中的一个
• 当玩家转弯时，必须通知同一游戏中的其他玩家该移动。游戏中的最大玩家数量为 10 人左右

首先，我从我的选项列表中排除了 UDP，因为我需要一个可靠的协议(protocol)，因为在极少数情况下我真的需要发送一些不能放在一个数据包中的数据，我不想为合并数据包和类似的问题而烦恼事情，跟踪到达包裹的顺序和其他低级的东西。

所以两难的问题是使用 TCP 还是 HTTP。

TCP 尝试 #1

从客户端到服务器(反之亦然)的连接一直处于打开状态。这样，当玩家移动时，服务器可以轻松通知游戏中的其他玩家移动了哪一步。这种方法让我感到困扰的主要问题是，始终打开多达 1000 个连接和套接字是否可取甚至可能？

TCP 尝试 #2

我想到的替代方案是，针对来自客户端的每个请求使用建立单独的连接/套接字。客户端将打开一个连接，向服务器发送一些小数据并关闭该连接。通过这种方法，我可以有一个固定大小的线程池，比如说 10，并在每个线程中分别处理客户端的请求，以便随时最多打开 10 个连接器/套接字。但是有两件事让我对这种方法感到困扰:

1. 打开/关闭与客户端的连接的代价
2. 通知游戏中其他玩家的方式，因为与他们的连接很可能已关闭。在这种情况下，他们每个人都应该“轮询”服务器以获取更新，比方说每隔一秒。

建立 TCP 套接字/连接的成本是多少？这是一项昂贵的操作还是仅需几毫秒(或更短时间)即可完成？

HTTP

1. 如果 我会发送一个新的 GET/POST 只是为了发送几个字节？
2. 我可以保持 1000 个 HTTP 连接到 客户端同时使用，然后使用 AJAX 或类似的东西来减少 高架？在那种情况下，1000 同时连接构成 有关的重大问题 带宽/性能？

我乐于接受任何类型的建议。

Answer 1

仅供引用:HTTP 是 TCP。即，使用 TCP 的特定协议(protocol)。 HTTP 基于 TCP，就像 TCP 基于 IP 等一样。所以实际上您的选择是在 HTTP over TCP 或自定义协议(protocol) over TCP 之间。你是对的，UDP 在这里不匹配。

如果您自己编写服务器，使用 HTTP 的许多好处就会消失。 HTTP 的主要好处是已经有高度优化的服务器可用，因此您可以将它用作简单有效的 RPC 系统。但是，如果您自己编写服务器，您不太可能达到 Apache 之类的效率，因此您不得不问为什么不选择一个更简单的协议(protocol)来使用？此外，绕过 HTTP 的只拉性质似乎是错误的方法。

考虑到这一点，我只会使用基于 TCP 的更轻量级的协议(protocol)。您可以更好地控制连接，并可以将更新通知感兴趣的客户端，而无需他们轮询更改。您还可以丢失 HTTP 请求/响应开销，这在您的情况下大多是多余的。您可以改为使用相当简单的定制协议(protocol)，可能基于 XML 或 JSON，或者可能是现有的可用 RPC 方法之一。