WebSockets、UDP和基准测试

Question

WebSockets、UDP和基准测试

79

目前HTML5的WebSockets使用一种TCP通信方式。然而对于实时游戏来说，TCP并不够用（这也是使用其他平台（如本地）的好理由）。因为我可能需要UDP来继续一个项目，所以我想知道HTML6或其他版本是否支持UDP？此外，是否有可靠的基准测试WebSockets协议与低级别直接套接字协议之间的比较？

- bobbybee

5个回答

54

我建议你使用本地有线网络上的WebSockets开发游戏，然后在WebRTC数据通道API可用时进行移植。正如@oberstet所指出的那样，WebSocket的平均延迟基本相当于原始TCP或UDP，特别是在本地网络上，因此对于开发阶段来说应该没问题。一旦WebRTC数据通道API广泛可用，它的设计就非常类似于WebSocket（一旦建立连接），因此集成起来应该相当简单。

你的问题意味着UDP可能是低延迟游戏所需要的，这是正确的。如果你正在编写游戏，你可能已经意识到了这一点，但对于那些不知道的人，这里有一个有关TCP和UDP的快速入门：

TCP是一种有序、可靠的传输机制，UDP是最好的尝试。TCP将传送所有发送的数据，并按发送顺序传送。UDP数据包按照它们到达的顺序发送，可能是无序的，并且可能存在间隙（在拥塞的网络中，UDP数据包在TCP数据包之前被丢弃）。TCP听起来像一个很大的改进，对于大多数类型的网络流量来说确实如此，但这些功能也有代价：延迟或丢失的数据包也会导致所有后面的数据包延迟（以保证有序传递）。

实时游戏通常无法容忍TCP套接字可能导致的延迟，因此它们使用UDP进行大部分游戏流量，并具有处理丢失和无序数据的机制（例如向有效负载数据中添加序列号）。如果你错过了敌方玩家的一个位置更新并在几毫秒后收到了另一个位置更新（而且可能甚至没有注意到），那就没什么大不了的。但是，如果你500毫秒没收到位置更新，然后突然一次性收到了所有更新，那将导致可怕的游戏体验。

尽管如此，在本地有线网络上，数据包几乎从不会延迟或丢失，因此TCP作为初始开发目标非常合适。一旦WebRTC数据通道API可用，你可以考虑转移到它上面。当前的提案基于重试或计时器具有可配置的可靠性。

以下是一些参考资料:

- kanaka

1

有效观点：TCP按顺序，保证传递可能会增加延迟。是的，玩家位置可能可以容忍一些丢失，但玩家的命中怎么办？我认为WebSocket实时游戏的有趣数字是：游戏应该运行的网络上中位数和例如99.9％分位数RTT。我没有WAN的测量数据...但肯定会有一些“取决于”的因素。 - oberstet

6

应用程序可以在不可靠的传输层上构建可靠的有序通道，然后根据数据类型选择要使用的通道，但不能反过来。一般来说，关键信息始终由服务器维护（以避免欺骗和作弊）。我已经使用WebSockets（1110.n01se.net）构建了一个实时游戏，并且表现很好（作为一个实验），但我已经看到了在负载下的传输延迟对性能的影响，这可能会通过使用不可靠的传输机制得到显着缓解。 - kanaka

9

只是为了澄清，我认为WebSockets很棒，在许多需要基于浏览器的低延迟通信（包括游戏）的情况下，它们是完全正确的选择。但是，AAA实时游戏通常使用UDP而不是TCP（或混合使用）的原因是有原因的。WebSockets建立在TCP之上，具有与TCP相同的优缺点。工作组已经要求通过WebSocket使用UDP（用于实时游戏），并且Data Channel通过WebRTC是给出的答案：http://lists.whatwg.org/htdig.cgi/help-whatwg.org/2011-August/000920.html - kanaka

24

简而言之，如果你想在多人游戏中使用TCP协议，你需要使用我们所称的自适应流媒体技术。换句话说，你需要确保针对每个客户端当前可用的带宽和延迟来控制实时数据的发送量，以在客户端之间同步游戏世界。

动态限速、合并处理、增量传输和其他机制都是自适应流媒体技术，它们不能像UDP一样神奇地使TCP变得高效，但足以使其对于多种类型的游戏可用。

我在一篇文章中尝试解释了这些技术：在Web上优化多人3D游戏同步 (http://blog.lightstreamer.com/2013/10/optimizing-multiplayer-3d-game.html)。

上个月我还在旧金山的HTML5开发者大会上发表了关于这个主题的演讲。该视频刚刚在YouTube上发布：http://www.youtube.com/watch?v=cSEx3mhsoHg

- Alessandro Alinone

7

Websockets不支持UDP（其实应该支持），但是你可以使用WebRTC的RTCDataChannel API来进行类似UDP的通信。这里有一篇很好的文章：http://www.html5rocks.com/en/tutorials/webrtc/datachannels/。

RTCDataChannel实际上使用的是SCTP，它具有可配置的可靠性和有序传递。您可以通过告诉它无序地传递消息，并将最大重传次数设置为0来使其像UDP一样运行。

不过我还没有尝试过这些。

- Timmmm

1

还要注意这是Emscripten模拟UDP的方式。 - Timmmm

3

我想知道HTML6或其他版本是否支持UDP？

WebSockets不支持。 WebSockets的一个好处是它利用现有的HTTP连接。这意味着对于代理和防火墙，WebSockets看起来像HTTP，因此它们不会被阻止。

由于安全问题，任意UDP连接很可能永远不会成为任何网络规范的一部分。最接近您所需的内容将很可能作为WebRTC及其相关JSEP协议的一部分提供。

是否有可靠的基准测试...比较WS协议与低级别的直接套接字协议？

据我所知，没有这样的情况。我要冒险预测WebSockets会更慢 ;)

- robertc

5

“任意的UDP连接永远不会成为任何网络规范的一部分。” 由“任意”这个词的含义而定。当然，WebRTC的数据通道组件允许任意浏览器客户端相互连接，以通过数据报（UDP）连接发送任意数据。如果你所说的“任意”是指“原始”的UDP连接，则是正确的。但是同样适用于WebSocket；WebSocket连接也不是原始的TCP连接。 - kanaka

1

@kanaka 我的意思是你无法通过UDP连接到任意客户端和端口。 - robertc

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- oberstet · Accepted Answer

在局域网上，通过WebSocket发送的消息的往返时间为200微秒（从浏览器JS到WebSocket服务器再返回），与原始ICMP ping相似。在城域网上，约为10毫秒，在广域网上（通过家庭ADSL到同一国家的服务器），约为30毫秒，依此类推，最高可达3.5G，约为120-200毫秒左右。重点是：基于网络，WebSocket几乎不会增加任何延迟。

与原始TCP相比，WebSocket的线路开销每个消息通常为2个字节（未掩码负载<126个字节）至14个字节（掩码负载> 64k）。非常低。

有关WebSocket线路级开销的更详细分析，请参见此博客文章 - 这包括涵盖WebSocket以外层的分析。

更进一步说，WebSocket实现了流式处理能力，您可以（在初始WebSocket握手后）启动单个WebSocket消息和每个方向的帧，然后发送多达2^63八位字节而没有任何开销。本质上，这使WebSocket成为裸TCP的花哨前奏曲。注意：中间件可能会根据自己的决定分段流量。但是，如果您运行WSS（即安全WS = TLS），则没有中间人可以干扰，然后您就拥有了具有HTTP兼容前奏（WS握手）的裸TCP。

WebRTC使用RTP（=基于UDP）进行媒体传输，但还需要信令通道（也可以是WebSocket）。 RTP针对宽容丢包的实时媒体传输进行了优化。 "实时游戏"通常意味着传输的不是媒体，而是诸如玩家位置之类的东西。 WebSocket对此有效。

注：WebRTC传输可以通过RTP或SRTP保护。请参见“RTP配置文件”here。