Socket.io-client: O padrão de transporte é polling em vez de websocket?

Criado em 11 set. 2015 · 9Comentários · Fonte: socketio/socket.io-client

A linha 1613 de socket.io.js diz:
this.transports = opts.transports || ['polling', 'websocket'];

Por que o pedido não é ['websocket', 'polling']?

Do lado do cliente, estou fazendo:
var socket = io.connect (url);

Então, no lado do servidor, eu fiz:
io.on ('conexão', função (soquete) {
console.log (soquete);
});

A parte do aperto de mão se parece com:

handshake: 
   { headers: 
      { 'user-agent': 'node-XMLHttpRequest',
        accept: '*/*',
        host: 'localhost:8081',
        connection: 'close' },
     time: 'Fri Sep 11 2015 16:04:39 GMT-0400 (EDT)',
     address: '::ffff:127.0.0.1',
     xdomain: false,
     secure: false,
     issued: 1442001879771,
     url: '/socket.io/?EIO=3&transport=polling&t=1442001879749-0&b64=1',
     query: { EIO: '3', transport: 'polling', t: '1442001879749-0', b64: '1' } }

Isso significa que ele está usando polling em vez de websocket?

Tentei definir o transporte para 'websocket' explicitamente e a parte do handshake mudou para o seguinte, o que parece correto:
var socket = io.connect (url, {transports: ['websocket']});

handshake: 
   { headers: 
      { connection: 'Upgrade',
        upgrade: 'websocket',
        host: 'localhost:8081',
        origin: 'localhost:8081',
        'sec-websocket-version': '13',
        'sec-websocket-key': 'MTMtMTQ0MjAwMTUxNDcyNA==' },
     time: 'Fri Sep 11 2015 15:58:34 GMT-0400 (EDT)',
     address: '::ffff:127.0.0.1',
     xdomain: true,
     secure: false,
     issued: 1442001514739,
     url: '/socket.io/?EIO=3&transport=websocket',
     query: { EIO: '3', transport: 'websocket' } }

Fonte

napalm272

👍4

Comentários muito úteis

+1
Eu prefiro a ideia de "downgrade" em vez de "upgrade". Atualmente, a maioria dos navegadores oferece suporte a websocket bem. Conectar-se inicialmente a websocket melhorará o desempenho e economizará recursos.

stackOverMind em 20 out. 2015

👍14

Todos 9 comentários

stackOverMind em 20 out. 2015

👍14

O motivo de upgrade é o seguinte.

O Socket.IO nunca presume que o WebSocket simplesmente funcionará, porque, na prática, há uma boa chance de que não funcione. Em vez disso, ele estabelece uma conexão com XHR ou JSONP imediatamente e, em seguida, tenta atualizar a conexão para WebSocket. Em comparação com o método de fallback que depende de tempos limite, isso significa que nenhum de seus usuários terá uma experiência degradada.

http://socket.io/blog/introducing-socket-io-1-0/

nkzawa em 27 nov. 2015

👍5

@nkzawa
Eu entendo por que a abordagem de atualização é preferida, e é um recurso muito bom.
Mas nem sempre é necessário: em ambientes corporativos controlados, a abordagem de downgrade faz mais sentido, e eu diria que forçar o web socket como o único transporte permitido é a melhor maneira de otimizar o desempenho.

Tentei forçar o transporte para o soquete da web no cliente e no servidor passando esta opção:
{ transports: ["websocket"] }

Isso parece funcionar e eu só tenho uma conexão de soquete da web com o servidor, mas notei que uma votação também está sendo feita e obviamente falha em todas as tentativas:
Request URL:http://localhost:4000/socket.io/?EIO=3&transport=polling&t=L8RaD0p
{ code: 0, message: "Transport unknown" }

Existe alguma solução viável no momento para mudar essa abordagem de upgrade para downgrade?

sirudog em 7 jan. 2016

Não importa, foi meu código que fez aquela pesquisa extra de uma classe diferente onde eu também usei socket.io. Então, usar opts que restringe os transportes para websocket quando me conecto faz o que eu queria.

sirudog em 7 jan. 2016

@sirudog
Você pode tentar isto: {transports: ['websocket', 'polling']}

poppowerlb2 em 11 jan. 2016

👍5

Obrigado @ poppowerlb2 (sem mais tráfego como ele na minha guia de rede). Mesmo que meu navegador esteja atualizado, vejo que o socket-io-client prefere polling.

jy95 em 25 abr. 2017

Esta abordagem de atualização não exclui alguns servidores? Estou tentando usar o socket.io com um servidor node-red e ainda não consigo estabelecer uma conexão. Claro, ele funciona bem com websockets simples.

rm-rf-etc em 8 ago. 2017

Eu também acho que é preferível que o socket.io tente websockets mesmo se o polling não funcionar.

yoch em 18 fev. 2018

+1
Eu prefiro a ideia de "downgrade" em vez de "upgrade". Atualmente, a maioria dos navegadores oferece suporte a websocket bem. Conectar-se inicialmente a websocket melhorará o desempenho e economizará recursos.

`
const client = io ('https://io.yourhost.com', {// AVISO: nesse caso, não há fallback para transportes de pesquisa longa: ['websocket'] // ou ['websocket', ' polling '], que é a mesma coisa})

https://socket.io/docs/using-multiple-nodes/
`