为回合制游戏服务器选择哪种协议

我正在为Java中的回合制游戏编写游戏服务器.这些都是事实:

游戏的速度很慢,所以客户端需要每8秒发送一次数据,而且数据大部分时间只是一个小的增量更新(几十个字节),除了加入游戏或列表之类的情况可用游戏等

服务器必须支持大量的玩家,比方说1000,玩几百个游戏中的一个

当玩家转弯时,必须通知同一游戏中的其他玩家移动.游戏中玩家的最大数量约为10

首先,我从我的选项列表中排除了UDP,因为我需要一个可靠的协议,因为在极少数情况下我真的需要发送一些不适合一个数据包的数据,我不想打扰合并数据包和类似的东西,跟踪到达的包裹和其他低级别的东西的顺序.

所以困境在于是使用TCP还是HTTP.

TCP尝试#1

从客户端到服务器的连接(反之亦然)始终打开.这样,当玩家进行移动时,服务器可以容易地通知游戏中的其他玩家进行了移动.使用这种方法困扰我的主要问题是,是否建议甚至可以连续打开1000个连接和套接字？

TCP尝试#2

我想到的替代方案是,用于在客户端的每个请求上建立单独的连接/套接字.客户端将打开连接,将一些小数据发送到服务器并关闭该连接.使用这种方法,我可以有一个固定大小的线程池,比方说10,并在每个线程中单独处理客户端的请求,这样任何时候最多可以打开10个connectinos/socket.但是这种方法有两件事困扰我:

打开/关闭与客户端的连接的昂贵

在游戏中通知其他玩家的方式,因为与他们的联系很可能是关闭的.在这种情况下,每个人都应该"轮询"服务器进行更新,让我们说每一秒.

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

HTTP

如果我发送一个新的GET/POST只发送几个字节会有很多开销吗？

我可以同时保持与客户端的1000个HTTP连接,然后使用AJAX或类似的东西来减少开销吗？在这种情况下,1000个同时连接会对带宽/性能造成严重问题吗？

我接受任何形式的建议/意见.

仅供参考:HTTP 是 TCP.使用TCP的特定协议,即.HTTP基于TCP,就像TCP基于IP等.所以你真的选择在HTTP over TCP或TCP上的自定义协议之间.你是对的,UDP在这里不太匹配.

如果您自己编写服务器,使用HTTP的许多好处都会消失.HTTP的主要优点是已经有高度优化的服务器,因此您可以将其用作简单有效的RPC系统.但如果您自己编写服务器,那么您不太可能达到Apache之类的效率,因此您不得不问为什么您不会选择使用更简单的协议？此外,围绕HTTP的仅拉式特性进行攻击似乎是错误的方法.

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