HTML5 websockets 当前使用一种 TCP 通信形式。然而，对于实时游戏来说，TCP 就无法解决问题（这也是使用其他平台的一个很好的理由，比如原生平台）。因为我可能需要 UDP 来继续一个项目，所以我想知道 HTML6 的规范是否支持 UDP？
此外，是否有任何可靠的 WebSocket 基准可以将 WS 协议与低级的直接套接字协议进行比较？
【问题讨论】：
标签： performance html udp websocket
在 LAN 上，您可以获得 200 微秒的 WebSocket 消息往返时间（从浏览器 JS 到 WebSocket 服务器并返回），这类似于原始 ICMP ping。在 MAN 上，大约 10 毫秒，WAN（通过住宅 ADSL 到同一国家的服务器）大约 30 毫秒，依此类推，通过 3.5G 达到大约 120-200 毫秒。关键是：基于网络，WebSocket 确实不会给你无论如何都会得到的延迟增加任何延迟。
WebSocket 的线路级开销（与原始 TCP 相比）在每条消息 2 个八位字节（长度 64k 的屏蔽有效负载）之间（前面的数字假设消息不是分割成多个 WebSocket 帧）。非常低。
有关 WebSocket 线路级开销的更详细分析，请参阅blog post - 这也包括涵盖 WebSocket 之外的层的分析。
更重要的是：使用能够进行流处理的 WebSocket 实现，您可以（在初始 WebSocket 握手之后）在每个方向上启动单个 WebSocket 消息和帧，然后发送最多 2^63 个八位字节而完全没有开销。从本质上讲，这使 WebSocket 成为原始 TCP 的花哨前奏。警告：中介可能会根据自己的决定分割流量。但是，如果您运行 WSS（即安全 WS = TLS），则没有中介可以干扰，并且您有：原始 TCP，带有 HTTP 兼容前奏（WS 握手）。
WebRTC 使用 RTP（= 基于 UDP）进行媒体传输，但还需要一个信令通道（可以是 WebSocket，即）。 RTP 针对容损实时媒体传输进行了优化。 “实时游戏”通常意味着传输的不是媒体，而是玩家位置等东西。 WebSocket 将为此工作。
注意：WebRTC 传输可以通过 RTP 或通过 SRTP 进行保护。请参阅“RTP 配置文件”here。
【讨论】：
我建议在本地有线网络上使用 WebSockets 开发您的游戏，然后在 WebRTC 数据通道 API 可用后转移到它。正如@oberstet 正确指出的那样，WebSocket 平均延迟基本上等同于原始 TCP 或 UDP，尤其是在本地网络上，所以它应该适合您的开发阶段。 WebRTC 数据通道 API 的设计与 WebSockets 非常相似（一旦建立连接），因此一旦广泛可用，集成应该相当简单。
您的问题暗示 UDP 可能是您想要的低延迟游戏，这是事实。您可能在编写游戏时就已经意识到这一点，但对于那些尚未意识到这一点的人，这里有一个 TCP 与 UDP 的快速入门，适用于实时游戏：
TCP 是一种有序、可靠的传输机制，而 UDP 是尽力而为。 TCP 将按照发送的顺序传递所有发送的数据。 UDP 数据包在到达时发送，可能是无序的，并且可能有间隙（在拥塞的网络上，UDP 数据包在 TCP 数据包之前被丢弃）。 TCP 听起来像是一个很大的改进，它适用于大多数类型的网络流量，但这些功能是有代价的：延迟或丢弃的数据包也会导致所有后续数据包延迟（以保证按顺序交付）。
实时游戏通常不能容忍 TCP 套接字可能导致的延迟类型，因此它们使用 UDP 处理大部分游戏流量，并具有处理丢失和乱序数据的机制（例如，添加序列有效载荷数据的数字）。如果您错过了敌方玩家的一次位置更新，这没什么大不了的，因为几毫秒后您将收到另一次位置更新（甚至可能不会注意到）。但是，如果你在 500 毫秒内没有获得位置更新，然后突然将它们全部取出一次，那将导致糟糕的游戏玩法。
综上所述，在本地有线网络上，数据包几乎从不延迟或丢弃，因此 TCP 作为初始开发目标非常合适。一旦 WebRTC 数据通道 API 可用，您可能会考虑转向该 API。当前提案具有基于重试或计时器的可配置可靠性。
以下是一些参考资料：
【讨论】：
长话短说，如果您想在多人游戏中使用 TCP，您需要使用我们所说的自适应流技术。换句话说，您需要确保为在客户端之间同步游戏世界而发送的实时数据量由每个客户端当前可用的带宽和延迟控制。
动态节流、合并、增量传递和其他机制是自适应流技术，它们不会神奇地使 TCP 像 UDP 一样高效，但足以使其适用于多种类型的游戏。
我试图在一篇文章中解释这些技术：Optimizing Multiplayer 3D Game Synchronization Over the Web (http://blog.lightstreamer.com/2013/10/optimizing-multiplayer-3d-game.html)。
上个月，我还在旧金山举行的 HTML5 开发者大会 上发表了关于这个主题的演讲。该视频刚刚在 YouTube 上发布：http://www.youtube.com/watch?v=cSEx3mhsoHg
【讨论】：
没有对 Websockets 的 UDP 支持（确实应该有），但是您显然可以使用 WebRTC 的 RTCDataChannel API 进行类似 UDP 的通信。这里有一篇好文章：
http://www.html5rocks.com/en/tutorials/webrtc/datachannels/
RTCDataChannel 实际上使用的是 SCTP，它具有可配置的可靠性和有序的交付。您可以让它像 UDP 一样工作，方法是告诉它无序传送消息，并将最大重传次数设置为 0。
不过我还没有尝试过。
【讨论】：
我想知道 HTML6 或其他规范是否支持 UDP？
WebSockets 不会。 WebSockets 的好处之一是它piggybacks the existing HTTP connection。这意味着对于代理和防火墙，WebSockets 看起来像 HTTP，因此它们不会被阻止。
由于security concerns，任意 UDP 连接可能永远不会成为任何 Web 规范的一部分。最接近您所追求的东西可能会作为WebRTC 的一部分出现，并且与JSEP protocol 相关联。
是否有任何可靠的基准……将 WS 协议与低级的直接套接字协议进行比较？
我不知道。我将冒险出去并预测 WebSockets 会更慢；）
【讨论】：