Socket.io: Почему socket.io использует соединение через веб-сокет и параллельный опрос xhr?

• «Опрос XHR» не является соединением, он может использовать более одного соединения.
• Транспорты веб-сокета и опроса еще не инициализированы одновременно. Фактически, это то, что делает engine.io и что скоро будет делать socket.io, когда он его реализует. Прочтите здесь, и вы, возможно, пересмотрите ярлык «глупый».

Если вы столкнулись с ситуацией, когда socket.io 0.9 имеет два открытых транспорта одновременно, это будет ошибкой, и мы будем благодарны за дополнительную информацию о том, как ее воспроизвести.

«Опрос XHR» не является соединением, он может использовать более одного соединения.

Да, но поскольку опрос работает по одному и тому же URL-адресу, все запросы. Я предполагаю, что он должен подражать одному.

Если вы столкнулись с ситуацией, когда socket.io 0.9 имеет два открытых транспорта одновременно, это будет ошибкой, и мы будем благодарны за дополнительную информацию о том, как ее воспроизвести.

Я не уверен, имеем ли мы в виду то же самое, но: Chromium показывает мне открытое соединение с веб-сокетом и, кроме того, отправляет запросы на опрос в socket.io.
«Глупый» теперь означает, что я не могу воспользоваться преимуществами подключения и опроса пригодных для использования веб-сокетов.
Разве соединение через веб-сокет не должно быть самодостаточным, а опрос xhr использоваться только в качестве запасного варианта?

Поправьте меня, если я что-то пропустил

@bodokaiser действительно ли работает соединение с веб-сокетом или это откат к опросу?

Имейте в виду, что рукопожатие - это обычный HTTP

Chrome Показывает мне, что соединение с веб-сокетом ожидается. Сообщение об ошибке отсутствует. Предполагаю, что ws работает. Тем не менее, как я могу проверить, откатывается ли socket.io?

Ага, это определенно не рукопожатие. Я вижу в хроме и в консоли узла, как запросы на получение повторяются каждые 2000 мс.

Поможет ли вам ведение журнала node.js?

С Уважением

Осмотрите фреймы, которыми обменивались в ws-соединении (я думаю, это есть только в Chrome). Если вы не видите данных, значит, это не сработало.

Ага, похоже, отступает:

  debug - client authorized
   info  - handshake authorized yUEmr7drZfmWzWHdEZcp
GET /socket.io/1/?t=1344799805756 200 3ms
   debug - setting request GET /socket.io/1/xhr-polling/yUEmr7drZfmWzWHdEZcp?t=1344799815866
   debug - setting poll timeout
   debug - client authorized for 
   debug - clearing poll timeout
   debug - xhr-polling writing 1::
   debug - set close timeout for client yUEmr7drZfmWzWHdEZcp
GET /socket.io/1/xhr-polling/yUEmr7drZfmWzWHdEZcp?t=1344799815866 200 1ms
   debug - xhr-polling received data packet 5:::{"name":"hello","args":["world"]}
POST /socket.io/1/xhr-polling/yUEmr7drZfmWzWHdEZcp?t=1344799815871 200 1ms
   debug - setting request GET /socket.io/1/xhr-polling/yUEmr7drZfmWzWHdEZcp?t=1344799815872
   debug - setting poll timeout
   debug - discarding transport
   debug - cleared close timeout for client yUEmr7drZfmWzWHdEZcp
   debug - clearing poll timeout
   debug - xhr-polling writing 8::
   debug - set close timeout for client T9eCOR7gCe3pLNtiEZco
   debug - xhr-polling closed due to exceeded duration
GET /socket.io/1/xhr-polling/T9eCOR7gCe3pLNtiEZco?t=1344799800945 200 20002ms
   debug - clearing poll timeout
   debug - xhr-polling writing 8::
   debug - set close timeout for client yUEmr7drZfmWzWHdEZcp
   debug - xhr-polling closed due to exceeded duration

@guille, не могли бы вы сказать мне, почему это откат?

Какой браузер вы используете?

Chroms 21 для Mac OSX

Я также вижу ту же проблему в Chrome 21 / Windows 21.0.1180.79 m - есть соединение для опроса JSONP (которое кажется успешным) с одновременным подключением WebSocket, которое никогда не подключается - оно всегда находится в состоянии «Ожидание». Та же версия Chrome на Mac кажется прекрасной.

Это не похоже на брандмауэр или антивирус, все тесты проходят на websocketstest.org и websocket.org/echo.html.

Я использую socket.io 0.9, но, похоже, он также присутствует в последней версии.

@guille Эту проблему тоже довольно легко воспроизвести. Я только что посетил сайт, который использует транспорт WebSocket socket.io:

http://beta.blaggart.com

Обратите внимание, что, по крайней мере, в Chrome 21 для Windows статус WS-соединения всегда «Ожидает».

Попробовать с мастером socket.io?

Просто попробовал мастер, и у меня такая же проблема. Думаю, этот выпуск тоже может быть ошибкой # 998.

Кроме того, как бы то ни было, обходной путь, описанный в # 998, действительно помог мне установить соединение - отключение веб-сокетов и использование только опроса xhr и jsonp.

это на самом деле ошибка хрома?

при выполнении теста на сайте www.websocket.org/echo.html

Забавно то, что когда я использую «безопасный WebSocket (TLS)» на том же веб-сайте, тогда веб-сокет работает.

точно такое же поведение для Chrome и Firefox .. очень странно ..

Сервер:

socket.on('loginout',function(){
    socket.emit('loginout',{uname:socket.name});
});

socket.on ('логин', функция (данные) {
socket.emit ('l_msg', {uname: data.uname, score: data.score, type: true});
});

Распечатать:
информация: рукопожатие разрешено 11012331592122282453
отладка: установка запроса GET /socket.io/1/xhr-polling/11012331592122282453?t=1353485202761
отладка: установка тайм-аута опроса
отладка: клиент авторизован для
отладка: очистка тайм-аута опроса
отладка: запись xhr-опроса 1 ::
отладка: установить таймаут закрытия для клиента 11012331592122282453
debug: xhr-polling получил пакет данных 20 5 ::: {"name": "count"} 22 5 ::: {"name": "history"} 23 5 ::: {"name ":" userList "}
отладка: установка запроса GET /socket.io/1/xhr-polling/11012331592122282453?t=1353485202792
отладка: установка тайм-аута опроса
отладка: отбрасывание транспорта
отладка: очищен тайм-аут закрытия для клиента 11012331592122282453
отладка: очистка тайм-аута опроса
отладка: запись xhr-опроса 8 ::
отладка: установить таймаут закрытия для клиента 1896586469607627233
debug: xhr-polling закрыт из-за превышения продолжительности
debug: xhr-polling получил пакет данных 5 ::: {"name": "login", "args": [{"uname": "gjjn", "pwd": "3f01728152a0225ff9806c401ffdbe77"}]}
отладка: очистка тайм-аута опроса
debug: xhr-polling writing 5 ::: {"name": "l_msg", "args": [{"uname": "gjjn", "type": true, "head": " http: //42.121. 14.234 / undefined "}]}
отладка: установить таймаут закрытия для клиента 11012331592122282453
debug: xhr-polling получил пакет данных 5 ::: {"name": "loginout"}
отладка: запись в веб-сокете 5 ::: {"name": "l_msg", "args": [{"uname": "gregergre", "type": true, "head": " http://42.121.14.234/ undefined "}]}
отладка: выдача пульса для клиента 5207531891749391108
отладка: запись в веб-сокете 2 ::
отладка: установить тайм-аут пульса для клиента 5207531891749391108
отладка: есть контрольный пакет
отладка: очищен тайм-аут пульса для клиента 5207531891749391108
отладка: установить интервал пульса для клиента 5207531891749391108
отладка: запись в веб-сокете 5 ::: {"name": "loginout", "args": [{}]}

Xhr-polling получил пакет данных 5 ::: {"name": "loginout"}.
Но не Результат.

Тут то же самое. Я использовал тот же код, но он работает в Chrome MacOS, но не в Chrome Windows

как воспроизвести - https://gist.github.com/jonnsl/5021596

+1, исправьте эту проблему .. @LearnBoost

Даже если я это вижу, со своей стороны я вижу соединение с Websocket и повторяющийся запрос XHR, отправленный на сервер SOCKET.io

Кажется, что соединение с веб-сокетом привело к успеху, но я вижу запрос XHR

Request URL:ws://localhost:5000/socket.io/?EIO=2&transport=websocket&sid=XcMblHoZ0x97QRn_AAAE
Request Method:GET
Status Code:101 Switching Protocols
Request Headers CAUTION: Provisional headers are shown.
Cache-Control:no-cache
Connection:Upgrade
Cookie:io=XcMblHoZ0x97QRn_AAAE
Host:localhost:5000
Origin:http://localhost:3000
Pragma:no-cache
Sec-WebSocket-Extensions:permessage-deflate; client_max_window_bits, x-webkit-deflate-frame
Sec-WebSocket-Key:EZixwYoUHpFFpgrEOqiS+w==
Sec-WebSocket-Version:13
Upgrade:websocket
User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.153 Safari/537.36
Query String Parametersview sourceview URL encoded
EIO:2
transport:websocket
sid:XcMblHoZ0x97QRn_AAAE
Response Headers
Connection:Upgrade
Sec-WebSocket-Accept:WHsiBZoW9stmULt+YX8wmNK1wx8=
Upgrade:websocket

Вот как выглядят рамки веб-сокетов
https://www.dropbox.com/s/v6szg9hka53erbc/Screenshot%202014-07-09%2011.12.33.png

И длинный запрос на опрос

https://www.dropbox.com/s/pf7d56tp85864bg/Screenshot%202014-07-09%2011.15.47.png

Я использую Google Chrome 35.0.1916.153

а версия проблемы с сокетом - [email protected]

У меня такая же проблема. Любые обновления? Использование SocketIO 1.0.6

Первым запросом всегда является XHR, затем мы _обновляем_ до WebSocket (если сможем). Последующий опрос прерывается (в некоторых случаях может быть дополнительный цикл опроса, но не более 1)

@guille, что касается того, что я проверил, я вижу повторный опрос XHR, даже если соединение с Websocket было установлено успешно

Привет,

Как решить эту проблему?

@rohittailor : Я тестирую это на клиенте:

    <script src="/socket.io/socket.io.js"></script>
    <script>
        var socket = io.connect({transports: ['websocket']});
    </script>

и пока все хорошо. Это полностью исключает подключение XHR.

Это тоже решило мою проблему, websocket работал нормально, НО также был грязный опрос XHR. Спасибо @gonzalodiaz

Мне бы очень хотелось увидеть сценарий, при котором он успешно обновляется до WS, но циклы опроса XHR продолжаются бесконечно в Web Inspector!

(демо, видео, анимированный гиф, все работает)

Я могу предоставить вам демонстрационный доступ к моему веб-сайту, размещенному в облаке MS Azure, завтра. Можете ли вы предоставить нам свой тестовый URL-адрес и более подробную информацию о том, как размещается socket.io?

@guille Как насчет этого

Вот как выглядят рамки веб-сокетов
https://www.dropbox.com/s/v6szg9hka53erbc/Screenshot%202014-07-09%2011.12.33.png

И длинный запрос на опрос

https://www.dropbox.com/s/pf7d56tp85864bg/Screenshot%202014-07-09%2011.15.47.png

Они продолжаются бесконечно? Есть ли дублирующиеся кадры в
ответы? Не могли бы вы опубликовать соответствующий журнал сервера с DEBUG = * и
журнал браузера с localStorage.debug='*' когда возникает такая ситуация?

-
Гильермо Раух - @rauchg https://twitter.com/rauchg

14 октября 2014 г., 22:59, Вирен Неги [email protected]
написал:

@guille https://github.com/guille Как насчет этого

Вот как выглядят рамки веб-сокетов

https://www.dropbox.com/s/v6szg9hka53erbc/Screenshot%202014-07-09%2011.12.33.png

И длинный запрос на опрос

https://www.dropbox.com/s/pf7d56tp85864bg/Screenshot%202014-07-09%2011.15.47.png

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/Automattic/socket.io/issues/991#issuecomment -59161273
.

@guille Я действительно вижу, что ответ xhr повторяется бесконечно, не уверен в дублировании кадра, позвольте мне посмотреть, смогу ли я предоставить все, что вам нужно

Не уверен, насколько я могу быть полезным, но замечаю, что могу подключиться к веб-сокету, только если он безопасен. Были ли некоторые недавние изменения безопасности, требующие заголовка (например, CORS), чтобы разрешить незащищенные соединения WebSocket?

WebSockets у меня работал месяц назад, теперь работает только для wss: // соединений.
Chrome 38.0.2125.104 - Windows 8.1.1

Изменить: эти результаты могут быть проблемой с http://www.websocket.org/echo.html
Мне не удалось протестировать где-либо еще

Успех соединения WS действительно зависит от возможностей сети / сервера. SSL гарантирует, что ничто не может его сломать до того, как данные будут расшифрованы (хотя последующие прокси / балансировщики нагрузки все еще могут сломать его).

Я заметил, что на самом деле это была ошибка в коде, он даже не опрашивал соединение WS, я внес изменения, и тогда это сработало. Если я вспомню, сегодня вечером посмотрю модифицированный исходник.

Но если он работает для всех остальных, то может быть что-то еще не так с моей настройкой, но он не пытался подключиться, потому что думал, что WS недоступен без попытки, изменив && на || починил это.

Я бы хотел услышать больше!

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

{transports: ['websocket']}

Чтобы он заработал, но клиент должен попробовать все транспорты, чтобы найти подходящий, не так ли?

Эта проблема была причиной, по которой я еще в 2012/13 году начал работать над собственным "чистым" пакетом веб-сокетов.

Эта проблема решена? Я вижу нечто подобное, но прежде чем я начну копать, я хотел бы быстро поискать ... комментарии?

Код немного изменился с тех пор, как я последний раз комментировал эту проблему. Вряд ли это та же ошибка. Кажется, я не могу найти строку, которая, как я подозревал, вызвала проблему в прошлый раз. Нельзя сказать, что это исправлено.

Мой код socket.io в настоящее время заблокирован ошибкой engine.io-client, поэтому я не использовал s.io в течение нескольких месяцев, поэтому не могу точно сказать, все еще проблема.

@ Nevercast ваш комментарий о работе wss, но ws не был полностью правильным в моем случае. Спасибо, что указали на это. Я искал эту проблему больше недели. Обнаружено, что каким-то образом любое соединение ws в моей сети блокируется, но wss работает нормально.

Этот веб-сайт великолепен: http://websocketstest.com/ он сообщает вам, какие порты могут запускать веб-сокеты в любой данной сети. Рекомендуем проверить это, прежде чем слишком увлекаться отладкой веб-сокетов.

У меня проблема с socket io, но я не уверен, где ошибаюсь.

на изображении выше показано, что он отлично работает в локальном режиме, но изображение ниже снято при попытке в среде AWS.

У меня проблема с socket io, но я не уверен, где ошибаюсь.

на изображении выше показано, что он отлично работает в локальном режиме, но изображение ниже снято при попытке в среде AWS.

столкнулся с той же проблемой