【请采纳点赞】
你可以把WebSocket看成是HTTP协议为了支持长连接所打的一个大补丁，它和HTTP有一些共性，是为了解决HTTP本身无法解决的某些问题而做出的一个改良设计。在以前HTTP协议中所谓的keep-aliveconnection是指在一次TCP连接中完成多个HTTP请求，但是对每个请求仍然要单独发header；所谓的polling是指从客户端(一般就是浏览器)不断主动的向服务器发HTTP请求查询是否有新数据。
这两种模式有一个共同的缺点，就是除了真正的数据部分外，服务器和客户端还要大量交换HTTPheader，信息交换效率很低。它们建立的“长连接”都是伪。长连接，只不过好处是不需要对现有的HTTPserver和浏览器架构做修改就能实现。WebSocket解决的第一个问题是，通过第一个HTTPrequest建立了TCP连接之后，之后的交换数据都不需要再发HTTPrequest了，使得这个长连接变成了一个真。
长连接。但是不需要发送HTTPheader就能交换数据显然和原有的HTTP协议是有区别的，所以它需要对服务器和客户端都进行升级才能实现。在此基础上WebSocket还是一个双通道的连接，在同一个TCP连接上既可以发也可以收信息。此外还有multiplexing功能，几个不同的URI可以复用同一个WebSocket连接。
这些都是原来的HTTP不能做到的。另外说一点技术细节，因为看到有人提问WebSocket可能进入某种半死不活的状态。这实际上也是原有网络世界的一些缺陷性设计。上面所说的WebSocket真。长连接虽然解决了服务器和客户端两边的问题，但坑爹的是网络应用除了服务器和客户端之外，另一个巨大的存在是中间的网络链路。
一个HTTP/WebSocket连接往往要经过无数的路由，防火墙。你以为你的数据是在一个“连接”中发送的，实际上它要跨越千山万水，经过无数次转发，过滤，才能最终抵达终点。在这过程中，中间节点的处理方法很可能会让你意想不到。比如说，这些坑爹的中间节点可能会认为一份连接在一段时间内没有数据发送就等于失效，它们会自作主张的切断这些连接。
在这种情况下，不论服务器还是客户端都不会收到任何提示，它们只会一厢情愿的以为彼此间的红线还在，徒劳地一边又一边地发送抵达不了彼岸的信息。而计算机网络协议栈的实现中又会有一层套一层的缓存，除非填满这些缓存，你的程序根本不会发现任何错误。这样，本来一个美好的WebSocket长连接，就可能在毫不知情的情况下进入了半死不活状态。
而解决方案，WebSocket的设计者们也早已想过。就是让服务器和客户端能够发送Ping/PongFrame(RFC6455-TheWebSocketProtocol)。这种Frame是一种特殊的数据包，它只包含一些元数据而不需要真正的DataPayload，可以在不影响Application的情况下维持住中间网络的连接状态。
全部
