Здравствуйте, Videoman, Вы писали:

V>Здравствуйте, Michael, Вы писали:

V>Да тут еще оказывается что у клиента WebSocket proxy стоял зачем-то, который тоже терял коннект и снова устанавливал соединение.
V>А вы не знаете зачем такая реализация? С обычным TCP же нет жесткого требования разрывать соединение в случае высокой нагрузки, ну не идет ответ и и ладно, ждем пока придет.

вообще WS внутри себя периодически шлёт контрольные пинги (https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API/Writing_WebSocket_servers )
и в нагруженной сети после потерь нескольких пингов он рвёт соединение (чтобы приложение знало "есть проблемы с сетью"). и по сравнению с TCP где можно долго
тупить пока не словишь дисконнект в WS сделано вроде по быстрее.

плюс могу ещё напомнить что есть лимит на кол-во параллельных соединений который браузер может делать на один домен.
(хотя не уверен что это к WS тоже относиться).
Кстати если у них прокси на базе nginx то там ещё по моему keepalive надо крутить иначе обрыв будет
по любому через какое-то время.