5

I would like to ask if I should expect some different round-trip time (sending some information to the server and recieving a response) when implemented with web sockets (message) compared to a standard HTTP GET. I assume that the web socket is already connected and the DNS is resolved.

As far as I understand it it would be different if GET would consist of multiple roundtrips in the underlying protocol, which I'm not sure of. Otherwise I would expect the same results.

tillda
  • 18,150
  • 16
  • 51
  • 70

2 Answers2

19

WebSockets seem to have a lower round trip time. I ran some tests locally and on a remote server, averaging the trip times for 100 requests at a time:

Local:
WebSocket:   2.46ms
Ajax:        9.97ms

Remote:
WebSocket:  93.41ms
Ajax:      183.49ms

The tests were done with Node.js with express and socket.io on the server, and Chrome with socket.io's library on the client. The remote tests were run over a 3G connection.

Update: At home on a much lower-latency connection, the numbers are a bit different:

Websocket:  63.02ms
Ajax:       72.11ms

This suggests that latency has a larger effect on HTTP requests than on WebSocket connections, which is likely because HTTP has to make a couple more round trips to reestablish a connection for each request, as you mentioned.

Joe Friedl
  • 751
  • 3
  • 10
  • 1
    are you sure chrome's aggressive caching didn't affect the result of this test? can you publish the test? – jchook Dec 13 '13 at 02:06
  • Unfortunately, the test was lost over the two years since I wrote it. The method involved sending data to the server and waiting for a response, though, so I don't think it's likely caching could've affected the results. – Joe Friedl Dec 17 '13 at 17:46
2

It depends on the initial scenario you are considering.

Example 1: You already have an HTTP 1.1 connection in place in one case and a WebSocket already established in the other case. In this scenario the round trip for both cases will be exactly the same, because in both cases you already have the TCP connection established and no further application-handshake is necessary. (Note: the quantity of data sent for the two cases will be different, but this impacts bandwidth, not latency, that is, round-trip time).

Example 2: You already have an HTTP 1.1 connection in place in one case (because perhaps you just downloaded the last image in your page) and no WebSocket opened in the other case. Well, in this scenario the round-trip time over HTTP will be lower than the round-trip time over WebSocket. The reason is that with HTTP you only need to send a TCP segment and receive a TCP segment (single round trip). With WebSockets you need to set-up the TCP connection and to perform the WS handshake, which involves a few round trips.

Alessandro Alinone
  • 4,934
  • 2
  • 18
  • 22
  • Not quite. Even though HTTP 1.1 is able to pipeline multiple requests in the same TCP connection, this doesn't mean it has the same latency as a WebSocket connection. There is a ton of processing on both the client and server that happens for every HTTP request response that adds to the latency of HTTP requests. Each HTTP header in the request and response generally has some processing required. For example, just one small example is cookie marshalling and unmarshalling. In WebSockets the "HTTP" header processing only happens on initial connection setup. – kanaka Dec 03 '11 at 23:54
  • 1
    @kanaka: That's not fully correct. HTTP 1.1 pipelining is something different. It's a specification for sending multiple GET or POST requests on the socket without waiting for a response before sending the next request. HTTP 1.1 pipelining has never taken off. What I referred to in my explanation was HTTP "keep-alive", which is availbel for both HTTP 1.0 and 1.1 (where it id the default behavior). – Alessandro Alinone Dec 06 '11 at 09:35
  • @kanaka: I don't agree on your processing considerations too, because this shifts the discussion to the optimization of the application layer. You might have a very unoptimized WebSocket server that is slow in processing requests and a super-optimized HTTP Server that is very fast in processing cookies or even ignore them for the purpose of that specific application. – Alessandro Alinone Dec 06 '11 at 09:38
  • Alessandro: you're right, I was meaning TCP connection re-use that HTTP 1.1 enables. But in practice you can't get away from processing considerations. Just because an theoretical HTTP server *might* be as low overhead as a WebSockets server, in practice it won't be. And it's not just the server, the client/browser also does far more processing to process HTTP request (XMLHttpRequest) and responses than to generate/process a WebSockets frame and that is true (and will be true) for all popular browsers. – kanaka Dec 07 '11 at 00:05