SockJS подключен как веб-сокет, но ничего не происходит

Я столкнулся с проблемой при использовании SockJS в определенной сети доступа. Думаю, это связано с тем, как SockJS выбирает лучший транспортный протокол (веб-сокет, долгий опрос,...) в зависимости от состояния сети.

Используя веб-браузер, мой клиент SockJS подключается с помощью транспортного протокола websocket к моему серверу SockJS узла. Я даже вижу событие «при подключении» на узле. Однако, когда я отправляю данные, через них ничего не проходит. Чтобы быть исчерпывающим, он отлично работает из некоторых других сетей доступа.

По результатам сайта http://websocketstest.com/ состояние этой сети доступа несколько особенное: для WebSockets (порт 80) он привязан к:

Connected       Yes✔
Data Receive    Yes✔

Чтобы убедиться, что веб-сокет работает хорошо, он также должен иметь строку «Время сервера», обновляемую каждую секунду тестовым сервером. Поскольку это не так, я почти уверен, что у меня есть прозрачный HTTP-прокси, который разрывает соединение через веб-сокет.

Однако SockJS этого не обнаруживает и не переключается на резервный протокол. Я думал, что это было разработано, чтобы сделать это.

Я ошибаюсь в отношении возможностей SockJS по согласованию транспорта?

Является ли Socket.IO более надежным для такого сценария или для такого типа сетей доступа с прозрачными прокси-серверами HTTP?

Я знаю, что мог бы использовать SockJS с SSL, но я думаю, что это скорее запасной вариант, а не решение.


person Vincent Hiribarren    schedule 05.02.2014    source источник


Ответы (1)


Я думаю, вы ошибаетесь насчет возможностей SockJS по согласованию транспорта. SockJS — это эмуляция веб-сокета. SockJS ведет себя как веб-сокеты. Действительно, если веб-сокеты поддерживаются клиентом, они будут использоваться. Но, конечно, некоторые браузеры не поддерживают веб-сокеты, о чем позаботится SockJS. Резервный механизм используется для нахождения транспорта, поддерживаемого клиентом, а не транспорта, поддерживаемого сетью.

Тот факт, что SockJS перебирает транспорты, пока не найдет успешное соединение, вводит в заблуждение относительно того, что он пытается сделать. Он не заботится о ситуациях, когда сети разрывают веб-сокеты так, как будто веб-сокет подключен, или любой другой транспорт, который кажется подключенным (путем чтения статуса соединения), но данные не проходят.

Вы несете ответственность за то, чтобы данные проходили через сеть, а также за то, чтобы вы оставались на связи, если это то, что вы намереваетесь. Эти вещи выходят за рамки веб-сокетов и, следовательно, за рамки SockJS.

person Matt Esch    schedule 05.02.2014
comment
Хорошо, однако в sockjs-client написано, что SockJS предназначен для работы для всех современных браузеров и в средах, которые не поддерживают протокол WebSocket, например, за ограничительными корпоративными прокси-серверами. Позже будет написано Опросные транспорты используются в качестве запасного варианта для старых браузеров и хостов за ограничительными прокси-серверами. . Возможно, способ тестирования сети ограничен, однако SockJS — это не только поддержка веб-сокетов клиентом. - person Vincent Hiribarren; 05.02.2014
comment
Эти вещи на самом деле верны. Они имеют в виду, что веб-сокеты не смогут установить успешное соединение. Я не защищаю дизайнерские решения SockJS, я думаю, что многие люди делают предположения, которые вы делаете об этом. Исходный код действительно лучший способ увидеть, что именно вы получаете. - person Matt Esch; 06.02.2014