简单易懂而详细的讲解websocket及其简单应用

浅显而详细的讲解websocket及其简单应用

目录

• 1.什么是webSocket
• 2.webSocket通信和http通信对比
• 3.websocket相较于Http的优点
• 4.何时需要webSocket
• 5.如何建立websocket通信
• 6.自制websocket模块简介
• 7.webSocket的一些简单应用

1. 什么是webSocket

​ websocket是一种新的协议，它是为了在浏览器和服务器之间建立一个不受限制的双向通信通道而诞生的。不同于http的短链接应答机制和被动应答特征，webSocket可以在客户端之间建立起一个长效连接通道，且服务端和客户端之间可以互相进行通信，直到某一方关闭连接。

​ 以上都是概念性的述说，为了方便理解，很多人在打比方的时候会以池塘和钓鱼的形式来诉说http和websocket的区别，这个比方确实很形象，但是这里为了方便后文的继续讲述我就按照自己的理解和比喻来进行诉说了：

​ 现在2个人需要进行对话，A在家里，B已经到了A的家门口，

​ 对于Http来说，对话的情况是这样的：B敲A的家门并往门内塞了表明我是谁我要干吗的文件，然后A看了一下塞进来的文件，随后打开了门，B对A说了一句话，A用一句话回答了B的话然后就关门了，如果还没聊完，B和A就只能不厌其烦的重复以上的过程才能进行聊天。要注意的是，这里的对话是A没说话前B不能说话，A说话了B才能说话且只能用一句话来进行回答

​ 而对于webSocket来说，对话的情况就不一样了：B敲A的家门并往门内塞了表明我是谁我要干吗的文件同时还在文件中附上一句话：“这门太碍事了，挡着我们讲话了，不要这门了，我们直接说话吧”，然后A看了一下塞进来的文件，说：”来了“，然后A打开了门，并把门给拆了，双方就一直进行对话聊天，一直到A或B中的某一个人离开为止，然后再把门给安上

2. webSocket通信和http通信对比

​ 对于http来说，进行通信是一问一答的，即一个request只能对应一个response，response还不能主动发出

​ 打个比方，还是上面那个对话的例子

现在2个人需要进行对话，A在家里，B已经到了A的家门口，B敲A的家门并往门内塞了表明我是谁我要干吗的文件，然后A看了一下塞进来的文件，随后打开了门，B对A说了一句话，A用且只能用一句话回答了B的话然后就关门了，如果还没聊完，B和A就只能不厌其烦的重复以上的过程才能进行聊天。要注意的是，这里的对话是A没说话前B不能说话，A说话了B才能说话且只能用一句话来进行回答

​ 上面的比喻中，A对应服务端，A在家中也就是服务器是在线状态正常运作，B就是客户端，门就是http协议

​ 对话前，“B敲A的家门并往门内塞了表明我是谁我要干吗的文件”，也就是客户端向服务端发送了一次http请求，其中的文件就是请求头

​ “随后打开了门”，也就是http连接建立了

​ “B对A说了一句话，A用且只能用一句话回答了B的话然后就关门了”, 以及“A没说话前B不能说话”，也就是说服务器是被动进行响应的，没有resquest就不会有response，且一旦发出response后本次通信结束，断开连接

​ “如果还没聊完，B和A就只能不厌其烦的重复以上的过程才能进行聊天”，也就是说如果一次通信不足以完成需求，就只能不停建立连接发送request

​

​ 对于websocket来说，要进行通信首先要由客户端向服务器端发送一次http请求，待服务器端进行响应后就会将http协议替换/升级（upgrade）为websocket协议，之后客户端和服务端就会根据websocket协议进行长效双向通信

​ 打个比方，还是上面那个对话的例子：

现在2个人需要进行对话，A在家里，B已经到了A的家门口，B敲A的家门并往门内塞了表明我是谁我要干吗的文件同时还在文件中附上一句话：“这门太碍事了，挡着我们讲话了，不要这门了，我们直接说话吧”，然后A看了一下塞进来的文件，说：”来了“，然后A打开了门，并把门给拆了，双方就一直进行对话聊天，一直到A或B中的某一个人离开为止，然后再把门给安上

​ 上面的比喻中，A对应服务端，A在家中也就是服务器是在线状态正常运作，B就是客户端，门就是http协议

​ 对话前，B敲A的家门并往门内塞了表明我是谁我要干吗的文件，也就是客户端向服务端发送了一次http请求，其中的文件就是请求头

​ 同时还在文件中附上一句话：“这门太碍事了，挡着我们讲话了，不要这门了，我们直接说话吧”，然后A看了一下塞进来的文件，说：”来了“，也就是服务端接收到了http请求对请求头解析且解析到了协议升级请求并对请求进行应答

​ 然后A打开了门，并把门给拆了，也就是服务端将http协议替换/升级（upgrade）为了websocket协议

​ “门”拆了之后，双方就一直进行对话聊天，一直到A或B中的某一个人离开为止，也就是http协议进行了替换，替换成了websocket协议，通信就建立起来了，此时双方都可以给对方发送消息，直到某一方关闭连接

3. websocket相较于Http的优点

​ 在具有实时性，需要进行长连接的场景下，http的应答机制限制了它的发挥，虽然办法总比困难多，也有几个解决这个问题的方法（例如短轮询、长轮询、长连接/流），但是随之而来的也只是问题的伪解决和各种高消耗，且这几种方法并没能突破http协议的被动性和无状态性的问题，因此这其中的方法总有些不尽人意。以下将会对这些方法简单讲解并将其对比websocket进行简单的说明，同时为了方便理解，在这里我会再设置一个情景：

A在家，这时候有人打电话来问他点信息············

​ 短轮询：其本质上就只是设定了个定时器，每隔一定时间对服务器发送请求，这种方式虽然是兼容性最好的方式，但是在请求和响应的过程中仍然消耗了时间，因此只是一个伪实时，并且由于是不间断频繁的发送请求，这回对客户端和服务器带来很大的压力。放在上面设置的情景中就是：

一个电话打来问A：“有收到XXX的消息吗？”

A回答：“没有” 然后挂断了电话。

隔一段很短的时间后这个人又打电话过来问：“有收到XXX的消息吗？”

A回答：“没有”然后挂断了电话。

隔一段很短的时间后这个人又打电话过来问：“有收到XXX的消息吗？”

A回答：“你烦不烦啊？没有！”然后挂断了电话。

········这个不停打电话询问的情况就这么一直循环到A有了XXX的消息并在某次通话中告诉电话那一头才结束。

电话两头都烦的不行了，这就是这么做带给客户端和服务端的压力

​ 长轮询：其本质上和短轮询并没有太大差别，仍是不停的发送向服务端发送请求，但是短轮询的请求是立即请求和立即响应，长轮询是将超时时间增加了很长，是立即请求和挂起等待响应直到请求超时或收到消息。相较于短轮询，它的请求数量大幅减少，节省了很多资源，但是因为是一直等待状态，这就给服务器带来了很大压力，一旦同时请求数过多，就会极其考验服务器的并发量。同时，这个既然是叫长轮询，也就意味着是不停的请求，也就是如果数据量过大或者更新的够频繁，本质上也就重新变回了短轮询，放在上面设置的情景中就是：

一个电话打来问A：“有收到XXX的消息吗？” A回答：“没有” 然后A没挂断电话就一直保持接通状态放在那里，直到A收到了XXX的消息再拿起电话告诉电话另一头才挂断

或是等到电话接线员发现这一路电话线上虽然接通很久了但是一直没人说话，接线员手动将其干掉了，但是这种情况下电话那头没收到消息，于是又打了一次电话，A又接了电话然后放在了那里继续等待收到XXX的消息。

当然这只是一个电话，如果是1000个电话，A一个人就要同时管1000个放着的电话；1万个电话，A一个人就要同时管1万个放着的电话，A就会累到不行管不过来而导致效率低下，同时A的家里能安的电话是有限的，一旦达到了这个上限，别的电话就再也接不进来了，同时A也很有可能会因为一个人管不了那么多电话就直接罢工，老子不干了。 同时，如果一下更新的信息过多，就会变成刚说完信息挂断了又有信息了然后又打电话·······

​ 长连接/流：和长轮询不同的是，长轮询是“轮询”，而长连接是“连接”，长轮询只是一个超时时间非常长的http请求，而长连接是在建立了http连接之后就会一直保持连接，也就是服务器在接收到请求之后会不停刷新连接状态以保证连接不会中断，可以在这个连接中完成多个http请求，但是每次传输依旧是需要发送单独的header，且长连接依旧是伪长连接，它并不是永久连接的，在一段时间内如果没有http请求发送过来依旧会被服务器切断连接。同时连接数一旦过多，同长轮询一样对服务器也是有相当的考验，而且因为也是基于http协议的，也就是本质上还是request和response的消息对，由于http协议的被动性和无状态性，因此在实时性上依旧是伪实时，放在上面设置的情景中就是：

一个电话打来问A：“有收到XXX的消息吗？”

A回答：“没有” 然后没挂断电话就放在那里

隔不长时间后A拿起电话问：“在吗在吗？”

电话那头说：“在的”，然后A又放下了电话·······

就这样一直到收到消息，A告诉电话另一头所有消息后让电话另一头别挂继续等，然后又进入了隔不久就问一次对面还在不在的状态循环

当然这只是一个电话，如果是1000个电话，A一个人就要同时管1000个放着的电话；1万个电话，A一个人就要同时管1万个放着的电话，A就会累到不行管不过来而导致效率低下，同时A的家里能安的电话是有限的，一旦达到了这个上限，别的电话就再也接不进来了，同时A也很有可能会因为一个人管不了那么多电话就直接罢工，老子不干了。

​ 同时http协议的被动性和无状态性也是性能资源高开销的原因之一，在我理解之中也是导致上面几个方法需要大量开销资源的根本原因之一：

被动性：在我理解之下也是http应答机制的一种解释，所谓应答机制，在我个人的理解就是”应“和”答“，有”应“才有”答“，无“应”则无“答”（即被动），和一”应“对一”答“（request和response是一一对应关系），一“应”一“答”则结束（返回response后该次http请求结束），也就是只有客户端向服务端发送了1次request请求后，服务器才能且只能进行1次response响应，这时服务器是被动进行响应的。因此需要不停发送请求以便获取到最新信息。

无状态性：服务器不会存储连接信息。因为每次请求完毕都会断开连接，而服务器不存储连接信息，因此每次发送请求都不仅需要重新建立连接，还要重新读取解析头信息，而头信息中有相当大的一部分是与有用的信息无关的信息，这就增大了开销

​ 这两点放在上面的情景中就是：

被动性：A从来不记录对面的电话，因此就算有消息了没法回拨告诉对面，只能等对面自己打电话过来问

无状态性：A对于每个打过来的电话都要进行接通，但是从不记录对面信息的他每次接通电话都要问对面问题确认信息，但是对面回答问题的时候会参杂了很多废话，一顿巴拉巴拉之后A才从废话中获取到了标志信息确认了对面的身份

​ 而websocket则突破了http协议的限制，达到了实时性的效果（废话，因为用的根本不是http协议）

​ 在websocket中为了兼容需要，它在建立连接的同时依然使用了http协议进行发送第一次请求，当服务端收到响应后就会将http协议替换为websocket协议建立长效双向通信通道，所谓长效，就是一直是连接状态，双向就是不只是客户端可以向服务器端发送请求，同时服务器端也可以向客户端主动发送效信息，以上这两种特点，突破了http协议的被动性和无状态性的特点，大大减少了反复建立连接和反复解析头信息带来的资源开销（因为服务器可以主动推送信息，所以客户端在建立连接之后就不用再频繁发送请求进行询问了，服务端一旦有消息就会主动推送给客户端，省去了建立连接和解析头信息等的时间达到了实时的效果，同时也减少了开销），且websocket使用起来相对简单。放在上面的情景中就是：

一个电话打来问A：“有收到XXX的消息吗？” A回答：“没有”，然后电话那头说：“那我给你我的联系方式，有消息了你告诉我” A回答：“好”

在这里他们就以另一种方式保持联系状态（有电话号码），而不是无法进行联系（没电话号码，不知道要怎么联系上对面）只能等待对面打电话过来问，同时因为留有电话，A在收到消息后可以直接且一直告诉电话另一头消息

​ 当然websocket也是有缺点的，因为是新的协议，就会有可能进行变动，而且因为是“新”，兼容性也是个问题

4. 何时需要webSocket

​ 如上文所说，在需要用到长链接或者需要进行双向通信等具有实时性的场景的时候就会用到，例如聊天室、广播、直播等

5. 如何建立websocket通信

客户端操作

		var _ip = /*这里放ip地址 如 ws://10.20.159.666:8080*/;
        
        // 建立websocket对象
        var ws = new WebSocket(_ip);

        // 连接成功时
        ws.addEventListener("open", function () {
   
            console.