最近发现socket.io 的一个问题，做的应用不知道什么原因，有些人总是连接不上，后来找到了一些socket.io的文档，发现了问题的所在：大概的意思就是说因为socket.io 在现代浏览器上 会一直首选 websocket作为通信手段，而websocket有安全隐患,有些防火墙或者是杀毒软件可能会阻止websocket链接。所以socket.io应用连接不上。

于是，干脆去试着了解了一下socket.io出现前的web通信技术，虽然之前也听说过 长轮询啊 comet 等等技术，但都只是听说而已，所以这两天下了点功夫去了解了一下：

反向ajax技术 ：概念上说其实就是要实现由服务器想客户端发送数据，实现低延迟通信。但ajax请求无状态，只能客户端请求服务器，所以要通过技术模拟服务器端和客户端之间的响应式通信来绕过这一限制。

HTTP 轮询(polling) ：这个是最容易实现的而且对浏览器服务器没有特别要求，就是通过不断的向服务器发ajax请求。但这种方法会很浪费带宽和资源，所以不太可取。

JSONP轮询 ：跟http轮询类似，只不过是 JSONP是可跨域的。

捎带轮询 (piggyback polling)： 这个我看了很久，关于他的介绍不多，说是客户端需要的时候再向后台请求，服务端返回一个混合的响应，是网络开销最低的方式，但是总感觉这样跟普通的ajax请求有些相似呢。。。

Comet

Comet（长连接，服务器推）： Comet 是一个 Web 应用模型，就是客户端的请求被发送到服务器端后保持一个很长的存活期，直到超时或是有服务器端事件发生。这样服务器就可以在无需显式请求的情况下向客户端发送数据，但这种长时间保持请求打开的功能需要服务器的支持。实现Comet这种模式有2种方法：  流 (streaming) 和 长轮询(long polling).

流 (streaming)  ：流的实现也有两种方法：传说中的 Forever Iframes 和   多部分的 XMLHttpRequest

Forever Iframe ：这个之前就有听说，就是通过隐藏的iframe的src指向返回服务器端事件的 servlet 路径,每次在事件到达时，servlet 写入并刷新一个新的 script 标签，该标签内部带有 JavaScript 代码，iframe 的内容被附加上这一 script 标签，标签中的内容就会得到执行。 这种方式实现简单，支持iframe的浏览器都可以，但是连接和数据都是通过html标签，不能追踪连接状态以及可靠的错误处理。

多部分的 XMLHttpRequest ：是在  XHR  对象上使用某些浏览器（比如 Firefox）支持的 multi-part 标志，Ajax 请求被发送给服务器端并保持打开状态，每次有事件到来时，一个多部分的响应就会通过这同一连接来写入。并非所有浏览器支持。

长轮询(long polling) ： 应该是指服务器端的技术可以保持连接保持打开状态，有事件发生，则响应给客户端，关闭连接，然后再打开一个新的连接。也是有2种实现方式： script 标签 和  XMLHttpRequest 长轮询。

script 标签： 跟iframe类似，也是返回script脚本执行，可跨域，与iframe有同样的缺点，错误处理缺失，以及连接的不可知不可干涉。

XMLHttpRequest 长轮询： 我的理解就是发送普通的ajax请求，由服务器端挂起请求，直到某个事件返回响应客户端，客户端继续打开新的请求。这也算是实现Comet的最佳实现了，可以对超时等错误进行追踪，对浏览器几乎没有要求，只是服务器端需要挂起连接的功能。

FlashSockets: 利用嵌入网页的flash程序中的 socket 跟服务器通信，javascript 在通过flash提供的接口获取到XML。从而实现服务器推。但flashsockets需要安装flash插件，并需要843端口。

再写就是HTML5中的websocket协议了

 WebSocket： 是HTML5开始提供的一种浏览器与服务器间进行全双工通讯的网络技术。2011年被定为标准。双工通讯其实就是可以互相传输数据，全双工通讯就是指双方可以同时进行传输，与之相对的是半双工，不可同时传输。

了解了这么多，回头一看 发现 这些就是 socket.io 可降级实现的 所有东西：

这里