问题
I came accross a problem while using SockJS on a specific access network. It think it is related to the way SockJS chooses the best transport protocol (websocket, long polling, ...) according to the state of the network.
Using a web browser, my SockJS client is connected with the websocket transport protocol to my node SockJS server. I even see the "on connection" event on node. However, when I send data, nothing passes through it. To be exhaustive, it works perfectly well from some other access networks.
According to the results of the website http://websocketstest.com/ the state of this access network is a bit special: for WebSockets (Port 80), it is stucked to:
Connected Yes✔
Data Receive Yes✔
To be sure websocket works well, it should also have a "Server time" line updated every seconds by the test server. Since it is not the case, I am pretty sure I have a transparent HTTP proxy which breaks the websocket connection.
However, SockJS does not discover that, and it does not switch to a fallback protocol. I thought it was designed to do so.
Am I mistaken about the transport negotiation capabilities of SockJS?
Is Socket.IO more robust in this kind of scenario or for this kind of access networks with transparent HTTP proxies?
I know I could use SockJS with SSL, but I think it is rather a fallback, not really a solution.
回答1:
I think you are mistaken about the transport negotiation capabilities of SockJS. SockJS is a websocket emulation. SockJS behaves like websockets. Indeed, if websockets are supported by the client they will be use. But of course, some browsers don't support websockets, which is what SockJS takes care of. The fallback mechanism is used to find a transport that is supported by the client, not a transport which is supported by the network.
The fact that SockJS iterates through transports until it finds a successful connection is sort of misleading about what it is trying to do. It doesn't take care of situations where networks break websockets in a way that appears as if the websocket is connected, or any other transport that appears connected (by reading the connection status) but data doesn't make it through.
You are responsible for ensuring that data makes it through the network and that you also remain connected if this is what you intend. These things are outside the scope of websockets, and therefore the scope of SockJS.
来源：https://stackoverflow.com/questions/21582787/sockjs-connected-as-websocket-but-nothing-going-through