WebSocket的故事（一）—— WebSocket的由来

以你之姓@ 2021-09-24 08:30 425阅读 0赞

# 前言 #

最近，偶然在掘金上发现了一个大牛写的这篇文章，感觉作者写的非常好，防止以后找不到了，这里转载记录一下，方便以后使用。

# 概述 #

微信小程序、小游戏的火爆，都让WebSocket的应用变得无处不在。针对这个主题，笔者打算做一个系列博客，旨在由浅入深的介绍WebSocket以及在Springboot和JS中如何快速构建和使用WebSocket提供的能力。

本系列计划包含如下几篇文章：

**第一篇，什么是WebSocket以及它的用途**  
[第二篇，Spring中如何利用STOMP快速构建WebSocket广播式消息模式][Spring_STOMP_WebSocket]  
[第三篇，Springboot中，如何利用WebSocket和STOMP快速构建点对点的消息模式(1)][Springboot_WebSocket_STOMP_1]  
[第四篇，Springboot中，如何利用WebSocket和STOMP快速构建点对点的消息模式(2)][Springboot_WebSocket_STOMP_2]  
[第五篇，Springboot中，实现网页聊天室之自定义WebSocket消息代理][Springboot_WebSocket]  
[第六篇，Springboot中，实现更灵活的WebSocket][Springboot_WebSocket 1]

# 本篇的主线 #

首先由一个典型场景引出WebSocket的需求场景，进而阐述WebSocket协议本身。包括其定义，特点以及握手过程报文的解读。最后，再次从**协议维度**和**实现长连接的方法**两个方面，对比了HTTP与WebSocket的异同，让读者对WebSocket有更深的认识和理解。

# 本篇适合的读者 #

为了照顾到刚接触前/后端开发的新手，作为系列的开篇文章，本着由浅入深的目的，本文采用了较为详尽的解读方式，老鸟亦欢迎收藏参考。后续篇章也会陆续更新上线，敬请期待。

# 由一个场景说起 #

小铭购买了一张机票，在出发前的几个小时，他希望通过航班动态查询软件，实时的了解航班动态，如是否有延误，取消等信息。

那么这时查询软件与服务器交互如下图：

![format_png][]

很容易理解，每一次航班动态查询，client都需要向server发起请求，然后等待server端的响应结果。当client收到响应后，本次通信的生命周期即宣告结束。

可是小铭说： **我希望只查询一次航班动态，当航班有更新时，服务器可以主动把最新的航班动态信息推送给我！**

怎么办？聪明的程序猿想到了如下的办法：

*  **轮询（如ajax的轮询）方式**

即程序内部在小铭第一次请求时，记录下这个请求信息和响应信息，每隔固定时间（例如1分钟）请求一次服务器，服务器返回当前最新状态，对比之前收到的信息，如果相比有变更，则通知小铭；

> 客户端：有没有新动态(Request)  
> 服务端：正常起飞（Response）  
> 客户端：啦啦啦，有没有新动态(Request)  
> 服务端：正常起飞。。（Response）  
> 客户端：有没有新动态(Request)  
> 服务端：你好烦啊，正常起飞。。（Response）  
> 客户端：有没有新动态（Request）  
> 服务端：好啦好啦，有啦给你，延误30分钟。。（Response）  
> 客户端：有没有新动态（Request）  
> 服务端：没有。。。（Response）

*  **服务端增加延迟答复(长连接)**

即程序内部依然采用轮询方式，不过比上一个方案相比，采取了阻塞方式。（一直打电话，没收到就不挂电话），也就是说，客户端发起连接后，如果服务端没消息，就一直不返回Response给客户端。直到有消息才通知小铭，之后客户端再次建立连接，周而复始。

> 客户端：有没有新动态，没有的话就等有了才返回给我吧（Request）  
> 服务端：等到有动态的时候再告诉你。（过了一会儿）来了，给你，延误30分钟（Response）  
> 客户端：有没有新动态，没有的话就等有了才返回给我吧（Request）

**从整个交互的过程来看，这两种都是非常消耗资源的。**

*  第一种方案,即轮询，需要服务器有很快的处理速度和处理器资源。（训练有素的接线员）
 *  第二种方案，即HTTP长连接（后文还会介绍），需要有很高的并发，也就是说并行处理的能力。（足够多的接线员）

所以它们都有可能发生下面这种情况：

> 客户端：有新动态么？  
> 服务端：问的人太多了，线路正忙，请稍后再试（503 Server Unavailable）  
> 客户端：。。。。好吧，有新动态么？  
> 服务端：问的人太多了，线路正忙，请稍后再试（503 Server Unavailable）  
> 客户端：。。。。服务端你到底行不行啊。。!@\#$%$^&

通过上面这个例子，总结一下我们可以看出，这两种采用HTTP的方式都不是最好的方式，体现在：

*  **HTTP的被动性**：需要很多服务资源。一种需要“接线员”有更快的速度，一种需要更多的“接线员”。这两种都会导致对服务资源（接线员）的需求越来越高。
 *  **HTTP的无状态性**：由于接线员只管接电话和处理请求内容，并不会去记录是谁给他们打了电话，每次打电话，都要重新告诉一遍接线员你是谁和你的请求内容是什么。

那现在想要达到小铭的要求，该怎么办呢？

# WebSocket的真身 #

说了这么半天了，让我们言归正传。基于上述的需求和矛盾，WebSocket出现了。

让我们先来看看，使用了WebSocket以后，上面的场景会变成怎样的流程：

> 客户端：我要开始使用WebSocket协议，需要的服务：chat(查动态)，WebSocket协议版本：13（HTTP Request）  
> 服务端：没问题，已升级为WebSocket协议（HTTP Protocols Switched）  
> 客户端：麻烦航班动态有更新的时候推送通知给我。  
> 服务端：没问题。  
> （……过了10分钟）  
> 服务端：有动态啦，延误30分钟！  
> （……过了30分钟）  
> 服务端：有动态啦，现在开始登机！

由此可见，

*  当使用WebSocket时，服务端可以主动推送信息给客户端了，不必在意客户端等待了多久，不必担心超时断线，解决了被动性问题。
 *  Websocket只需要一次HTTP交互，来进行协议上的切换，整个通讯过程是建立在一次连接/状态中，也就避免了HTTP的无状态性，服务端会一直知道你的信息，直到你关闭请求，这样就解决了服务端要反复解析HTTP请求头的问题。

如下图所示：

![format_png 1][]

# WebSocket的出生 #

WebSocket是HTML5提出的一个协议规范（2011年）附上协议链接：

[The WebSocket Protocol RFC6455][]

WebSocket约定了一个通信的规范，通过一个握手的机制，客户端（如浏览器）和服务器（WebServer）之间能建立一个类似Tcp的连接，从而方便C-S之间的通信。

## WebSocket协议的特点 ##

*  建立在 TCP 协议之上，它需要通过握手连接之后才能通信，服务器端的实现比较容易。
 *  与 HTTP 协议有着良好的兼容性。默认端口也是80或443，并且握手阶段采用 HTTP 协议，因此握手时不容易屏蔽，能通过各种 HTTP 代理服务器。
 *  数据格式比较轻量，性能开销小，通信高效。可以发送文本，也可以发送二进制数据。
 *  没有同源限制，客户端可以与任意服务器通信。
 *  协议标识符是ws（如果加密，则为wss），服务器网址就是URL。（例如：ws://www.example.com/chat）
 *  它是一种双向通信协议，采用异步回调的方式接受消息，当建立通信连接，可以做到持久性的连接，WebSocket服务器和Browser都能主动的向对方发送或接收数据，实质的推送方式是服务器主动推送，只要有数据就推送到请求方。

用一张图来描述各个协议的关系：

![format_png 2][]

## WebSocket的通信建立——握手过程 ##

WebSocket的握手使用HTTP来实现，客户端发送带有Upgrade头的HTTP Request消息。服务端根据请求，做Response。

### 请求报文： ###

GET wss://www.example.cn/webSocket HTTP/1.1
    Host: www.example.cn
    Connection: Upgrade
    Upgrade: websocket
    Sec-WebSocket-Version: 13
    Origin: http://example.cn
    Sec-WebSocket-Key: afmbhhBRQuwCLmnWDRWHxw==
    Sec-WebSocket-Protocol: chat, superchat
    Sec-WebSocket-Extensions: permessage-deflate; client_max_window_bits

详细解释一下：

*  **第1、2行**：与HTTP的Request的请求行一样，这里使用的是HTTPS协议，所以对应的是wss请求。
 *  **第3行**：Connection：HTTP1.1中规定Upgrade只能应用在直接连接中。带有Upgrade头的HTTP1.1消息必须含有Connection头，因为Connection头的意义就是，任何接收到此消息的人（往往是代理服务器）都要在转发此消息之前处理掉Connection中指定的域（即不转发Upgrade域）。
 *  **第4行**：Upgrade是HTTP1.1中用于定义转换协议的header域。 如果服务器支持的话，客户端希望使用已经建立好的HTTP（TCP）连接，切换到WebSocket协议。
 *  **第5行**：Sec-WebSocket-Version标识了客户端支持的WebSocket协议的版本列表。
 *  **第6行**：Origin为安全使用，防止跨站攻击，浏览器一般会使用这个来标识原始域。
 *  **第7行**：Sec-WebSocket-Key是一个Base64encode的值，这个是客户端随机生成的，用于服务端的验证，服务器会使用此字段组装成另一个key值放在握手返回信息里发送客户端。
 *  **第8行**：Sec\_WebSocket-Protocol是一个用户定义的字符串，用来区分同URL下，不同的服务所需要的协议，标识了客户端支持的子协议的列表。
 *  **第9行**：Sec-WebSocket-Extensions是客户端用来与服务端协商扩展协议的字段，permessage-deflate表示协商是否使用传输数据压缩，client\_max\_window\_bits表示采用LZ77压缩算法时，滑动窗口相关的SIZE大小。

注：如果对压缩扩展协商的细节感兴趣，可参考下面的RFC7692了解更多细节。 [Compression Extensions for WebSocket RFC7692][]

### 响应报文： ###

HTTP/1.1 101
    Server: nginx/1.12.2
    Date: Sat, 11 Aug 2018 13:21:27 GMT
    Connection: upgrade
    Upgrade: websocket
    Sec-WebSocket-Accept: sLMyWetYOwus23qJyUD/fa1hztc=
    Sec-WebSocket-Protocol: chat
    Sec-WebSocket-Extensions: permessage-deflate;client_max_window_bits=15

详细解释一下：

*  **第1行**：HTTP的版本为HTTP1.1，返回码是101，开始解析Header域（不区分大小写）。
 *  **第2,3行**：服务器信息与时间。
 *  **第4行**：Connection字段，包含Upgrade。
 *  **第5行**：Upgrade字段，包含websocket。
 *  **第6行**：Sec-WebSocket-Accept字段，详细介绍一下：

> Sec-WebSocket-Accept字段生成步骤：
> 
> 1.  将Sec-WebSocket-Key与协议中已定义的一个GUID “258EAFA5-E914-47DA-95CA-C5AB0DC85B11”进行拼接。
> 2.  将步骤1中生成的字符串进行SHA1编码。
> 3.  将步骤2中生成的字符串进行Base64编码。

> 客户端通过验证服务端返回的Sec-WebSocket-Accept的值, 来确定两件事情:

> 1.  服务端是否理解WebSocket协议, 如果服务端不理解,那么它就不会返回正确的Sec-WebSocket-Accept，则建立WebSocket连接失败。
> 2.  服务端返回的Response是对于客户端的此次请求的,而不是之前的缓存。 主要是防止有些缓存服务器返回缓存的Response.

*  **第7行**：Sec-WebSocket-Protocol字段，要判断是否之前的Request握手带有此协议，如果没有，则连接失败。
 *  **第8行**：扩展协议协商，支持压缩，且LZZ的滑动窗口大小为15。

至此，握手过程就完成了，此时的TCP连接不会释放。客户端和服务端可以互相通信了。

# HTTP1.1与WebSocket的异同 #

最后，作为总结，让我们再来回顾一下HTTP1.1与WebSocket的相同与不同。加深对WebSocket的理解。

## 协议层面的异同 ##

### 相同点 ###

*  都是基于TCP的应用层协议。
 *  都使用Request/Response模型进行连接的建立。
 *  在连接的建立过程中对错误的处理方式相同，在这个阶段WebSocket可能返回和HTTP相同的返回码。

### 不同点 ###

*  HTTP协议基于Request/Response，只能做单向传输，是半双工协议，而WebSocket是全双工协议，类似于Socket通信，双方都可以在任何时刻向另一方发送数据。
 *  WebSocket使用HTTP来建立连接，但是定义了一系列新的Header域，这些域在HTTP中并不会使用。换言之，二者的请求头不同。
 *  WebSocket的连接不能通过中间人来转发，它必须是一个直接连接。如果通过代理转发，一个代理要承受如此多的WebSocket连接不释放，就类似于一次DDOS攻击了。
 *  WebSocket在建立握手连接时，数据是通过HTTP协议传输的，但在建立连接之后，真正的数据传输阶段是不需要HTTP协议参与的。
 *  WebSocket传输的数据是二进制流，是以帧为单位的，HTTP传输的是明文传输，是字符串传输，WebSocket的数据帧有序。

## HTTP的长连接与WebSocket的持久连接的异同 ##

### HTTP的两种长连接 ###

一、HTTP1.1的连接默认使用长连接（Persistent connection）

即在一定的期限内保持链接，客户端会需要在短时间内向服务端请求大量的资源，保持TCP连接不断开。客户端与服务器通信，必须要有客户端发起然后服务器返回结果。客户端是主动的，服务器是被动的。在一个TCP连接上可以传输多个Request/Response消息对，所以本质上还是Request/Response消息对，仍然会造成资源的浪费、实时性不强等问题。如果不是持续连接，即短连接，那么每个资源都要建立一个新的连接，HTTP底层使用的是TCP，那么每次都要使用三次握手建立TCP连接，即每一个request对应一个response，将造成极大的资源浪费。

二、“长轮询”

即客户端发送一个**超时时间很长**的Request，服务器保持住这个连接，在有新数据到达时返回Response

### WebSocket的持久连接 ###

只需建立一次Request/Response消息对，之后都是TCP连接，避免了需要多次建立Request/Response消息对而产生的冗余头部信息。节省了大量流量和服务器资源。因此被广泛应用于线上WEB游戏和线上聊天室的开发。

# 下一篇内容前瞻 #

下一篇中，笔者将使用JS（前端）和Springboot（后端），详细介绍如何利用Springboot框架，快速构建一个基于STOMP的简单WebSocket通信系统。敬请关注。

作者：xNPE  
链接：[https://juejin.im/post/5b6ef32fe51d4519610e5e7e][https_juejin.im_post_5b6ef32fe51d4519610e5e7e]  
来源：掘金  
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

写博客是为了记住自己容易忘记的东西，另外也是对自己工作的总结，希望尽自己的努力，做到更好，大家一起努力进步！  
  
如果有什么问题，欢迎大家评论，一起探讨，代码如有问题，欢迎各位大神指正！  
  
给自己的梦想添加一双翅膀，让它可以在天空中自由自在的飞翔！

[Spring_STOMP_WebSocket]: https://blog.csdn.net/smilehappiness/article/details/106470154
[Springboot_WebSocket_STOMP_1]: https://blog.csdn.net/smilehappiness/article/details/106470179
[Springboot_WebSocket_STOMP_2]: https://blog.csdn.net/smilehappiness/article/details/106470202
[Springboot_WebSocket]: https://blog.csdn.net/smilehappiness/article/details/106470221
[Springboot_WebSocket 1]: https://blog.csdn.net/smilehappiness/article/details/106470235
[format_png]: /images/20210923/0be9bb7381e94e049463b387e0f0bbf2.png
[format_png 1]: /images/20210923/bbb17c7870ea4078919047955e9604db.png
[The WebSocket Protocol RFC6455]: https://www.rfc-editor.org/rfc/pdfrfc/rfc6455.txt.pdf
[format_png 2]: /images/20210923/a0216aa4f4ae4d1a8123a5c7b653ec9b.png
[Compression Extensions for WebSocket RFC7692]: https://tools.ietf.org/pdf/rfc7692.pdf
[https_juejin.im_post_5b6ef32fe51d4519610e5e7e]: https://juejin.im/post/5b6ef32fe51d4519610e5e7e