Websocket：看完让你彻底搞懂Websocket原理即时消息通讯

http://goeasy.io/cn/pricing

封装好的socket Web消息推送系统&＃xff0c;便捷实现web端消息推送&＃xff0c;

原生的封装参考&＃xff1a;https://blog.csdn.net/young_phper/article/details/52441143

分割线--------------------------------------------------------------------------------------------------------------------------------------------------------------------

偶然在知乎上看到一篇回帖&＃xff0c;瞬间觉得之前看的那么多资料都不及这一篇回帖让我对 websocket 的认识深刻有木有。所以转到我博客里&＃xff0c;分享一下。比较喜欢看这种博客&＃xff0c;读起来很轻松&＃xff0c;不枯燥&＃xff0c;没有布道师的阵仗&＃xff0c;纯粹为分享。废话这么多了&＃xff0c;最后再赞一个~

一、websocket与http

WebSocket是HTML5出的东西&＃xff08;协议&＃xff09;&＃xff0c;也就是说HTTP协议没有变化&＃xff0c;或者说没关系&＃xff0c;但HTTP是不支持持久连接的&＃xff08;长连接&＃xff0c;循环连接的不算&＃xff09;

首先HTTP有 1.1 和 1.0 之说&＃xff0c;也就是所谓的 keep-alive &＃xff0c;把多个HTTP请求合并为一个&＃xff0c;但是 Websocket 其实是一个新协议&＃xff0c;跟HTTP协议基本没有关系&＃xff0c;只是为了兼容现有浏览器的握手规范而已&＃xff0c;也就是说它是HTTP协议上的一种补充可以通过这样一张图理解

有交集&＃xff0c;但是并不是全部。

另外Html5是指的一系列新的API&＃xff0c;或者说新规范&＃xff0c;新技术。Http协议本身只有1.0和1.1&＃xff0c;而且跟Html本身没有直接关系。。通俗来说&＃xff0c;你可以用HTTP协议传输非Html数据&＃xff0c;就是这样&＃61;。&＃61;

再简单来说&＃xff0c;层级不一样。

二、Websocket是什么样的协议&＃xff0c;具体有什么优点

首先&＃xff0c;Websocket是一个持久化的协议&＃xff0c;相对于HTTP这种非持久的协议来说。简单的举个例子吧&＃xff0c;用目前应用比较广泛的PHP生命周期来解释。

HTTP的生命周期通过 Request 来界定&＃xff0c;也就是一个 Request 一个 Response &＃xff0c;那么在 HTTP1.0 中&＃xff0c;这次HTTP请求就结束了。

在HTTP1.1中进行了改进&＃xff0c;使得有一个keep-alive&＃xff0c;也就是说&＃xff0c;在一个HTTP连接中&＃xff0c;可以发送多个Request&＃xff0c;接收多个Response。但是请记住 Request &＃61; Response &＃xff0c; 在HTTP中永远是这样&＃xff0c;也就是说一个request只能有一个response。而且这个response也是被动的&＃xff0c;不能主动发起。

教练&＃xff0c;你BB了这么多&＃xff0c;跟Websocket有什么关系呢&＃xff1f;_(:з」∠)_好吧&＃xff0c;我正准备说Websocket呢。。

首先Websocket是基于HTTP协议的&＃xff0c;或者说借用了HTTP的协议来完成一部分握手。

首先我们来看个典型的 Websocket 握手&＃xff08;借用Wikipedia的。。&＃xff09;

GET /chat HTTP/1.1
Host: server.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw&＃61;&＃61;
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13
Origin: http://example.com

熟悉HTTP的童鞋可能发现了&＃xff0c;这段类似HTTP协议的握手请求中&＃xff0c;多了几个东西。我会顺便讲解下作用。

Upgrade: websocket
Connection: Upgrade

这个就是Websocket的核心了&＃xff0c;告诉 Apache 、 Nginx 等服务器&＃xff1a;注意啦&＃xff0c;我发起的是Websocket协议&＃xff0c;快点帮我找到对应的助理处理~不是那个老土的HTTP。

Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw&＃61;&＃61;
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13

首先&＃xff0c; Sec-WebSocket-Key 是一个 Base64 encode 的值&＃xff0c;这个是浏览器随机生成的&＃xff0c;告诉服务器&＃xff1a;泥煤&＃xff0c;不要忽悠窝&＃xff0c;我要验证尼是不是真的是Websocket助理。

然后&＃xff0c; Sec_WebSocket-Protocol 是一个用户定义的字符串&＃xff0c;用来区分同URL下&＃xff0c;不同的服务所需要的协议。简单理解&＃xff1a;今晚我要服务A&＃xff0c;别搞错啦~

最后&＃xff0c; Sec-WebSocket-Version 是告诉服务器所使用的 Websocket Draft&＃xff08;协议版本&＃xff09;&＃xff0c;在最初的时候&＃xff0c;Websocket协议还在 Draft 阶段&＃xff0c;各种奇奇怪怪的协议都有&＃xff0c;而且还有很多期奇奇怪怪不同的东西&＃xff0c;什么Firefox和Chrome用的不是一个版本之类的&＃xff0c;当初Websocket协议太多可是一个大难题。。不过现在还好&＃xff0c;已经定下来啦~大家都使用的一个东西~ 脱水&＃xff1a; 服务员&＃xff0c;我要的是13岁的噢→_→

然后服务器会返回下列东西&＃xff0c;表示已经接受到请求&＃xff0c; 成功建立Websocket啦&＃xff01;

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: HSmrc0sMlYUkAGmm5OPpG2HaGWk&＃61;
Sec-WebSocket-Protocol: chat

这里开始就是HTTP最后负责的区域了&＃xff0c;告诉客户&＃xff0c;我已经成功切换协议啦~

Upgrade: websocket
Connection: Upgrade

依然是固定的&＃xff0c;告诉客户端即将升级的是 Websocket 协议&＃xff0c;而不是mozillasocket&＃xff0c;lurnarsocket或者shitsocket。

然后&＃xff0c; Sec-WebSocket-Accept 这个则是经过服务器确认&＃xff0c;并且加密过后的 Sec-WebSocket-Key 。 服务器&＃xff1a;好啦好啦&＃xff0c;知道啦&＃xff0c;给你看我的ID CARD来证明行了吧。。

后面的&＃xff0c; Sec-WebSocket-Protocol 则是表示最终使用的协议。

至此&＃xff0c;HTTP已经完成它所有工作了&＃xff0c;接下来就是完全按照Websocket协议进行了。具体的协议就不在这阐述了。

——————技术解析部分完毕——————

你TMD又BBB了这么久&＃xff0c;那到底Websocket有什么鬼用&＃xff0c; http long poll &＃xff0c;或者ajax轮询 不都可以实现实时信息传递么。

好好好&＃xff0c;年轻人&＃xff0c;那我们来讲一讲Websocket有什么用。来给你吃点胡&＃xff08;苏&＃xff09;萝&＃xff08;丹&＃xff09;卜&＃xff08;红&＃xff09;

三、Websocket的作用

在讲Websocket之前&＃xff0c;我就顺带着讲下 long poll 和 ajax轮询 的原理。

ajax轮询

ajax轮询的原理非常简单&＃xff0c;让浏览器隔个几秒就发送一次请求&＃xff0c;询问服务器是否有新信息。

场景再现&＃xff1a;

客户端&＃xff1a;啦啦啦&＃xff0c;有没有新信息(Request)

服务端&＃xff1a;没有&＃xff08;Response&＃xff09;

客户端&＃xff1a;啦啦啦&＃xff0c;有没有新信息(Request)

服务端&＃xff1a;没有。。&＃xff08;Response&＃xff09;

客户端&＃xff1a;啦啦啦&＃xff0c;有没有新信息(Request)

服务端&＃xff1a;你好烦啊&＃xff0c;没有啊。。&＃xff08;Response&＃xff09;

客户端&＃xff1a;啦啦啦&＃xff0c;有没有新消息&＃xff08;Request&＃xff09;

服务端&＃xff1a;好啦好啦&＃xff0c;有啦给你。&＃xff08;Response&＃xff09;

客户端&＃xff1a;啦啦啦&＃xff0c;有没有新消息&＃xff08;Request&＃xff09;

服务端&＃xff1a;。。。。。没。。。。没。。。没有&＃xff08;Response&＃xff09; —- loop

long poll

long poll 其实原理跟 ajax轮询 差不多&＃xff0c;都是采用轮询的方式&＃xff0c;不过采取的是阻塞模型&＃xff08;一直打电话&＃xff0c;没收到就不挂电话&＃xff09;&＃xff0c;也就是说&＃xff0c;客户端发起连接后&＃xff0c;如果没消息&＃xff0c;就一直不返回Response给客户端。直到有消息才返回&＃xff0c;返回完之后&＃xff0c;客户端再次建立连接&＃xff0c;周而复始。

场景再现&＃xff1a;

客户端&＃xff1a;啦啦啦&＃xff0c;有没有新信息&＃xff0c;没有的话就等有了才返回给我吧&＃xff08;Request&＃xff09;

服务端&＃xff1a;额。。 等待到有消息的时候。。来 给你&＃xff08;Response&＃xff09;

客户端&＃xff1a;啦啦啦&＃xff0c;有没有新信息&＃xff0c;没有的话就等有了才返回给我吧&＃xff08;Request&＃xff09; -loop

从上面可以看出其实这两种方式&＃xff0c;都是在不断地建立HTTP连接&＃xff0c;然后等待服务端处理&＃xff0c;可以体现HTTP协议的另外一个特点&＃xff0c;被动性。

何为被动性呢&＃xff0c;其实就是&＃xff0c;服务端不能主动联系客户端&＃xff0c;只能有客户端发起。

简单地说就是&＃xff0c;服务器是一个很懒的冰箱&＃xff08;这是个梗&＃xff09;&＃xff08;不会、不能主动发起连接&＃xff09;&＃xff0c;但是上司有命令&＃xff0c;如果有客户来&＃xff0c;不管多么累都要好好接待。

说完这个&＃xff0c;我们再来说一说上面的缺陷&＃xff08;原谅我废话这么多吧OAQ&＃xff09;

从上面很容易看出来&＃xff0c;不管怎么样&＃xff0c;上面这两种都是非常消耗资源的。

ajax轮询 需要服务器有很快的处理速度和资源。&＃xff08;速度&＃xff09;long poll 需要有很高的并发&＃xff0c;也就是说同时接待客户的能力。&＃xff08;场地大小&＃xff09;

所以 ajax轮询 和 long poll 都有可能发生这种情况。

客户端&＃xff1a;啦啦啦啦&＃xff0c;有新信息么&＃xff1f;

服务端&＃xff1a;月线正忙&＃xff0c;请稍后再试&＃xff08;503 Server Unavailable&＃xff09;

客户端&＃xff1a;。。。。好吧&＃xff0c;啦啦啦&＃xff0c;有新信息么&＃xff1f;

服务端&＃xff1a;月线正忙&＃xff0c;请稍后再试&＃xff08;503 Server Unavailable&＃xff09;

客户端&＃xff1a;然后服务端在一旁忙的要死&＃xff1a;冰箱&＃xff0c;我要更多的冰箱&＃xff01;更多。。更多。。&＃xff08;我错了。。这又是梗。。&＃xff09;

言归正传&＃xff0c;我们来说Websocket吧

通过上面这个例子&＃xff0c;我们可以看出&＃xff0c;这两种方式都不是最好的方式&＃xff0c;需要很多资源。

一种需要更快的速度&＃xff0c;一种需要更多的’电话’。这两种都会导致’电话’的需求越来越高。

哦对了&＃xff0c;忘记说了HTTP还是一个状态协议。

通俗的说就是&＃xff0c;服务器因为每天要接待太多客户了&＃xff0c;是个健忘鬼&＃xff0c;你一挂电话&＃xff0c;他就把你的东西全忘光了&＃xff0c;把你的东西全丢掉了。你第二次还得再告诉服务器一遍。

所以在这种情况下出现了&＃xff0c;Websocket出现了。他解决了HTTP的这几个难题。首先&＃xff0c;被动性&＃xff0c;当服务器完成协议升级后&＃xff08;HTTP->Websocket&＃xff09;&＃xff0c;服务端就可以主动推送信息给客户端啦。所以上面的情景可以做如下修改。

客户端&＃xff1a;啦啦啦&＃xff0c;我要建立Websocket协议&＃xff0c;需要的服务&＃xff1a;chat&＃xff0c;Websocket协议版本&＃xff1a;17&＃xff08;HTTP Request&＃xff09;

服务端&＃xff1a;ok&＃xff0c;确认&＃xff0c;已升级为Websocket协议&＃xff08;HTTP Protocols Switched&＃xff09;

客户端&＃xff1a;麻烦你有信息的时候推送给我噢。。

服务端&＃xff1a;ok&＃xff0c;有的时候会告诉你的。

服务端&＃xff1a;balabalabalabala

服务端&＃xff1a;balabalabalabala

服务端&＃xff1a;哈哈哈哈哈啊哈哈哈哈

服务端&＃xff1a;笑死我了哈哈哈哈哈哈哈

就变成了这样&＃xff0c;只需要经过一次HTTP请求&＃xff0c;就可以做到源源不断的信息传送了。&＃xff08;在程序设计中&＃xff0c;这种设计叫做回调&＃xff0c;即&＃xff1a;你有信息了再来通知我&＃xff0c;而不是我傻乎乎的每次跑来问你 &＃xff09;

这样的协议解决了上面同步有延迟&＃xff0c;而且还非常消耗资源的这种情况。那么为什么他会解决服务器上消耗资源的问题呢&＃xff1f;

其实我们所用的程序是要经过两层代理的&＃xff0c;即HTTP协议在Nginx等服务器的解析下&＃xff0c;然后再传送给相应的Handler&＃xff08;PHP等&＃xff09;来处理。简单地说&＃xff0c;我们有一个非常快速的 接线员&＃xff08;Nginx&＃xff09; &＃xff0c;他负责把问题转交给相应的 客服&＃xff08;Handler&＃xff09; 。

本身接线员基本上速度是足够的&＃xff0c;但是每次都卡在客服&＃xff08;Handler&＃xff09;了&＃xff0c;老有客服处理速度太慢。&＃xff0c;导致客服不够。Websocket就解决了这样一个难题&＃xff0c;建立后&＃xff0c;可以直接跟接线员建立持久连接&＃xff0c;有信息的时候客服想办法通知接线员&＃xff0c;然后接线员在统一转交给客户。

这样就可以解决客服处理速度过慢的问题了。

同时&＃xff0c;在传统的方式上&＃xff0c;要不断的建立&＃xff0c;关闭HTTP协议&＃xff0c;由于HTTP是非状态性的&＃xff0c;每次都要重新传输 identity info &＃xff08;鉴别信息&＃xff09;&＃xff0c;来告诉服务端你是谁。

虽然接线员很快速&＃xff0c;但是每次都要听这么一堆&＃xff0c;效率也会有所下降的&＃xff0c;同时还得不断把这些信息转交给客服&＃xff0c;不但浪费客服的处理时间&＃xff0c;而且还会在网路传输中消耗过多的流量/时间。

但是Websocket只需要一次HTTP握手&＃xff0c;所以说整个通讯过程是建立在一次连接/状态中&＃xff0c;也就避免了HTTP的非状态性&＃xff0c;服务端会一直知道你的信息&＃xff0c;直到你关闭请求&＃xff0c;这样就解决了接线员要反复解析HTTP协议&＃xff0c;还要查看identity info的信息。

同时由客户主动询问&＃xff0c;转换为服务器&＃xff08;推送&＃xff09;有信息的时候就发送&＃xff08;当然客户端还是等主动发送信息过来的。。&＃xff09;&＃xff0c;没有信息的时候就交给接线员&＃xff08;Nginx&＃xff09;&＃xff0c;不需要占用本身速度就慢的客服&＃xff08;Handler&＃xff09;了

——————–

至于怎么在不支持Websocket的客户端上使用Websocket。。答案是&＃xff1a; 不能

但是可以通过上面说的 long poll 和 ajax 轮询 来 模拟出类似的效果

这里有一个快速SDK的API

https://yunba.io/docs/socketio_api_api_manual