我对构建一个小型的实时多人游戏感兴趣，使用HTML5/JavaScript作为客户端，可能使用Java作为服务器软件。WebSockets适合实时多人游戏吗？
我看了一下WebSockets，但看起来我对WebSockets实际上有些误解。我最初认为WebSockets只是JavaScript处理TCP套接字的方式，就像在Java和其他语言中使用一样，但看起来整个握手过程必须发生，并且每次传输都包含很多HTTP开销（并且在那种情况下，对Ajax的好处似乎并不像第一眼那样令人兴奋）？
关于相关主题，有没有更好的替代WebSockets用于此目的（JavaScript中的实时多人游戏）？
WebSockets是在网络浏览器中运行的实时多人游戏的最佳解决方案。正如在注释中指出的那样，初始握手的地方是HTTP连接升级，但一旦建立连接，WebSockets为服务器和客户端之间的双向通信提供最低延迟连接机制。
我建议你看这个：https://www.youtube.com/watch?v=_t28OPQlZK4&feature=youtu.be
看一看：
唯一的原料TCP的解决办法是使用支持某种TCPClient对象的插件。我建议你尝试一下WebSockets。
您可以找到多个选项here。只需在页面内搜索WebSockets即可。
也看看WebRTC。根据游戏的目的以及是否需要服务器来管理游戏状态，您可以使用此技术进行点对点通信。您可能仍然需要一个解决方案来处理玩家分组 - 在这种情况下，WebSockets是最快/最好的解决方案。
罗布霍克斯视频的链接被破坏，这是同样的谈话吗？ http://youtu.be/_t28OPQlZK4 –
@JasonSperske - 是的，谢谢。我也更新了这些例子。 – leggetter
多人游戏需要服务器向客户端发送世界状态的定期快照。在浏览器HTML/js应用程序的上下文中，您没有什么选择：轮询，websocket或编写自己的插件来扩展浏览器功能。
诸如BOSH或Bayeux的HTTP轮询非常复杂，但会引入网络开销和延迟。 websocket的设计是为了克服它们的局限性，而且肯定会更有反应。
库（例如cometd或socket io）提供传输的抽象并为您解决浏览器兼容性问题。最重要的是，它允许在底层传输之间进行切换，并且可以毫不费力地比较其性能。
我编码multiplayer arcade game与socket.io和通常措施2ms延迟与websocket和约30ms与xhr轮询在局域网上。这对多人游戏来说已经足够了。
我建议你看看nodejs和socket。io为了能够在客户端和服务器之间共享代码，您还可以在[3]上借用一些多人游戏代码。
如果您打算为您的游戏使用JavaScript，那么WebSocket是您的最佳选择。如果你想支持旧版本的Internet Explorer，那么请考虑微软开发的Signal R系统。他们正在使用WebSocket，但他们也有一些回退选项......所以协议将使用可用的最佳可用解决方案。
Socket.io也有倒退 – JorgeGarza
我不知道，如果WebSockets的仍然是网络 实时多人，这些天（2017年）的最佳工具。 WebRTC是一种较新的技术 ，它提供了更高性能的潜力。而这些 天的WebRTC也更容易与感谢合作，以下库：
另外，如果你想独善其身包装你的游戏，这是一个很好的匹配实现网络实现的实际细节，并且您正在寻找一个提供更高级别多人游戏界面的库，请看Lance.gg。 （免责声明：我是贡献者之一）。
基本上，你有3个选择在写这篇文章的时间：
的WebSockets
的WebSockets是一个轻量级的消息传递协议，它利用TCP，而不是一个Javascript实现TCP套接字的，因为你”已经指出。但是，除了最初的握手之外，还没有HTTP标头在该点之后传递。连接建立后，数据可以自由通过，开销很小。
长轮询
长轮询，概括地说，定期涉及到客户端轮询新的信息的服务器的HTTP请求。这在CPU和带宽方面非常昂贵，因为您每次发送大量新的HTTP标头。这对于旧浏览器来说实质上是您唯一的选择，而像Socket.io这样的库在这些情况下使用长轮询作为后备。
的WebRTC
除了什么已经被提及，的WebRTC允许通过UDP通信。由于UDP开销低（相对于TCP），低延迟和非阻塞性质，UDP在非网络环境中一直用于多人游戏。
TCP“保证”每个数据包将到达（除了灾难性的网络故障），并且他们将始终以发送的顺序到达。这对于重要信息（如注册乐谱，点击，聊天等）非常有用。
另一方面，UDP没有这样的保证。数据包可以以任何顺序到达，或根本不会。当涉及以较高频率发送并且需要尽快到达的较不重要的数据时，这实际上是有用的，例如播放器位置或输入。原因在于如果在传输期间单个数据包延迟，TCP流将被阻止，从而导致游戏状态更新中的较大差距。使用UDP，您可以简单地忽略延迟到达（或根本不到）的数据包，并继续下一次收到的数据包，为玩家创造更流畅的体验。
在撰写本文时，WebSocket可能是您最好的选择，尽管WebRTC的采用正在迅速扩大，并且在您完成游戏时可能更可取，所以这是需要考虑的问题。
实际上每个传输只包含两个字节的开销。 http握手只发生在打开新的websocket时，并且只要浏览器停留在该页面上，您就可以保持websocket处于打开状态。 –
是的，他们是。 HTTP握手完成一次以打开套接字。所以如果你在一封邮件后关闭套接字，开销会很大，如果你永远保持套接字打开，那么开销就不大。 – Raynos
为什么握手过程如此复杂？从我记得的，我们必须读一些字符串，其中最后一个字符是[随机]字符集合，然后必须以某种方式对base64进行编码并发送回客户端。我试图自己编写所说的服务器端握手代码，但它不起作用（握手过程从未完成，所以我永远无法发送和检索自己的数据包）。当使用其他人编写的Java程序包来做同样的事情时，我达到了同样的结果。 – Josh1billion