As mentioned above, retransmission timeout depends on the OS.  The typical defaults have been 3 seconds, followed by somewhere between two to four decays giving 3-5 retransmit attempts depending on the configuration details.

In Windows up until recent Windows 10 updates the value is in the registry under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\InitialRtt (or Tcpip6) which defaults to 3000 milliseconds, which is 3 seconds. The time is doubled, then doubled again, then disconnected, but the number of attempts is also adjustable with the TcpMaxDataRetransmissions in the same Parameters location.  

Windows 10's current version supports rfc6298 which uses a timer based on the recent typical round trip time rather than a static amount of time.  It still uses a 3 second delay for the initial SYN handshake, but then uses the dynamic round trip time with a floor of at least 1 second. That is, if round trip time is under 1 second it uses a 1 second, then 2 second, then 4 second delay. If it normally takes more than one second then the delay is 1 RTO, then 2 RTO, then 4 RTO.  You can still modify the initial round trip time estimation and the number of data retransmissions by modifying the registry values.

Linux machines have more configurable options. If it supports the rfc6298 optimizations (which most do since mid-2012) then you can see the per-connection RTO value using the ss -i command. Depending on your system configuration you can adjust the RTO or the F-RTO settings. 

Anyway ...

The key point is that with WebSockets (and any other TCP system) you as the developer cannot control retransmit timings.  Since it is stream based your stream is blocked until the data is retransmitted, and the retransmission time can be many seconds long.  If that is acceptable to the game, then use it.  If that is not acceptable to the game, use UDP and implement your own variation of the sliding window protocol, or use a library that implements them for you.