为什么引擎io首先使用轮询建立连接然后使用websocket

Question

当我读取引擎io协议时，我发现它使用轮询来建立连接，然后将传输升级到websocket，我不知道为什么？你能给我一些想法吗？

Answer 1

这是因为WebSocket升级可能会失败，因此将轮询作为回退机制非常有用。

Answer 2

它并不真正使用轮询。初始HTTP URL可能看起来像是轮询设置，但只有在服务器不同意升级到webSocket协议的连接时才会发挥作用。

socket.io连接以单个TCP连接开始，该连接是设置了某些webSocket标头的HTTP请求，然后当服务器响应支持webSocket协议时，连接从HTTP“升级”到webSocket并且双方将正在使用的协议从HTTP切换到webSocket。这就是指定webSocket协议的方式。

如果客户端/服务器组合不支持webSocket，那么只有socket.io才能使用长轮询。

这个特殊的设计允许webSocket和HTTP共享相同的端口，如果双方都不同意webSocket升级，socket.io设计允许长时间轮询的优雅回退。

Answer 3

engine.io / socket.io 1.x +首先轮询 ，因为它几乎总是适用于所有类型的客户端，允许它们非常快速地连接。然后在后台尝试升级连接（到WebSockets或其他任何东西）。这样，如果连接升级失败，则不会丢失任何内容，因为轮询仍然像以前一样工作，因此没有停机时间。

从降级而不是升级的旧行为改变的原因是WebSockets在某些情况下（例如负载均衡器，代理等问题）可能很麻烦，即使它们确实在那里连接可能会涉及一些额外的延误。另外，使用WebSockets的闪回后备还需要一些时间来连接，因为它涉及额外的往返和一些额外的延迟。