Http 遇上 Websocket 协议

Posted 2021-04-25 开发者技术前线

说到协议，我们第一反应都会想到http，既然这样，那就对Http协议再简单的BB一番，没有对比就没有伤害，我们来见证一下最终是谁会是受伤的一方，当然结果还是你说了算，不要问小编为什么，因为你牛逼啊。

Http和Https详细介绍请看作者写的一篇文章：。

Http协议：

众所周知的超文本传输协议，所有的万维网都遵循此协议，这家伙出道早（1945年传说中RFC-http1.0），加上又没有竞争对手可称之为在协议界的一大霸主。

建立在TCP协议之上，称之为http，但是建立在SSL和TLS协议层之上，又变成了人们常说的https。总之不管怎样，他们只是所承载的协议层不同罢了，不要太介怀。如果你很是介怀，没办法，小编只能说你先去熟悉网络的7层协议，一层层分析，慢慢介怀去。

Http请求响应模式：

宏观上看是不是超级简单？一个Request 对应一个 Response。建立连接后，客户端发送一次请求，服务端确认收到了，就被动反应一下。看起来很不友好的样子，在1.0时更可怜，默认的是短连接，客户端和服务端之间频繁的建立连接，频繁的断开连接，在1.1起开始引入keep-alive（长连接）即是在http请求的header中加了一个识别：connetion:keep-alive(代表告诉服务器，我要的是长连接)。

但依旧解决不了服务端的‘高冷’和‘惰性’。因此引发了下一个问题：http协议是有很大缺陷的。

Http协议的缺点：

通过上面简单的介绍，我们明显感觉到，客户端和服务端之间的交互有点生硬，服务端有点被动，客户端问一句，服务端答一句，客户端没命的啰嗦就会导致浪费时间和带宽（针对于短连接来说）。

如果是长连接的话，那可能更惨，客户端发一个请求，服务端没有及时返回，链接就一直建立着，上面也说了，http的相应模式无论是多少台客户端发出请求，服务端的标配是一个request对应一个response，如此说来，如果很多的这样的链接的话，那么服务端就有扛不住的时候，所以有的时候就会碰到server is too busy，这时你又该骂娘了。

说到这，我们再来说说，这种不友好的相应模式最终的根源是啥。

哦，原来是有两种机制导致的，Ajax轮询long poll的轮询机制，分别对应短连接和长连接的实现形式。

ajax轮询是，孜孜不倦，乐在其中啊，那我就隔几秒请求一次，服务端和客户端来回的断开建立，就这样一问一答直到客户端拿到了自己想要的东西，所以这种沟通贼浪费时间和宽带。

综上所述，http的一大‘亮点’就是，客户端不请求，服务端绝对不会主动。凸显了http数据传输的一个被动性。

WebSocket协议：

这个社会是发展的，所有风靡一时的荣耀最终都会被崛起的新事物给慢慢取代，当然说的有点严重，反正就是那意思了。鉴于http的缺点，伴随着http的发展，直到h5出现，Websocket应运而生。

不过，新事物的单身往往都是踩在巨人的肩膀上的，WebSocket也是基于http协议的一种持久化的协议，并不是跟http毫无关系，可以说是http协议的一种进化。

那么Websocket是怎样建立连接的呢？

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

以上是请求的头，Websocket很是高调啊，生怕对方不知道是自己的协议，整了这么多关键字眼，废话不多说，抽几个关键的说说吧。

Upgrade && Connection：告诉服务端我采取的是什么协议。

Sec-WebSocket-Key：别乱来，我是有身份证的。

剩下的就不说了，很显然，客户端是比较仔细的，定制的很是详细。

服务器接到请求后，就回应了下：

HTTP/1.1 101 Switching Protocols

Upgrade: websocket

Connection: Upgrade

Sec-WebSocket-Accept: HSmrc0sMlYUkAGmm5OPpG2HaGWk=

Sec-WebSocket-Protocol: chat

看起来服务端也是很守规矩，告诉客户端，你看看信息对不对。

细心的同学会发现，不对啊，那个发送的key和请求的key怎么不一样呢？孩子别太单纯那是服务端加过密的，小编没搞错的话应该是SHA-1的加密方式。

好了，以上就是客户端和服务端建立连接的过程。

Websocket特点：

回归到http协议的被动性和一些缺点，那么Websocket协议就凸显的很好了，请求只需要成功建立一次，这次咸鱼翻身了，服务端会屁颠屁颠的主动把信息反馈给客户端，完美解决了之前的被动性，提高沟通效率，减少了沟通成本，真正建立了久连接。

但是，人无完人，websockt需要浏览器的支持，如果有些浏览器不支持，也没什么卵用了。另外假如设置的有代理，需要代理也支持。更要命的是需要服务器支持，如果服务器不支持，那对不起，发了一堆什么破乱玩意，本座不认识，打回！

另外，websocket实现的是双向通道，对网络的链接要求很高，这是其优点也是缺点，一旦一方网络有问题，那就直接game-over了。

总结：

以上是作者的理解并加以总结，另外，两种协议终究哪个更好，你们说了算。

面试资料免费获取请回复“面试资料”，学习请回复“学习"

开发者技术前线 汇聚最新最热的技术干货，

行业动态，职场思考， 热点思维，一线面经！

相关推荐