HTML5 websockets 当前使用一种 TCP 通信形式。然而,对于实时游戏来说,TCP 就无法解决问题(这也是使用其他平台的一个很好的理由,比如原生平台)。因为我可能需要 UDP 来继续一个项目,所以我想知道 HTML6 的规范是否支持 UDP?
此外,是否有任何可靠的 WebSocket 基准可以将 WS 协议与低级直接套接字协议进行比较?
HTML5 websockets 当前使用一种 TCP 通信形式。然而,对于实时游戏来说,TCP 就无法解决问题(这也是使用其他平台的一个很好的理由,比如原生平台)。因为我可能需要 UDP 来继续一个项目,所以我想知道 HTML6 的规范是否支持 UDP?
此外,是否有任何可靠的 WebSocket 基准可以将 WS 协议与低级直接套接字协议进行比较?
在 LAN 上,您可以获得 200 微秒的 WebSocket 消息往返时间(从浏览器 JS 到 WebSocket 服务器并返回),这类似于原始 ICMP ping。在 MAN 上,大约 10 毫秒,WAN(通过住宅 ADSL 到同一国家的服务器)大约 30 毫秒,依此类推,通过 3.5G 达到大约 120-200 毫秒。关键是:基于网络,WebSocket 确实不会给你无论如何都会得到的延迟增加任何延迟。
WebSocket 的线路级开销(与原始 TCP 相比)在每条消息 2 个八位字节(长度 < 126 个八位字节的未屏蔽有效负载)和 14 个八位字节(长度 > 64k 的屏蔽有效负载)之间(前面的数字假设消息没有分段成多个WebSocket 帧)。非常低。
有关 WebSocket 线级开销的更详细分析,请参阅此博客文章- 这也包括涵盖 WebSocket 之外的层的分析。
更重要的是:使用能够进行流处理的 WebSocket 实现,您可以(在初始 WebSocket 握手之后)在每个方向上启动单个 WebSocket 消息和帧,然后发送最多 2^63 个八位字节而完全没有开销。从本质上讲,这使 WebSocket 成为原始 TCP 的花哨前奏。警告:中介可能会根据自己的决定分割流量。但是,如果您运行 WSS(即安全的 WS = TLS),则没有中介可以干扰,您就是:原始 TCP,带有 HTTP 兼容的前奏(WS 握手)。
WebRTC 使用 RTP(= 基于 UDP)进行媒体传输,但还需要一个信令通道(可以是 WebSocket 即)。RTP 针对容损实时媒体传输进行了优化。“实时游戏”通常意味着传输的不是媒体,而是玩家位置等东西。WebSocket 将为此工作。
注意:WebRTC 传输可以通过 RTP 或通过 SRTP 进行保护。请参阅此处的“RTP 配置文件” 。
我建议在本地有线网络上使用 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 的好处之一是它搭载了现有的 HTTP 连接。这意味着对于代理和防火墙,WebSockets 看起来像 HTTP,因此它们不会被阻止。
出于安全考虑,任意 UDP 连接可能永远不会成为任何 Web 规范的一部分。最接近您所追求的东西可能会成为WebRTC的一部分,并且它是相关的JSEP 协议。
是否有任何可靠的基准……将 WS 协议与低级的直接套接字协议进行比较?
不是我知道的。我将四处走动并预测 WebSockets 会更慢;)