79

HTML5 websockets currently use a form of TCP communication. However, for real-time games, TCP just won't cut it (and is great reason to use some other platform, like native). As I probably need UDP to continue a project, I'd like to know if the specs for HTML6 or whatever will support UDP?

Also, are there any reliable benchmarks for WebSockets that would compare the WS protocol to a low-level, direct socket protocol?

bobbybee
  • 1,758
  • 1
  • 16
  • 27

5 Answers5

229

On a LAN, you can get Round-trip times for messages over WebSocket of 200 microsec (from browser JS to WebSocket server and back), which is similar to raw ICMP pings. On MAN, it's around 10ms, WAN (over residential ADSL to server in same country) around 30ms, and so on up to around 120-200ms via 3.5G. The point is: WebSocket does add virtually no latency to the one you will get anyway, based on the network.

The wire level overhead of WebSocket (compared to raw TCP) is between 2 octets (unmasked payload of length < 126 octets) and 14 octets (masked payload of length > 64k) per message (the former numbers assume the message is not fragmented into multiple WebSocket frames). Very low.

For a more detailed analysis of WebSocket wire-level overhead, please see this blog post - this includes analysis covering layers beyond WebSocket also.

More so: with a WebSocket implementation capable of streaming processing, you can (after the initial WebSocket handshake), start a single WebSocket message and frame in each direction and then send up to 2^63 octets with no overhead at all. Essentially this renders WebSocket a fancy prelude for raw TCP. Caveat: intermediaries may fragment the traffic at their own decision. However, if you run WSS (that is secure WS = TLS), no intermediaries can interfere, and there you are: raw TCP, with a HTTP compatible prelude (WS handshake).

WebRTC uses RTP (= UDP based) for media transport but needs a signaling channel in addition (which can be WebSocket i.e.). RTP is optimized for loss-tolerant real-time media transport. "Real-time games" often means transferring not media, but things like player positions. WebSocket will work for that.

Note: WebRTC transport can be over RTP or secured when over SRTP. See "RTP profiles" here.

Community
  • 1
  • 1
oberstet
  • 21,353
  • 10
  • 64
  • 97
  • +1 - very useful set of timings. You might want to review the "...between 2 and a couple..." sentence though – simonc Oct 24 '12 at 08:39
  • +1 as it is hard to get any numbers from the establishment and the supporting advertisers. The numbers that I get are of the same order of magnitude, but bigger by a factor of 2. More like 400 microsec on LAN and 60ms with echo.websocket.org. – Tony Aug 21 '13 at 04:13
  • 1
    Although highly real-time games, such as FPS require some not-too-important data to be transferred in unreliable manner, just to prevent slight overhead when packets are lost in TCP (they are resent by underlying network layer). So for example player position - it is important to have most recent, rather than all of data. Though nowadays, the difference between quality and speed is not that relevant anymore, so WebSockets are the way to go that is for sure. – moka Mar 12 '14 at 14:18
  • How about an action web browser rpg game similar to Path of Exile? Would Websockets be fine for handling player skills, monster ai, etc? [Example](http://gamedev.stackexchange.com/questions/111601/websocket-scalability-w-player-skills) I know you said player positions would be fine, so I think the answer is yes? Just curious, thank for the great write up! – NiCk Newman Nov 19 '15 at 06:25
  • NiCk Newman, web sockets are a way to transfer information, so asking if its a way to handle monster ai is a little off the wall. That being said, I believe you would be absolutely fine with web sockets for an rpg style game – Mr Bell Dec 08 '15 at 18:47
  • The blog post link is broken, the new location can be found [here](https://crossbario.com/blog/Dissecting-Websocket-Overhead/). – porkbrain Jan 16 '19 at 21:33
  • Hi @oberstet what's your opinion on using Websockets for real-time audio/video conferencing solution? – quarks Apr 26 '20 at 17:17
  • @quarks as a default (without knowing any specific requirements) I would probably go with WebRTC for media streams and WebSocket for media session control. websocket isn't optimized for media streaming at least. but possible of course. another thing to factor in: QUIC is coming ... and that'll again shift cards at the transport protocols level a bit .. – oberstet May 01 '20 at 12:13
  • I tested in my WLAN, same data and devices, TCP AVG 57ms, UDP 25ms (but with some lost packets, because my WIFI router is far from my bedroom :D). For my solution I can use Tokens, ignoring lost or late packets. – edwell Aug 25 '22 at 18:35
54

I would recommend developing your game using WebSockets on a local wired network and then moving to the WebRTC Data Channel API once it is available. As @oberstet correctly notes, WebSocket average latencies are basically equivalent to raw TCP or UDP, especially on a local network, so it should be fine for you development phase. The WebRTC Data Channel API is designed to be very similar to WebSockets (once the connection is established) so it should be fairly simple to integrate once it is widely available.

Your question implies that UDP is probably what you want for a low latency game and there is truth to that. You may be aware of this already since you are writing a game, but for those that aren't, here is a quick primer on TCP vs UDP for real-time games:

TCP is an in-order, reliable transport mechanism and UDP is best-effort. TCP will deliver all the data that is sent and in the order that it was sent. UDP packets are sent as they arrive, may be out of order, and may have gaps (on a congested network, UDP packets are dropped before TCP packets). TCP sounds like a big improvement, and it is for most types of network traffic, but those features come at a cost: a delayed or dropped packet causes all the following packets to be delayed as well (to guarantee in-order delivery).

Real-time games generally can't tolerate the type of delays that can result from TCP sockets so they use UDP for most of the game traffic and have mechanisms to deal with dropped and out-of-order data (e.g. adding sequence numbers to the payload data). It's not such a big deal if you miss one position update of the enemy player because a couple of milliseconds later you will receive another position update (and probably won't even notice). But if you don't get position updates for 500ms and then suddenly get them all out once, that results in terrible game play.

All that said, on a local wired network, packets are almost never delayed or dropped and so TCP is perfectly fine as an initial development target. Once the WebRTC Data Channel API is available then you might consider moving to that. The current proposal has configurable reliability based on retries or timers.

Here are some references:

Community
  • 1
  • 1
kanaka
  • 70,845
  • 23
  • 144
  • 140
  • 1
    Valid point: TCP in-order, guaranteed delivery can add latency. And yes, player positions probably can tolerate some loss, but what about player hits? I'd say the interesting numbers for real-time games over WebSocket are: median and i.e. 99.9% quantile RTTs on the network the game is supposed to run. I don't have measurements for WAN .. but there sure will be some "it depends" factors. – oberstet Oct 24 '12 at 15:19
  • 6
    Applications can build reliable in-order channels on top of unreliable transports and then choose which channel to use depending on the data type but you can't do the reverse. And generally, critical information is maintained by a server anyways (to avoid spoofing and cheating). I've built a real-time game using WebSockets (1110.n01se.net) and it works great (as an experiment), but I've seen the impact of transport delays under load that could be significantly alleviated by an unreliable transport mechanism. – kanaka Oct 24 '12 at 16:14
  • 9
    Just to clarify, I think WebSockets are great, and for many situations where you want browser based low-latency communication (including games) they are exactly the right choice. But there are reasons why AAA real-time games typically use UDP rather than TCP (or a mix). WebSockets is built on TCP and has the same advantages and disadvantages as TCP. UDP over WebSocket has been asked for in the working group (for real-time games) and Data Channel via WebRTC is the answer that was given: http://lists.whatwg.org/htdig.cgi/help-whatwg.org/2011-August/000920.html – kanaka Oct 24 '12 at 16:27
24

To make a long story short, if you want to use TCP for multiplayer games, you need to use what we call adaptive streaming techniques. In other words, you need to make sure that the amount of real-time data sent to synchronize the game world among the clients is governed by the currently available bandwidth and latency for each client.

Dynamic throttling, conflation, delta delivery, and other mechanisms are adaptive streaming techniques, which don't magically make TCP as efficient as UDP, but make it usable enough for several types of games.

I tried to explain these techniques in an article: Optimizing Multiplayer 3D Game Synchronization Over the Web (http://blog.lightstreamer.com/2013/10/optimizing-multiplayer-3d-game.html).

I also gave a talk on this topic last month at HTML5 Developer Conference in San Francisco. The video has just been made available on YouTube: http://www.youtube.com/watch?v=cSEx3mhsoHg

Alessandro Alinone
  • 4,934
  • 2
  • 18
  • 22
7

There's no UDP support for Websockets (there really should be), however you can apparently use WebRTC's RTCDataChannel API for UDP-like communication. There's a good article here:

http://www.html5rocks.com/en/tutorials/webrtc/datachannels/

RTCDataChannel actually uses SCTP which has configurable reliability and ordered delivery. You can get it to act like UDP by telling it to deliver messages unordered, and setting the maximum number of retransmits to 0.

I haven't tried any of this though.

Timmmm
  • 88,195
  • 71
  • 364
  • 509
3

I'd like to know if the specs for HTML6 or whatever will support UDP?

WebSockets won't. One of the benefits of WebSockets is that it piggybacks the existing HTTP connection. This means that to proxies and firewalls WebSockets looks like HTTP so they don't get blocked.

It's likely arbitrary UDP connections will never be part of any web specification because of security concerns. The closest thing to what you're after will likely come as part of WebRTC and it's associated JSEP protocol.

are there any reliable benchmarks ... that .. compare the WS protocol to a low-level, direct socket protocol?

Not that I'm aware of. I'm going to go out on a limb and predict WebSockets will be slower ;)

Community
  • 1
  • 1
robertc
  • 74,533
  • 18
  • 193
  • 177
  • 5
    "arbitrary UDP connections will never be part of any web specification". Depends on what you mean by "arbitrary". Certainly the [Data Channel](http://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-02) component of WebRTC allows arbitrary browser clients to connect together to send arbitrary data over a datagram (UDP) connection. If by "arbitrary" you mean "raw" UDP, then that is true. But the same applies to WebSockets; WebSocket connections aren't raw TCP connections either. – kanaka Oct 26 '12 at 16:18
  • 1
    @kanaka I mean you won't be able to connect to arbitrary clients and ports over UDP – robertc Oct 26 '12 at 16:49