为什么Cypress在cy.request中最后使用websocket进行通信？

笔者在上次的研究中发现，cy.request命令在最后实际上是通过websocket协议发起请求。同事Jerry的文章中梳理了WebSocket的基本原理和与HTTP协议的区别：关于 WebSocket 和 HTTP 区别的思考以及一个最简单的 WebSocket 的客户端和服务器实现 。
上次的研究详情见讨论：cy.visit 命令什么时候执行的？
在这当中Jerry提出了三个问题，从这三个问题出发，进一步理解Cypress访问目标网址的过程。

问题1

为什么 Cypress 的 visit 方法选择了 WebSocket 作为与目标网站的通信技术呢？为什么不直接走 HTTP 协议，比如用 ES6 原生支持的 fetch 去访问目标网站呢？

问题2

那么问题又来了，在我们 cy.visit(‘http://xxx.com’) 的代码里，如果说最终 Cypress 通过 WebSocket 协议向 http://xxx.com 发送数据报，但是 http://xxx.com 不支持 WebSocket 怎么办？就像本文前一部分介绍的例子一样，WebSocket 需要客户端和服务器端同时支持才行。
那么会不会 cy.visit 和 visit 参数里指定的 webSite 之间，还存在着一个中间层？

关于问题1与问题2的讨论，笔者想放在一起进行。

笔者最开始通过debug cypress源码，发现cy.request最后实际使用wss协议发起请求后，就有这样一个疑问，cypress启动的浏览器里面中，查看地址栏的导航以及devTools中网络里面的各种连接，毫无疑问访问目标网页都是通过HTTP/HTTPS协议进行的，浏览器也并不能直接通过wss协议来访问目标网页（向目标网站服务器发起请求，获取网页文件后在浏览器中进行渲染）。

其它的UI自动测试框架如selenium，通过JSON Wire控制浏览器执行相应操作（request目标网页），这里的cy.request只是发起了一个wss请求，那它是怎么控制浏览器发起的HTTP请求呢（对应到人的操作就是在地址栏输入目标网页地址，然后按下回车）？

下图是《前端自动化测试框架Cypress从入门到精通》一图中作者绘制的Cypress架构图，根据作者的分析，测试首次加载Cypress时， Cypress的Server端（nodejs进程）先把自己托管在本地的随机端口上（类似于http://localhost:65874/__/ ），识别出测试中第一个cy.visit命令后，修改localhost:65874以匹配被测网站的Origin。任务发往被Cypress控制的浏览器之外的HTTP请求和相应都是通过Cypress生成的，通过Proxy转发Cypress生成的请求。

结合目前笔者debug cypress源码的发现，猜测如下：在cypress测试代码中，cy.request发起wss请求与cypress nodejs进程进行通信，然后cypress通过proxy将HTTP请求转发到目标服务器。

需要进一步研究的问题：

1. cy.request发起的wss请求里面携带的数据是不是就包含了一个实际的HTTP请求，然后经由Proxy的处理就能直接转发到目标服务器？
2. 如果不是，Cypress生成HTTP请求是发生在cypress控制的浏览器内还是发生在cypress的nodejs进程内？

要解决上述两个问题，需要对cypress的nodejs进程进行debug，但cypress在运行过程中会下载一个可执行文件，笔者担心这个可执行文件就是cypress的nodejs中所执行的程序，这样就无法简单地去找到proxy的实现细节。

问题3

WebSocket Connection，HTTP Connection，TCP connection，这三者的区别和联系是什么？

这是笔者找到的一篇博客，很详细的对比了Websocket，HTTP和TCP三种协议的联系和区别：全面理解WebSocket与Socket、TCP、HTTP的关系及区别。

原理性的东西不再复述，简单来说，Websocket Connetction和HTTP connection都是建立在TCPconnection的基础上的，这两者是应用层协议，他们通过TCP这个传输层协议来传输数据。

而Websocket connection的建立开始于一个HTTP请求，借用HTTP协议完成一部分握手，利用HTTP的upgrade首部将当前的HTTP请求升级为Websocket协议。

两个连接最大的区别是Websocket能做到持久连接，而且能做到服务器主动向客户端推送信息。