Perché il mio socket.io utilizza il polling lungo al posto del websocket?

Question

Così ho configurato socket.io con un server NodeJS + ExpressJS e tutto funziona correttamente. L'unico problema è che ho appena realizzato che le mie chiamate emit() utilizzano il metodo XHR fallback per inviare l'evento al mio server anziché la connessione websocket che ha aperto.

Quando visualizzo la connessione, tutto quello che vedo sono alcuni 2probe, 3probe, seguiti da un gruppo di 2 e 3 inviati attraverso la websocket. Questa connessione sembra essere aperta e funzionante, quindi perché sta ricadendo su un lungo polling con le richieste XHR?

Non sto fornendo alcun codice in questo momento perché non sono sicuro di quale parte sarebbe rilevante dal momento che l'aspetto funzionale del codice funziona bene, voglio solo utilizzare il websocket su XHR. Fatemi sapere se c'è qualche codice che volete vedere

UPDATE

Così stavo testando le prese un po 'di più e ho aggiunto un altro paio di emit() chiamate. Sembra che le prime 1 o 2 emittenti utilizzino il polling lungo e poi all'improvviso cambierà con l'uso della websocket. Solo curioso di sapere cosa sta succedendo qui.

Answer 1

Da Socket.IO 1.x, l'algoritmo di fallback è stato modificato da un approccio di downgrade a un approccio di upgrade.

Il polling lungo funziona praticamente dappertutto, quindi viene utilizzato inizialmente in modo da ottenere subito una "connessione". Quindi, in background, viene effettuato un tentativo di aggiornare la lunga connessione di polling a una connessione websocket. Se l'aggiornamento ha esito positivo, il polling lungo si arresta e la sessione passa alla connessione websocket. Se non ha esito positivo, la "connessione" polling lunga rimane aperta e continua a essere utilizzata.