联系和区别：http和websocket

 场景

Web应用的通信过程通常是客户端通过浏览器发出一个请求，服务器端接收请求后进行处理并返回结果给客户端，客户端浏览器将信息呈现。
这种机制对于信息变化不是特别频繁的应用可以良好支撑，但对于实时要求高、海量并发的应用来说显得捉襟见肘。
尤其在当前业界移动互联网蓬勃发展的趋势下，高并发与用户实时响应是Web应用经常面临的问题，
比如金融证券的实时信息（股票交易盘口推送）、Web导航应用中的地理位置获取（地图）、社交网络的实时消息推送（微信qq）等。

传统的Web请求-响应模式

通常采用实时通讯方案。
比如常见的ajax轮询方案，客户端以一定的时间间隔频繁请求的方式向服务器发送请求，来保持客户端和服务器端的数据同步。
其问题也很明显：当客户端以固定频率向服务器端发送请求时，服务器端的数据可能并没有更新，带来很多无谓请求，浪费带宽，效率低下。

技术过程

基于HTML5规范的、有WebTCP之称的WebSocket应运而生。
早期HTML5并没有形成业界统一的规范，各个浏览器和应用服务器厂商有着各异的类似实现，如IBM的MQTT、Comet开源框架等。
直到2014年，HTML5终于尘埃落地，正式落实为实际标准规范，各个应用服务器及浏览器厂商逐步开始统一，在 JavaEE7中也实现了WebSocket协议。
至此无论是客户端还是服务端的WebSocket都已完备。

WebSocket WebSocket是HTML5下一种新的协议。
它实现了浏览器与服务器全双工通信，能更好的节省服务器资源和带宽并达到实时通讯的目的。

它与HTTP一样通过已建立的TCP连接来传输数据，但是它和HTTP最大不同是：WebSocket是一种双向通信协议，也就是全双工。
在建立连接后，WebSocket服务器端和客户端都能主动向对方发送或接收数据，就像Socket一样；
WebSocket需要像TCP一样，先建立连接，连接成功后才能相互通信。

HTTP的缺点和WebSocket的优点

你可以把 WebSocket 看成是 HTTP 协议为了支持长连接所打的一个大补丁，它和 HTTP 有一些共性，是为了解决 HTTP 本身无法解决的某些问题而做出的一个改良设计。

HTTP 1.0 每次只能完成一个请求
HTTP 1.1 默认开启Connection： keep-alive，一定程度上弥补了HTTP1.0每次请求都要创建连接的缺点。

Connection：keep-alive是指在一次 TCP 连接中完成多个 HTTP 请求，但是对每个请求仍然要单独发 header；
所谓的 polling 是指从客户端（一般就是浏览器）不断主动的向服务器发 HTTP 请求查询是否有新数据。

这两种模式有一个共同的缺点，就是除了真正的数据部分外，服务器和客户端还要大量交换 HTTP header，信息交换效率很低。
它们建立的“长连接”都是伪长连接，只不过好处是不需要对现有的 HTTP server 和浏览器架构做修改就能实现。

websocket的特点:
WebSocket 通过第一个 HTTP request建立了TCP连接之后，之后的交换数据都不需要再发 HTTP request了，使得这个长连接变成了一个真长连接。（服务器和客户端都进行升级）
WebSocket 还是一个双通道的连接，在同一个 TCP 连接上既可以发也可以收信息。
WebSocket 具有multiplexing（多路复用的） 功能，几个不同的 URI 可以复用同一个 WebSocket 连接。

相比HTTP长连接，WebSocket有以下优点：
1. 真正的全双工方式。建立连接后客户端与服务器端是完全平等的，可以互相主动请求。
2. 效率更高。而HTTP长连接基于HTTP，是传统的客户端对服务器发起请求的模式。HTTP长连接中，每次数据交换除了真正的数据部分外，服务器和客户端还要大量交换HTTP header，信息交换效率很低。Websocket协议通过第一个request建立了TCP连接之后，之后交换的数据都不需要发送 HTTP header就能交换数据，这显然和原有的HTTP协议有区别所以它需要对服务器和客户端都进行升级才能实现（主流浏览器都已支持HTML5）。此外还有 multiplexing、不同的URL可以复用同一个WebSocket连接等功能。这些都是HTTP长连接不能做到的。

WebSocket为什么可能进入某种半死不活的状态？

解决方案：让服务器和客户端能够发送 Ping/Pong Frame。

这实际上也是原有网络世界的一些缺陷性设计。
上面所说的 WebSocket 真长连接虽然解决了服务器和客户端两边的问题，但坑爹的是网络应用除了服务器和客户端之外，另一个巨大的存在是中间的网络链路。
一个HTTP/WebSocket连接往往要经过无数的路由，防火墙。
你以为你的数据是在一个“连接”中发送的，实际上它要跨越千山万水，经过无数次转发，过滤，才能最终抵达终点。
在这过程中，中间节点的处理方法很可能会让你意想不到。
比如说，这些坑爹的中间节点可能会认为一份连接在一段时间内没有数据发送就等于失效，它们会自作主张的切断这些连接。
在这种情况下，不论服务器还是客户端都不会收到任何提示，它们只会一厢情愿的以为彼此间的红线还在，徒劳地一边又一边地发送抵达不了彼岸的信息。
而计算机网络协议栈的实现中又会有一层套一层的缓存，除非填满这些缓存，你的程序根本不会发现任何错误。
这样，本来一个美好的 WebSocket 长连接，就可能在毫不知情的情况下进入了半死不活状态。
而解决方案，WebSocket 的设计者们也早已想过。
就是让服务器和客户端能够发送 Ping/Pong Frame（RFC 6455 - The WebSocket Protocol）。
这种 Frame 是一种特殊的数据包，它只包含一些元数据而不需要真正的 Data Payload，可以在不影响 Application 的情况下维持住中间网络的连接状态。