广通软件N次元前端工程师趣谈webSocket

　　广通软件十多年来耕耘于运维管理软件研发和服务咨询，面向数据中心、互联网、物联网三个领域提供整合化的运维工具和服务。本文作者祝恩良，N次元生物，现任广通软件高级前端开发工程师。今天将以实战角度谈一谈WebSocket的特点与应用。

　　WebSocket是一个独立的基于TCP的协议，是HTML5新出的一个协议，跟我们认识的HTTP协议两者之间具有一定的交集，webSocket其实是借助了HTTP这个跳板，档次也杠杠的，能进行全双工通讯(全双工：允许两台设备同时进行双向资料传输)。它和HTTP唯一的关系就是它的握手请求作为一个升级请求(Upgrade request)，经由HTTP服务器解析。

　　在我们熟知的Http version 1.0 和 version 1.1，升级版本中包含了keep-alive(Keep-Alive功能使客户端到服务器端的连接持续有效，当出现对服务器的后继请求时，Keep-Alive功能避免了建立或者重新建立连接。但是保持链接中，暂停通讯期间不会释放资源，比较浪费服务器资源。)。webSocket其实也囊括了这个概念，虽然实现并不是如此，简单的来说就HTTP协议上的一种补充。

　　协议

　　在此我们要来讲一个早就存在的概念，持久化的协议，也是webSocket的一个特征，当然这个也是相对于我们的HTTP协议来说的。

　　HTTP协议请求：

　　HTTP 1.0: 一个request 一个response 一次HTTP链接这样就算是结束了。

　　HTTP 1.1:在1.0版本有了改进，加入了一个Keep-Alive，在一次HTTP链接中，我可以发送多个request，接收多个response，但是一个request 只能对应一个response。而且这个response，是被动发起的。

　　webSocket是基于HTTP协议，

　　小明：报告老师，你明明说是基于TCP协议的来着，真善变。

　　老师：别说话，HTTP协议也是基于TCP协议的好不，我这里主要是想表达，webSocket借用了HTTP协议来完成一次握手升级请求，understand?

　　GET /chat HTTP/1.1

　　Host: xxxx.com

　　Upgrade: websocket

　　Connection: Upgrade

　　Sec-WebSocket-Key: XXXXXX

　　Sec-WebSocket-Protocol: XXXX

　　Sec-WebSocket-Version: X

　　Origin:http://xxxx.com

　　以上内容就是一次webSocket的握手升级协议请求。

　　有两个参数：

　　Upgrade：webSocket

　　Connection：Upgrade

　　告诉服务器(Ngnix)接线员:attention please!爷发起的是webSocket协议，快帮我找一个对应的客服，不是那个蹩脚的HTTP客服。

　　Sec-WebSocket-Key: XXXXX

　　Sec-WebSocket-Protocol: A, B

　　Sec-WebSocket-Version: X

　　首先，Sec-WebSocket-Key 是一个Base64 encode的值，这个是浏览器随机生成的，旨在验证服务器给出的服务是否合格。简单的理解：别忽悠我，我要验证你是不是webSocket客服。

　　然后，Sec_WebSocket-Protocol 是一个用户定义的字符串，用来区分同URL下，不同的服务所需要的子协议(客户端支持的子协议列表)。简单理解：我点的服务是这个，别搞错了。

　　最后，Sec-WebSocket-Version 是告诉服务器所使用的Websocket版本：服务员，我要的是小学生，不是大学生噢→_→

　　服务员：客官，你的要求，我们都能满足你哟，(^_^)。

　　然后服务器会返回下列东西，表示已经接受到请求，成功建立Websocket啦!

　　HTTP/1.1101Switching Protocols

　　Upgrade: websocket

　　Connection: Upgrade

　　Sec-WebSocket-Accept: XXXX

　　Sec-WebSocket-Protocol: B

　　返回的这些内容，就表示服务端升级

　　这部分就是HTTP最后负责的内容了，此后跟HTTP毫无关系。上述内容中：

　　Upgrade：webSocket

　　Connection：Upgrade

　　告诉客户端，服务端已经成功升级成webSocket协议了。

　　Sec-WebSocket-Accept: XXXX

　　这段内容是经过服务确认之后，根据客户端生成Sec-WebSocket-Key生成的值;简单理解，服务端：来，你个死傲娇，给你看我的ID info。

　　Sec-WebSocket-Protocol表示服务端从客户端提供的协议列表中，提供自身支持哪个(B)。

　　接下去的事，表示跟那个蹩脚的HTTP木有，完全木有，真的木有再有关系了，webSocket客服完全承包后续服务内容。

　　WebSocket的作用

　　在讲webSocket之前，请允许老夫再BB一会。让我们来脑补一会 long pull 和 ajax轮询吧

　　ajax轮询

　　ajax的原理非常简单，就是定时器，每隔一会发起一个请求，轮询服务端是否有新的信息。

　　场景大致是这样的：

　　客户：我的快递到了没呀?(request)

　　客服：你好，你是?没有(response)

　　客户：我的快递到了没呀?

　　客服：你好，你是?没有..

　　客户：我的快递到了没呀?

　　客服：你好，你是?没有，真没有

　　客户：我的快递到了没呀?

　　客服：你好，你是?!@#$%&*,可能还再路上

　　客户：我的快递到了没呀?

　　客服：你好，你是?有了会给你送来的

　　客户：我的快递到了没呀?

　　客服：你好，你是?没.....没.....没有啊....啊啊啊啊

　　long pull

　　原理其实跟ajax差不多，但是采用的是阻塞的方式(电话接通不挂，直到我满意为止才挂电话)。

　　客户端发起请求之后，服务端没有消息就一直不返回response。直到有消息，服务端返回response，客户端再次建立链接，周而复始。

　　简单理解大致是这样的：

　　客户：有木有新消息呀?有了再回答我(request)

　　客服：你好，你是?(客户BB一串)，稍等!有消息了，BBBBBB(response)

　　客户：有木有新消息呀?有了再回答我(request)

　　again and again

　　从上面可以看出其实这两种方式，都是在不断地建立HTTP连接，然后等待服务端处理，服务端不会主动去联系客户端，只能由客户端主动访问，而且每次都必须要进行一次重复的询问验证身份的工作，这两种方式其实都非常耗资源，都需要靠服务端的性能来维持整个链接的畅通性。如果服务端的性能不好，那就会出现以下情况：

　　客户：今晚我需要大保健服务(request)

　　客服：对不起，当前座席正忙(HTTP CODE:503)

　　webSocket

　　为了解决上诉的问题，我们的hero出现了

　　主动询问(一次消费，终身受用)

　　客户端HTTP协议升级成webSocket协议，服务端就可以主动推送信息给客户端，而不是每次都由客户端傻乎乎的来询问。

　　客户：请把我的青铜铠甲升级成websocket

　　客服：装甲已升级(黄金圣斗士)，战斗力+1000

　　客户：给我实时汇报装甲的耐久度

　　客服：耐久度100

　　客服：耐久度99

　　客服：耐久度98

　　…

　　客服：耐久度1 ,请注意维修

　　只需要进行一次HTTP请求，就可以持续的从服务端拿数据了，而且不用的每次都询问我们客户的身份信息。每次询问身份，这种重复性的无用功，后端服务器每次都必须要听上一堆(balabalabala)，势必会导致处理效率的下降，还要浪费带宽(微信红包少于3分钱，表示不抢，网费都不够)。

　　解决服务器上的资源消耗

　　我们的前后端交互，其实还有一个中端处理过程，前端发起HTTP协议请求，需要在中端(Ngnix)过程中进行中转，然后再由中端向我们的后端(java)传递信息。我们的中端处理效率是非常高效的，大部分的资源消耗和效率就卡在我们的后端服务器的处理信息(哎~永远的痛)。

　　Websocket就解决了这样一个难题，建立后，可以直接跟中端处理中心建立持久连接，有信息的时候后端程序通知中端处理中心，然后中端在统一转交给前端。这样，就可以解决后端服务器处理速度过慢的问题了。

　　Websocket的一次握手升级请求，整个通讯过程是建立在一次连接/状态中，服务端会一直知道你的ID info，直到你关闭请求，这样就解决了中端处理中心需要反复解析HTTP协议，还要查看ID info的信息。

　　数据实时最新

　　相对于轮询来说，轮询是需要通过客户端不断的请求，务必会导致请求的时候服务端的数据还没有更新，导致不必要的流量浪费和无谓的请求。