WebSockets、UDP 和基准测试
Posted
技术标签:
【中文标题】WebSockets、UDP 和基准测试【英文标题】:WebSockets, UDP, and benchmarks 【发布时间】:2012-10-13 23:50:43 【问题描述】:html5 websockets 当前使用一种 TCP 通信形式。然而,对于实时游戏来说,TCP 就无法解决问题(这也是使用其他平台的一个很好的理由,比如原生平台)。因为我可能需要 UDP 来继续一个项目,所以我想知道 HTML6 的规范是否支持 UDP?
此外,是否有任何可靠的 WebSocket 基准可以将 WS 协议与低级的直接套接字协议进行比较?
【问题讨论】:
【参考方案1】:在 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。
【讨论】:
+1 - 非常有用的一组时间。您可能想要查看“...在 2 和一对...之间...”这句话 +1,因为很难从机构和支持广告商那里获得任何数字。我得到的数字是相同的数量级,但大了 2 倍。在 LAN 上更像是 400 微秒,在 echo.websocket.org 上是 60 毫秒。 虽然FPS等高实时性游戏需要一些不太重要的数据以不可靠的方式传输,只是为了防止在TCP中丢失数据包时产生轻微的开销(它们被底层重新发送)网络层)。因此,例如球员位置——重要的是拥有最新的数据,而不是所有的数据。虽然现在,质量和速度之间的差异已经不再那么重要了,所以 WebSockets 肯定是要走的路。 类似流放之路的动作网页浏览器RPG游戏怎么样? Websockets 可以很好地处理玩家技能、怪物 AI 等吗? Example我知道你说球员位置可以,所以我认为答案是肯定的?只是好奇,感谢您的精彩文章! NiCk Newman,网络套接字是一种传输信息的方式,所以询问它是否是一种处理怪物 AI 的方法有点离题。话虽如此,我相信你绝对可以使用网络套接字来玩 rpg 风格的游戏【参考方案2】:我建议在本地有线网络上使用 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。当前提案具有基于重试或计时器的可配置可靠性。
以下是一些参考资料:
WebRTC Introduction WebRTC FAQ WebRTC Data Channel Proposal【讨论】:
有效点:TCP 有序,保证交付会增加延迟。是的,球员位置可能可以容忍一些损失,但是球员命中呢?我想说通过 WebSocket 进行实时游戏的有趣数字是:游戏应该运行的网络上的中位数和即 99.9% 的分位数 RTT。我没有 WAN 的测量值 .. 但肯定会有一些“取决于”因素。 应用程序可以在不可靠的传输之上构建可靠的有序通道,然后根据数据类型选择要使用的通道,但您不能反过来。通常,关键信息无论如何都由服务器维护(以避免欺骗和欺骗)。我已经使用 WebSockets (1110.n01se.net) 构建了一个实时游戏,它运行良好(作为一个实验),但我已经看到负载下传输延迟的影响,可以通过不可靠的传输机制显着缓解. 澄清一下,我认为 WebSockets 很棒,对于许多需要基于浏览器的低延迟通信(包括游戏)的情况,它们是正确的选择。但 AAA 实时游戏通常使用 UDP 而不是 TCP(或混合使用)是有原因的。 WebSockets 建立在 TCP 之上,具有与 TCP 相同的优点和缺点。工作组已要求通过 WebSocket 进行 UDP(用于实时游戏),通过 WebRTC 的数据通道是给出的答案:lists.whatwg.org/htdig.cgi/help-whatwg.org/2011-August/…【参考方案3】:长话短说,如果您想在多人游戏中使用 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
【讨论】:
【参考方案4】:没有对 Websockets 的 UDP 支持(确实应该有),但是您显然可以使用 WebRTC 的 RTCDataChannel API 进行类似 UDP 的通信。这里有一篇好文章:
http://www.html5rocks.com/en/tutorials/webrtc/datachannels/
RTCDataChannel 实际上使用的是 SCTP,它具有可配置的可靠性和有序的交付。您可以让它像 UDP 一样工作,方法是告诉它无序传送消息,并将最大重传次数设置为 0。
不过我还没有尝试过。
【讨论】:
另请注意,这是 Emscripten 模拟 UDP 的方式。【参考方案5】:我想知道 HTML6 或其他规范是否支持 UDP?
WebSockets 不会。 WebSockets 的好处之一是它piggybacks the existing HTTP connection。这意味着对于代理和防火墙,WebSockets 看起来像 HTTP,因此它们不会被阻止。
由于security concerns,任意 UDP 连接可能永远不会成为任何 Web 规范的一部分。最接近您所追求的东西可能会作为WebRTC 的一部分出现,并且与JSEP protocol 相关联。
是否有任何可靠的基准……将 WS 协议与低级的直接套接字协议进行比较?
我不知道。我将冒险出去并预测 WebSockets 会更慢;)
【讨论】:
“任意 UDP 连接永远不会成为任何 Web 规范的一部分”。取决于你所说的“任意”是什么意思。当然,WebRTC 的Data Channel 组件允许任意浏览器客户端连接在一起,以通过数据报 (UDP) 连接发送任意数据。如果“任意”是指“原始” UDP,那是真的。但同样适用于 WebSocket; WebSocket 连接也不是原始 TCP 连接。 @kanaka 我的意思是你将无法通过 UDP 连接到任意客户端和端口以上是关于WebSockets、UDP 和基准测试的主要内容,如果未能解决你的问题,请参考以下文章