一直以来对WebSocket仅停留在使用阶段，也没有深入理解其背后的原理。当看到 x x x was not upgraded to websocket，我是彻底蒙了，等我镇定下来，打开百度输入这行报错信息，随即看到的就是大家说的跨域，或者Origin导致，其实webSocket本身不存在跨域问题，由于目前在Flutter项目中遇到这个错误，接下来我也将从Flutter源码中寻找问题所在。在此，特别感谢公司后台同事在此问题上的指导和帮助。

既然提到了跨域，我们还是先弄清什么是跨域。在了解什么是跨域的时候，我们首先要了解一个概念，叫同源策略，什么是同源策略呢，就是我我们的浏览器出于安全考虑，只允许与本域下的接口交互。不同源的客户端脚本在没有明确授权的情况下，不能读写对方的资源。

是什么意思呢，就比如你刚刚登录了淘宝买了东西，但是你现在又点进去了另外一个网站，那么你现在的淘宝账户是属于登录状态，而并没有登出，所以你现在点进去的这个网站可以看到你的账户信息，并操作你的账户信息，这样子就很危险。我们再来了解一个概念，就是本域，什么是本域呢？就是同协议，同域名，同端口就叫本域。从下面的图片我们可以清楚的了解到，什么是本域，以及什么时候跨域。再结合前面WebSocket问题，就明白了为什么不存在跨域问题，因为我们通过WebSocket的API new出的都是当前的单一实例，要访问其他域则需要单独new出实例。

通常我们客户端都是通过http向服务端发送request请求，然后得到response响应，也就是说http是一问一答的模式，这种模式对数据资源、数据加载足够够用，但是需要数据推送的场景就不合适了。我们知道Http2有Server push概念，那只是推资源用的，比如我们浏览器请求了html，服务端可以连带css资源一起推给浏览器，浏览器可以选择接不接收。对即时通讯要求较高的场景就需要用到WebSocket了。所以WebSocket本质上一种计算机网络协议，用来弥补Http协议在持久通信能力上的不足。它的最大特点就是，服务器可以主动向客户端推送信息，客户端也可以主动向服务器发送信息，是真正的双向平等对话，属于服务器推送技术的一种。

以Flutter平台为例，其它平台都大同小异，仅作为参考

在上面的例子当中，当我们调用了WebSocket的connect方法后，究竟会经过什么流程呢？为了直观，我先截我们公司前端ws链接情况，如下：

WebSocket严格意义上和http没什么关系，从上面的流程可以看出，首先是发出了get请求，然后返回101进行了一次协议切换，如下图：

切换的过程是这样的：从上面截图中可以清楚的看到，请求的Request Headers携带有以下值：

前面两个就是升级到Websocket协议的意思，第三个是Cookie，携带的是用户的账号密码以及SessionId等，针对这个属性后面单独展开来说，因为这里不注意就会遇到坑，第三个header是保证安全的一个key，Sec-WebSocket-Version就是版本的意思，根据查看flutter WebSocket部分源码，使用Postman以及结合浏览器发现这个应该是写死的都是13。服务端返回的Response Headers：

上面只是复制了部分Headers，更详细的可以参考上面的截图，我们发现无论是Request Headers还是Response Headers,有重合相同的部分：

Sec-WebSocket-Accept是对请求带过来的Sec-WebSocket-Key值处理后的结果，加入这个header就是为了确定对方一定有WebSocket能力，不然建立了链接，对方一直不回消息，那不就白等了么。Sec-WebSocket-Key经过什么处理得到了Sec-WebSocket-Accept？其实很简单，就是客户端传过来的key，加上一个固定的字符串，经过sha1加密之后转成base64的结果，这个固定的字符串为：

258EAFA5-E914-47DA-95CA-C5AB0DC85B11

如果你不信，可以自己动手实现一下，或者在网上搜下这个字符串:

如果你到这里还不信，我们稍后看看Flutter源码是怎么实现的，你就会真的明白它就是这样。前面提到WebSocket链接先通过get请求，服务端返回状态码101进行协议切换，然后也提到Headers的处理过程，下面我们通过阅读Flutter WebSocket源码证实我们上面分析的是不是正确的。进入connect方法，跳转到io.dart文件

url就是我们要链接的WebSocket url，是必须传的，其它都是配置选项，Headers就是我们上面提到的Request Headers,我在项目中的配置大概是下面这样，可以和后台协商配置。

再看看WebSocket的connect方法中，直接调用了WebSocket实现类_WebSocketImp中的connect方法。

上面的代码很长也很多，但是真的很重要，也很容易理解，接下来逐一分析上面每一行的功能和作用。

最后会把这个nonce，赋值给Sec-WebSocket-key。

在前面提到配置Headers，比如升级协议Upgrade，安全校验的Sec-WebSocket-key等，其实我们只需要配置与服务端协商好的key，其它别的是不用配置的，也就是底层会自动帮我们加上这些信息，前面也提到版本，这里可以看到就是写死的13。 

这里出现了response.statusCode和HttpStatus.switchingProtocols，HttpStatus.switchingProtocols这个值是什么呢，跟进去看发现就是常量101。

看到这里，是不是和我们前面分析的一模一样。还有重要的一点，这里出现了Connection to '$uri' was not upgraded to websocket。也就是我们最开始提到的异常，其实这里太笼统。只要返回的状态码不为101或者接收的connectionHeader为null，都直接抛出了这个头疼的not upgraded to websocket,所以不了解的时候，就像我开头说的根本无从下手，针对此问题在后面我也会分析会出现这个异常的原因。其实看到这里，我们心里或许也知道是什么导致的了。

这里的 sha1.add("$nonce$_webSocketGUID".codeUnits),nonce就是我们上面请求Headers中携带的Sec-WebSocket-key值，然后加上_webSocketGUID,_webSocketGUID就是前面一直提到的固定字符串。

看到这里我们是不是如释重负的感觉，完全和我们分析的一模一样，这里首先进行了长度比较，然后再判断每一个字符是不是相等。

通过上面的异常，比较之前的101状态码，还是可以接受一些，最起码告诉我们Headers有问题，这样我们找问题也就更直接了。

当然从上面的源码中也未发现这个东西。Cookie的概念其实在app中用的很少，至少在我开发过的项目里基本是没用到的，但是在浏览器中很常见。Cookie可以携带用户信息，如下面代码所示。

回到最开始项目中遇到的问题，就是Cookie导致的，由于我最开始不知道要携带这个Cookie导致服务器无法校验通过，也就无法成功返回101状态码，自然就无法成功切换到WebSocket协议了，JSESSIONID的值从哪获取呢，其实也是从Headers获取，一般我们调用登录接口，服务端返回的Response Header中就会携带这个值。

当我们拿到这个值的时候，保存下来，等链接wss的业务的时候取出来赋值给Cookie，就可以了。

通过过上面的分析，我们知道了WebSocket整个链接过程，以及是如何从Http切换到WebSocke协议的，以及分析了出现异常的原因，这里大致总结一下出现异常大概有以下问题导致：

1，服务端WebSocket本身就有问题（可以在postman上调试排查问题）

2，url有问题，不是正常的url

3，Headers问题，最有可能的就是Cookie，出现问题后我们应该立马和后台同事沟通，问清楚他们到底需要什么值，沟通清楚再实现。

至此我们分析了WebSocket的整个链接和切换流程，如果你觉得写的不错，欢迎点个关注，感谢🙏。