详解 websocket 协议

最新推荐文章于 2025-04-03 19:06:36 发布

MClink

最新推荐文章于 2025-04-03 19:06:36 发布

阅读量7.2k

点赞数 14

分类专栏：网络文章标签：网络 websocket

本文链接：https://blog.youkuaiyun.com/qq_38378384/article/details/107894545

版权

网络专栏收录该内容

13 篇文章

订阅专栏

一、websocket是什么？

websocket 是一个基于应用层的网络协议，建立在tcp 协议之上，和 http 协议可以说是兄弟的关系，但是这个兄弟有点依赖 http ，为什么这么说呢？我们都知道 HTTP 实现了三次握手来建立通信连接，实际上 websocket 的创始人很聪明，他不想重复的去造轮子，反正我兄弟已经实现了握手了，我干嘛还要重写一套呢？先让它去冲锋陷阵呢，我坐收渔翁之利不是更香吗，所以一般来说，我们会先用 HTTP 先进行三次握手，再向服务器请求升级为websocket 协议，这就好比说，嘿兄弟你先去给我排个队占个坑位建个小房子，到时候我在把这房子改造成摩天大楼。而且一般来说 80 和 443 端口一般 web 服务端都会外放出去，这样可以有效的避免防火墙的限制。当然，你创建的 websocket 服务端进程的端口也需要外放出去。

很多人会想问，web开发使用 HTTP 协议不是已经差不多够用了吗？为什么还要我再多学一种呢？这不是搞事情嘛，仔细想想，一门新技术的产生必然有原因的，如果没有需求，我们干嘛那么蛋疼去写那么多东西，就是因为 HTTP 这个协议有些业务需求支持太过于鸡肋了，从 HTTP 0.9 到现在的 HTTP3.0 ，HTTP协议可以说说是在普通的web开发领域已经是十分完善且高效的了，说这个协议养活了全球半数的公司也不为过吧，像 2.0 服务器推送技术，3.0 采用了 UDP 而放弃了原来的 TCP ,这些改动都是为了进一步提升协议的性能，然而大家现在还是基本使用的 HTTP 1.1 这个最为经典的协议, 也是让开发者挺尴尬的。

绝大多数的web开发都是应用层开发者,大多数都是基于已有的应用层去开发应用，可以说我们最熟悉、日常打交道最多的就是应用层协议了，底下 TCP/IP 协议我们基本很少会去处理，当然大厂可能就不一样了，自己弄一套协议也是正常的，这大概也是程序员和码农的区别吧，搬砖还是创新，差别还是很大的。网络这种分层协议的好处我在之前的文章也说过了，这种隔离性很方便就可以让我们基于原来的基础去拓展，具有较好的兼容性。

总的来说，它就是一种依赖HTTP协议的，支持全双工通信的一种应用层网络协议。

二、websocket 能解决什么问题？

工程师应该是以解决问题为主的，如果不会解决问题，只会伸手，必然不会长远，有思考，才会有突破，才能高效的处理事情，所以 websocket 到底解决了什么问题呢？它存在的价值是什么？

这还是得从HTTP说起，大家应该都很熟悉这门协议，我们简单说一下它的特点：

三次握手、四次挥手的方式建立连接和关闭连接
支持长连接和短连接两种连接方式
有同源策略的限制（端口，协议，域名）
单次请求-响应机制，只支持单向通信

其中最鸡肋的就是最后一个特点，单向通信，什么意思呐？就是说只能由一方发起请求（客户端），另一方响应请求（服务端），而且每一次的请求都是一个单独的事件，请求之间还无法具有关联性，也就是说我上个请求和下个请求完全是隔离的，无法具有连续性。

也许你觉得这样的说法比较难懂，我们来举一个栗子：

每个人都打过电话吧，电话打通后可以一直聊天是不是觉得很舒服啊，这是一种全双工的通信方式，双方都可以主动传递信息。彼此的聊天也具有连续性。我们简单把这种方式理解为 websocket 协议支持的方式。

如果打电话变成了 HTTP 那种方式呢？那就不叫打电话了，而是联通爸爸的智能语音助手了，我们知道客户端和服务端本身的身份并不是固定的，只要你可以发起通信，就可以充当客户端，能响应请求，就可以当做服务端，但是在HTTP的世界里一般来说，客户端（大多数情况下是浏览器）和服务器一般是固定的，我们打电话去查话费，会询问要人工服务还是智能助手，如果选了助手，你只要问她问题，她就会找对应的答案来回答你（响应你），一般都是简单的业务，你不问她也不会跟你闲聊，主动才有故事啊！

但是实际上有很多的业务是需要双方都有主动性的，半双工的模式肯定是不够用的，例如聊天室，跟机器人聊天没意思啊，又例如主动推送，我无聊的时候手都不想点屏幕，你能不能主动一点给我推一些好玩的信息过来。

只要做过前后端分离的同学应该都被跨域的问题折磨过。浏览器的这种同源策略，会导致不同端口/不同域名/不同协议的请求会有限制，当然这问题前后端都能处理，然而 websocket 就没有这种要求，他支持任何域名或者端口的访问（协议固定了只能是 ws/wss) ,所以它让人用的更加舒服

所以，上面 HTTP 存在的这些问题，websocket 都能解决！！！

三、websocket 的工作原理

主动是 websocket 的一大特点，像之前如果客户端想知道服务端对某个事件的处理进度，就只能通过轮训( Poll )的方式去询问，十分的耗费资源，会存在十分多的无效请求，下面我简单说推送技术的三种模型区别：

pull (主动获取) 即客户端主动发起请求，获取消息
poll (周期性主动获取) 即周期性的主动发起请求，获取消息
push (主动推送) 服务端主动推送消息给客户端

pull 和 poll 的唯一区别只在于周期性，但是很明显周期性的去询问，对业务来说清晰度很高，这也是为什么很多小公司都是基于轮训的方式去处理业务，因为简单嘛，能力不够机器来撑。这也是很多公司都会面临的问题，如果业务达到了瓶颈，使劲的堆机器，如果用新技术或者更高级的作法，开发成本和维护成本也会变高，还不如简单一点去增加机器配置。

如果两个人需要通话，首先需要建立一个连接，而且必须是一个长链接，大家都不希望讲几句话就得重新打吧，根据上面说的，websocket 会复用之前 HTTP 建立好的长链接，然后再进行升级，所以他和轮训的区别大致如下所示
在这里插入图片描述
（图片来源于网上）

图片省去了建立连接的过程，我们可以发现，基于轮训的方式，必须由客户端手动去请求，才会有响应，而基于 websocket 协议，不再需要你主动约妹子了，妹子也可以主动去约你，这才是公平的世界。

为了更好的阐述这个连接的原理，可以使用swoole 自带的创建websocket 的功能进行测试，服务端代码如下，如果连接不上，可以看看是不是检查一下端口开放情况（iptables/filewall)和网络的连通性，代码如下：

<?php
//创建websocket服务器对象，监听0.0.0.0:9501端口
$ws = new Swoole\WebSocket\Server("0.0.0.0", 9501);

//监听WebSocket连接打开事件
$ws->on('open', function ($ws, $request) {
    var_dump($request->fd, $request->get, $request->server); //request 对象包含请求的相关信息
    //$ws->push($request->fd, "hello, welcome\n");
});

//监听WebSocket消息事件
$ws->on('message', function ($ws, $frame) {  // frame 是存储信息的变量，也就是传输帧
    echo "Message: {$frame->data}\n";
    $ws->push($frame->fd, "server: {$frame->data}");
});

//监听WebSocket连接关闭事件
$ws->on('close', function ($ws, $fd) { // fd 是客户端的标志
    echo "client-{$fd} is closed\n";
});

$ws->start(); // 启动这个进程

通过 php-cli 我们可以启动这个常驻进程。可以通过 netstat 命令查看对应端口的监听情况
在这里插入图片描述

这里我就不写客户端了，直接用网上现成的客户端进行测试，我在此实验使用的网站是这个：
在这里插入图片描述

连接成功后我们可以看到两条记录，上面是该端口的监听情况，代表监听所有IP的9501端口信息下面那条是由于我已经用客户端创建好的一个连接。

  我们通过wireshark 可以抓到相关的报文我们来解释一下这个图
在这里插入图片描述
  首先前三个 tcp 连接很明显就是三次握手了，然后第一个 HTTP 报文是请求升级为 websocket 的报文，我们可以把对应的应用层报文弄出来看一下

  截图的这两个地方就是升级的关键了，connection 字段代表这是一个升级请求，upgrade 表示升级的是 websocket 协议，然后服务端又回复了一个 101 的 HTTP报文表示正在切换中，如下图所示
在这里插入图片描述
  当连接建立完成后，我们为了保持这个连接，服务端会定时发送基于 tcp 的心跳包，我们可以通过抓包看到相关的报文

如果客户端长时间不响应，说明它挂壁了，那么服务端就会把这个连接进行关闭。