即时通讯（instant-messaging）的前世今生

阿里云国内75折回扣微信号：monov8

阿里云国际，腾讯云国际，低至75折。AWS 93折免费开户实名账号代冲值优惠多多微信号：monov8 飞机：@monov6

原文地址https://github.com/kkcode24/websocket

开始之前(overview)

使用web来构建实时展示信息类似股票信息火车票余票或是即时聊天信息等等

传统的实现方式

轮询长轮询 …
不管以上什么方式在使用的时候都有缺点或是值得改进的地方。

ajax轮询

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

场景再现

客户端啦啦啦有没有新信息(Request)

服务端没有Response

客户端啦啦啦有没有新信息(Request)

服务端没有。。Response

客户端啦啦啦有没有新信息(Request)

服务端你好烦啊没有啊。。Response

客户端啦啦啦有没有新消息Request

服务端好啦好啦有啦给你。Response

客户端啦啦啦有没有新消息Request

服务端。。。。。没。。。。没。。。没有Response —- loop

长轮询 long poll

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

场景再现

客户端啦啦啦有没有新信息没有的话就等有了再返回给我吧Request

服务端额。。等待到有消息的时候。。。有了来吧给你Response

客户端啦啦啦有没有新信息没有的话就等有了再返回给我吧Request -loop

结论

从上面可以看出其实这两种方式都是在不断地建立HTTP连接然后等待服务端处理可以体现HTTP协议的另外一个特点被动性
被动性呢其实就是服务端不能主动联系客户端只能由客户端发起。

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

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

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

客户端啦啦啦啦有新信息么

服务端月线正忙请稍后再试503 Server Unavailable

客户端。。。。好吧啦啦啦有新信息么

服务端月线正忙请稍后再试503 Server Unavailable

客户端然后服务端在一旁忙的要死服务器我要更多的服务器更多。。更多。。

websocket实现方式

websocket与http

websocket是html5新出的东西协议但是HTTP协议并没有变化或者说是websocket与http协议没有多大关系HTTP协议是不支持持久链接的长链接循环链接的不算。

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

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ridtlIlz-1675847682543)(null)]

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

再简单来说层级不一样。

Websocket是什么样的协议具体有什么优点?

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

HTTP的生命周期通过 Request 来界定也就是一个 Request 一个 Response 那么在 HTTP 1.0 中这次HTTP请求就结束了。

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

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

首先我们来看个典型的 Websocket 握手@wikepedia

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

这段类似HTTP协议的握手请求中多了几个东西

Upgrade: websocket
Connection: Upgrade

这个就是websocket的核心了告诉ApacheNginx等服务器注意了我发起的是Websocket协议快点帮我找对应的助理处理不是那个老土的http协议

Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13

首先sec-WebSocket-Key是一个base64 encode的值这个是浏览器随机生成的告诉服务器泥煤不要忽悠窝我要验证你是不是真正的websocket的助理。

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

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

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

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: HSmrc0sMlYUkAGmm5OPpG2HaGWk=
Sec-WebSocket-Protocol: chat

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