如何在没有node.js的js中建立客户端-客户端连接？答案

【问题标题】：How to make client-client connection in js without node.js?如何在没有node.js的js中建立客户端-客户端连接？
【发布时间】：2023-03-28 17:06:01
【问题描述】：

我正在尝试用 JS 制作简单的井字游戏。

我几乎做了所有的事情。现在只有一件事要做。

我想让它可以与某人在线玩。

我想通过互联网在两个游戏之间发送数据。

很遗憾，我的服务器不支持 Node.JS。

有没有办法在没有任何服务器端“套接字”的情况下实现它。

我想我可以用XMLHttpRequest() 来保存/加载数据到/从服务器文件中并像这样玩，但我认为这需要很多代码，也许对于 ttt 它会足够快，但是对于更复杂的游戏是不够的。

我知道这很难，但是在 node.js 之前他们是怎么做到的？

【问题讨论】：

NodeJS 只是您可以选择的众多服务器端编程语言/框架之一。使用您的服务器可以支持的一个（尽管...AFAIK Node 在大多数平台上运行，所以不确定是什么阻止了您安装它，除非您指的是您购买的共享托管计划？）。它们都将支持 AJAX（即 XmlHttpRequest），并且许多都支持 WebSocket 连接（诚然，后者通常需要一些配置）。例如，PHP 和 ASP.NET 都肯定有 websocket 实现。有一个任何人都可以实现的 websocket 标准。
NodeJS 是 not a hard requirement 对于 WebSockets。
当然，您的另一个选择是迁移到支持您需要的服务器环境...通常最好在之前确定支持/环境要求设置服务器。
如果你使用 HTTP——这就是 XMLHttpRequest 和它更现代的兄弟如 Fetch API 使用的——你首先使用的是面向流和带宽的 TCP 协议（如与延迟相反），最重要的是再次为 HTTP 支付延迟——其中请求和响应可能超过您的数据有效负载，甚至在您构建请求和解析响应正文之前就必须对其进行解析。根据您游戏的性质，您可能需要使用 WebSockets 或 WebRTC（如果您必须有 P2P）。否则，HTTP 可能就足够了。
"有 WebSocket 支持，只是我的托管计划上的任何配置方式都被阻止，所以将没有配置" ...如果已经支持，那么您可能不需要做很多配置。通过配置，我的意思是安装 websocket 组件并使套接字连接正常工作。如果托管公司已经支持它，那么您应该没有太多问题。

标签： javascript node.js websocket xmlhttprequest

【解决方案1】：

对于像井字游戏这样玩家轮流进行的游戏，延迟肯定会排在通信中的其他所有因素之后。仅出于这个原因，仅使用 HTTP 协议进行通信，通常使用XMLHttpRequest 类或Fetch API，是一种非常合理的方法，可以为您节省大量编程工作。

否则，当需要一个或多个低延迟和/或RTC 频道时（希望有充分的理由），WebRTC 和 WebSocket 都是可行的候选者。

WebRTC 绝对可以做到点对点，而 WebSocket 使用客户端-服务器模型。但即使是 WebRTC 也需要“信令”服务来交换对等点标识符，然后最终切换到对等点之间直接通信。虽然设置 WebRTC 通信需要对等标识符，但 API 故意不涵盖对等标识符的交换方式——无论您想要设计信令服务，都取决于您。对于所有 WebRTC 关心，您可以将一个对等 ID“发布”到 HTTP 服务器并使用其他对等的 Web 浏览器检索它，反之亦然。 WebRTC 从已知的对等 ID 开始。

否则，如果配置为这样做，WebRTC 能够利用STUN 和/或TURN 服务在禁止任何两个客户端之间直接 IP 路由的网络上保持对等连接——a真正的点对点通信的必要前提。

并非在所有情况下都需要 STUN/TURN 服务，但了解平均网络状况，不使用 STUN 或 TURN 或两者都使用，您的应用程序对于任意网络上的任何两个客户端都不会非常可靠。就像在双方被至少一个防火墙或作为一个功能的顽固路由器隔开的情况下一样。

然后，TURN 服务将透明地路由 WebRTC 通信，充当中继。

STUN 服务会在客户端之间的防火墙上打孔，以便之后可以进行点对点通信。这意味着与 TURN 服务相比，在后者建立之后，它不会在通信中发挥任何积极作用。

WebRTC 有点复杂，尤其是如果您期望 API 类似于 send 和 receive，但开发人员应该可以理解简化的连接示例。

您可能也不需要直接使用 WebRTC API，有些库将 WebRTC 封装成一种或另一种更简单的 API，这些 API 同时隐藏了 WebRTC 的更多边缘或“样板”方面，这也有助于最大限度地减少由于不同的用户代理以不同的方式实现 WebRTC 的不同部分而臭名昭著，因此有陷入麻烦的风险。

其中一个库是 PeerJS，但毫无疑问还有其他库。

WebSocket API 与 WebRTC 不同，需要一个兼容 WebSocket 的服务器，而 WebSocket API 不做点对点。好消息是 1）WebSocket 兼容服务通常只是一个高级中继（通常与应用程序后端逻辑融合），尽管它在应用程序级别而不是 TURN 的会话级别上工作，并且 2）有很多“交钥匙”的 WebSocket 服务器实现。

【讨论】：

WebRTC 需要一个应用程序后端，即信令服务器。它具有您归因于 STUN 服务器的功能（其工作是告诉客户端其公共 ip）。许多信令服务器都是用 nodejs 编写的。
你是对的，尽管我认为信令服务器不是应用程序后端（因为前者可以是通用的，并且对应用程序几乎一无所知）。
WebRTC 对于这样的用例将是一种矫枉过正，没有真正意义。更好的方法是使用“一个”服务器在玩家之间协商消息。无论是 Node.js、Java、Go、Python 还是基于程序集的程序都几乎无关紧要。如果不想管理和维护后端，我会选择 PubNub、Pusher、Scaledrone 甚至 Firebase。
在我写完答案并且后者在我看到编辑之前接受之后，对问题进行了编辑以包含关键信息，即这是一个井字游戏，到那时为时已晚-无法删除已接受的答案。至于在井字游戏中使用 WebRTC，是的，我想这有点不必要，尽管我没有看到学习如何在 Web 浏览器之间完成 RTC 的危害。