WebSockets in Chrome and Firefox Disconnecting After One Minute of Inactivity

Question

I have found that WebSockets in Chrome and Firefox disconnect after exactly one minute of inactivity. Based on stuff I\'ve seen online, I was all set to blame proxies or some s

Answer 1

The WebSocket protocol specification defines Ping and Pong frames that can be used for keep-alive, heart-beats, network status probing. Ping means client/server is sending an iq to tell the other side server/client that to keep the connection alive and also the other side will send an acknowledgement with pong having same payload data.

You can also define a timeout when the browser stops respond or be considered dead.

read more: http://vunse.blogspot.in/2014/04/websocket-ping-pong.html

Answer 2

As much as i understood from researching this, this is caused by websocket timing out over a period of time when no data is sent. This is probably per browser.

You could use pings to resolve this or just reconnect when you need to use the socket again.

It makes sense to not keep sockets open when they are not used from server side as from browser side. For example, Chrome has a limit how many connections can be open, if the limit would be 64 connections and you have open 64 tabs (which is very likely for me as i always have loads of tabs open) and each tab is connected to a server, no more connections could be done (Actually similar thing happened to me once, when i ran out of available sockets in Chrome, funny).

There is proxy_read_timeout (http://nginx.org/r/proxy_read_timeout) which as well applies to WebSocket connections. You have to bump it if your backend do not send anything for a long time. Alternatively, you may configure your backend to send websocket ping frames periodically to reset the timeout (and check if the connection is still alive).

https://forum.nginx.org/read.php?2,236382,236383#msg-236383

Web Sockets have an idle timeout of 60 seconds: if you do not use a heartbeat or similar via ping and pong frames then the socket assumes that the user has closed the page and closes the socket to save resources.

https://www.codeproject.com/Questions/1205863/Websocket-is-closed-after-min

https://github.com/tornadoweb/tornado/issues/1070

Answer 3

Maybe not a clean solution but this is how I implemented websocket in JS to automatically reconnect when disconnected

var socket_main
const mainSocketMessageListener = (event) => {
  //retreive the data here
  console.log(event.data)
}

const mainSocketOpenListener = (event) => {
  console.log("Websocket opened")
  //Example of sending message to websocket here
  socket_main.send(JSON.stringify({
    event: "subscribe",
    data: ["all"]
  }))
}

const mainSocketCloseListener = (event) => {
  if (socket_main) {
    console.error('Websocket disconnected.')
  }
  socket_main = new WebSocket('wss://ws.example.com')
  socket_main.addEventListener('open', mainSocketOpenListener)
  socket_main.addEventListener('message', mainSocketMessageListener)
  socket_main.addEventListener('close', mainSocketCloseListener)
}

//connect the first time
mainSocketCloseListener()

Answer 4

It seems like if sockets are disconnected by the server after one minute of inactivity that would apply to IE and Edge just as much as Chrome and Firefox.

Hmmm, no, it doesn't. IE and Edge might be implementing a ping packet as part of the WebSocket protocol.

The WebSocket protocol includes support for a protocol level ping that the JavaScript API doesn't expose. It's a bit lower-level than the user level pinging that is often implemented.

This ping-pong traffic resets the timers in any network intermediaries (proxies, load balancers, etc') - and they all time connections to mark stale connections for closure (for example, the Heroku setup times connections at 55 seconds).

Most browsers trust the server to implement the ping, which is polite (since servers need to manage their load and their timeout for pinging...

...however it's also slightly frustrating, since browsers have no idea if a connection was abnormally lost. This is why many JavaScript clients implement a user level ping (i.e., a JSON {event: "ping", data: {...}} or another "empty" event message).

Anyway, I just wanted to point out that your assumption was incorrect, this is still a timeout occurring and the difference in browser behavior is probably related to the browsers themselves.

For a few specifics regarding nginx default timeouts (when proxying WebSocket connections) you can read @Hendry's answer.