webSocket粗谈
Posted 优云运维社区
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了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协议上的一种补充。
协议
在此我们要来BB一个早就存在的概念，持久化的协议，也是webSocket的一个特征，当然这个也是相对于我们的HTTP协议来说的。
HTTP协议请求：
HTTP 1.0: 一个request 一个response 一次HTTP链接这样就算是结束了。
HTTP 1.1:在1.0版本有了改进，加入了一个Keep-Alive，在一次HTTP链接中，我可以发送多个request，接收多个response，但是一个request 只能对应一个response。而且这个response，是被动发起的。
老师：BB了一大堆，小明同学，觉得我讲的如何？
小明：沉默（！@#￥％……）
本屌也是初入江湖，给点时间消化~
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客服完全承包后续服务内容。
小明：我表示啥都没听懂，又给你BBB了这么久，啥都没说明webSocket具体有什么鬼用处？
老师：年轻人，心急吃不了热豆腐哟，接下来我们来细细的说说WebSocket的作用吧。
作用
在讲webSocket之前，请允许老夫再BB一会。让我们来脑补一会 long pull 和 ajax轮询吧
ajax轮询
ajax的原理非常简单，就是定时器，每隔一会发起一个请求，轮询服务端是否有新的信息。
场景大致是这样的：
客户：我的快递到了没呀？（request）
客服：你好，你是？没有（response）
客户：我的快递到了没呀？
客服：你好，你是？没有..
客户：我的快递到了没呀？
客服：你好，你是？没有，真没有
客户：我的快递到了没呀？
客服：你好，你是？!@#$%&*,可能还再路上
客户：我的快递到了没呀？
客服：你好，你是？有了会给你送来的
客户：我的快递到了没呀？
客服：你好，你是？没.....没.....没有啊....啊啊啊啊
long pull
客户端发起请求之后，服务端没有消息就一直不返回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的信息。
数据实时最新
相对于轮询来说，轮询是需要通过客户端不断的请求，务必会导致请求的时候服务端的数据还没有更新，导致不必要的流量浪费和无谓的请求。
作者祝恩良，广通软件一只活在二次元世界的萌货，虽然在三次元的世界卖不了一手好萌~
欢迎入群——“敏捷运维群”，共同探讨交流。
微信添加“broada2015”，或扫码入群。
以上是关于webSocket粗谈的主要内容，如果未能解决你的问题，请参考以下文章