这是因为WebSocket升级可能会失败，所以使用轮询作为后退机制是很有用的。

它并没有真正使用轮询。最初的HTTP url看起来像是用于轮询的设置，但只有当服务器不同意将连接升级到webSocket协议时，这才会起作用。

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

如果客户机/服务器组合不支持webSocket，那么并且只有在那个时候Socket.io才会求助于使用长轮询。

这种特殊的设计允许webSocket和HTTP共享相同的端口，如果双方在webSocket升级上意见不一致，Socket.io设计允许很好地回退到长轮询。

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

从降级而不是升级的旧行为改变的原因是，WebSockets在某些情况下可能很难正常运行（例如，负载平衡器，代理等的问题），而且即使它们确实连接了，也可能会涉及到一些额外的延迟。另外，对WebSockets使用flash回退将需要一些时间来连接，因为它涉及额外的往返和一些额外的延迟。