WebSocket和long poll、ajax轮询的区别
WebSocket和long poll、ajax轮询的区别,ws协议测试
WebSocket是HTML5出的东西(协议),也就是说HTTP协议没有变化,或者说没关系,但HTTP是不支持持久连接的(长连接,循环连接的不算)首先HTTP有1.1和1.0之说,也就是所谓的keep-alive,把多个HTTP请求合并为一个,但是Websocket其实是一个新协议,跟HTTP协议基本没有关系,只是为了兼容现有浏览器的握手规范而已
典型的Websocket握手:
GET /chat HTTP/1.1
Host: server.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13
Origin: http://example.com
服务器会返回下列东西,表示已经接受到请求, 成功建立Websocket
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: HSmrc0sMlYUkAGmm5OPpG2HaGWk=
Sec-WebSocket-Protocol: chat
告诉客户端已成功切换协议
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Protocol 表示最终使用的协议。
至此HTTP协议已经完成,接下来就是完全按照Websocket协议进行了。
ajax轮询 的原理非常简单,让浏览器隔个几秒就发送一次请求,询问服务器是否有新信息。
long poll 其实原理跟 ajax轮询 差不多,都是采用轮询的方式,不过采取的是阻塞模型,客户端发起连接后,如果没消息,就一直不返回Response给客户端。
直到有消息才返回,返回完之后,客户端再次建立连接,不断循环。
从上面可以看出其实这两种方式,都是在不断地建立HTTP连接,然后等待服务端处理,可以体现HTTP协议的另外一个特点,被动性。
这两种都是非常消耗资源的。
ajax轮询 需要服务器有很快的处理速度和资源
long poll 需要有很高的并发
WebSocket当服务器完成协议升级后(HTTP->Websocket),服务端就可以主动推送信息给客户端,只需要经过一次HTTP请求,就可以做到源源不断的信息传送了。
Websocket可以直接跟nginx(等)建立持久连接,业务处理程序(Tomcat等)有信息的时候通知nginx,然后nginx在统一转发客户端
这样可以解决高并发和处理速度的问题
可以把 WebSocket 看成是 HTTP 协议为了支持长连接所打的一个大补丁,它和 HTTP 有一些共性,是为了解决 HTTP 本身无法解决的某些问题而做出的一个改良设计。
在以前 HTTP 协议中所谓的 keep-alive connection 是指在一次 TCP 连接中完成多个 HTTP 请求,但是对每个请求仍然要单独发 header;
所谓的 polling 是指从客户端(一般就是浏览器)不断主动的向服务器发 HTTP 请求查询是否有新数据。
这两种模式有一个共同的缺点,就是除了真正的数据部分外,服务器和客户端还要大量交换 HTTP header,信息交换效率很低。
它们建立的“长连接”都是伪.长连接,只不过好处是不需要对现有的 HTTP server 和浏览器架构做修改就能实现。
WebSocket 解决的第一个问题是,通过第一个 HTTP request 建立了 TCP 连接之后,之后的交换数据都不需要再发 HTTP request了,使得这个长连接变成了一个真.长连接。
但是不需要发送 HTTP header就能交换数据显然和原有的 HTTP 协议是有区别的,所以它需要对服务器和客户端都进行升级才能实现。
在此基础上 WebSocket 还是一个双通道的连接,在同一个 TCP 连接上既可以发也可以收信息。
此外还有 multiplexing 功能,几个不同的 URI 可以复用同一个 WebSocket 连接。
这些都是原来的 HTTP 不能做到的。
WebSocket 可能进入某种半死不活的状态。这实际上也是原有网络世界的一些缺陷性设计。
一个 HTTP/WebSocket 连接往往要经过无数的路由,防火墙。
中间节点可能会认为一份连接在一段时间内没有数据发送就等于失效,它们会自作主张的切断这些连接。
这种情况下,不论服务器还是客户端都不会收到任何提示。而计算机网络协议栈的实现中又会有一层套一层的缓存,除非填满这些缓存,你的程序根本不会发现任何错误。
这样WebSocket长连接就可能在毫不知情的情况下进入了半死不活状态。
解决方案就是让服务器和客户端能够发送 Ping/Pong Frame(RFC 6455 - The WebSocket Protocol)。
这种 Frame 是一种特殊的数据包,它只包含一些元数据而不需要真正的 Data Payload,可以在不影响 Application 的情况下维持住中间网络的连接状态。
WebSocket 跟其他 API 比较不一样的是,它不仅仅依赖于浏览器支持,同时要求服务器和代理支持。
WebSocket 本质上跟 HTTP 完全不一样,只不过为了兼容性,WebSocket 的握手是以 HTTP 的形式发起的,如果服务器或者代理不支持 WebSocket,会把这当做一个不认识的 HTTP 请求拒绝掉。