筆者之前與一位同事研究了 Cypress 的 visit 方法，其原始碼實現最終是呼叫了 WebSocket 向 visit 引數裡指定的 website 通行並獲取資料，見下圖變數 `ev.data` 的值。

![](https://img-blog.csdnimg.cn/img_convert/14fd239c691a1d4e64bbcd4700fdf753.png)

我這位同事的研究成果，透過 Joplin 筆記記錄如下[如下](https://0mpudovluc.joplinusercontent.com/shares/hEd3EIZx4qxfFfCG5s2i9R)。

於是筆者心裡有一個疑問，為什麼 Cypress 的 visit 方法選擇了 WebSocket 作為與目標網站的通訊技術呢？為什麼不直接走 HTTP 協議，比如用 ES6 原生支援的 fetch 去訪問目標網站呢？

要回答這個問題，我們先要理解到底什麼是 WebSocket，以及它與 HTTP 相比較的優缺點。

誠然，WebSocket 可以在使用者的瀏覽器和伺服器之間開啟互動式通訊會話，瀏覽器可以向伺服器傳送訊息並接收事件驅動的響應，而無需透過輪詢伺服器的方式以獲得響應。

![](https://img-blog.csdnimg.cn/img_convert/68b6ca88b30bed189f3af3cc0422b094.png)

WebSocket 基於 TCP 連線，在伺服器和瀏覽器間提供了全雙工通訊功能，即伺服器可以主動推送資料到瀏覽器端，而這在 HTTP 協議中是不可能實現的，HTTP 協議只支援瀏覽器到伺服器端的 Request - Response 方式，即瀏覽器客戶端如果想查詢伺服器端是否有最新的事件發生，則只能採取低效的輪詢方式進行。

舉個例子，當使用者向伺服器傳送請求時，該請求以 HTTP 或 HTTPS 的形式傳送，伺服器收到請求後向客戶端傳送響應，每個請求都與相應的響應相關聯，傳送響應後連線關閉，每個 HTTP 或 HTTPS 請求每次都會建立與伺服器的新連線，並且在獲得響應後，連線會自行終止。

筆者注：HTTP 請求頭部的 `Connection: keep-alive` 欄位，`可以實現連線重用的需求嗎？`

![](https://img-blog.csdnimg.cn/img_convert/610825fcec00f21660ddd27d0b7a8c32.png)

當啟用 Keep-Alive 時，客戶端和伺服器同意為後續請求或響應保持連線開啟。

預設情況下，HTTP 連線在資料事務結束時關閉。 這意味著客戶端建立一個新連線來請求頁面的每個檔案，伺服器在傳送資料後關閉這些 TCP 連線。

但是，如果伺服器需要同時響應多個 HTTP 請求併為每個新的 TCP 連線提供一個檔案，則站點頁面的載入時間將會增加。 這可能會導致糟糕的使用者體驗。

為了克服這個問題，網站所有者需要啟用 Keep-Alive 標頭來限制新連線的數量。

透過開啟 Keep-Alive 連線標頭，客戶端可以透過單個 TCP 連線下載所有內容，例如 JavaScript、CSS、影像和影片，而不是為每個檔案傳送不同的請求。

這是一張演示 Keep-Alive 工作原理的圖片：

![](https://img-blog.csdnimg.cn/img_convert/43e8f7de5d0d29c94d72d5a19019fdbc.png)

# 問題：啟用 Keep-Alive 頭部欄位後，重用的是 HTTP 連線，還是 TCP 連線？

WebSocket 並不是將 HTTP 的設計完全推翻重建，而是在 HTTP 的基礎上增添了一些邏輯來，管理客戶端和伺服器端的流。這些流的內容也是 HTTP 請求和響應，保留了舊語義，只是編碼和打包方式不同。

![](https://img-blog.csdnimg.cn/img_convert/045fb19d228ef3359bc7480b7461a2a9.png)

瞭解了理論知識後，我們動手開發一套最簡單的 WebSocket 伺服器端和客戶端實現。

## WebSocket 伺服器端實現

```javascript
var app = require('express')();
var server = require('http').Server(app);
var io = require('socket.io')(server);
var defaultPort = 3001;

var port = process.env.PORT || defaultPort;
var i = 0;

console.log("Server is listening on port: " + defaultPort);
server.listen(port);

io.on('connection', function (socket) {
  console.log("connect comming from client: " + socket.id);
  
  socket.emit('messages_jerry', { hello: 'world greeting from Server!' });
  
  socket.on('messages', function (data) {
    console.log("data received from Client:" + JSON.stringify(data,2,2));
  });
});
```
程式碼實現包含了4個關鍵點：

1. 伺服器監聽在預設的 3001 埠上。

2. 一旦 WebSocket 客戶端有傳送到 3001 埠上的連線請求時，程式碼第 12 行的 on 監聽函式觸發，監聽的事件名稱為 `connection`，然後在監聽函式的實現體裡，列印出客戶端連線的 id 值。
 
3. 伺服器端接收了客戶端的連結後，向客戶端透過第 15 行的 emit 方法，傳送一個 `messages_jerry` 的事件，以及一個 JSON 物件作為事件負載。

4. 第 17 行伺服器端監聽在 `messages` 事件上的監聽函式觸發時，說明接收到了從客戶端傳送過來的事件，在監聽函式里列印出客戶端傳遞過來的資料。

![](https://img-blog.csdnimg.cn/img_convert/764b88b9eacf6cd4edea14310d07052e.png)

## WebSocket 客戶端實現

```javascript
// #!/usr/bin/env node
const io = require('socket.io-client');
var socket = io.connect('http://localhost:3001');

socket.on('messages_jerry', function (data) {
    console.log("data sent from Server:" + JSON.stringify(data,2,2));
    socket.emit('messages', { my: 'data sent from Client' });
  });

socket.on('connect', function (socket2) {
    console.log('Connection with Server established!');
        socket.emit('messages', 'Client has established connection with Server');
});
```

程式碼的關鍵點：

1. 客戶端透過 connect 方法向 WebSocket 伺服器發起連線請求

2. 連線成功建立後，客戶端第 10 行的 on 監聽函式觸發，該函式監聽在 `connect` 事件上，會在 Web Socket 連線成功建立後自動觸發。

3. 客戶端在第 12 行呼叫 emit 向伺服器傳送一個 messages 事件。

4. 客戶端監聽在 `messages_jerry` 的監聽函式觸發，說明伺服器端有資料到達。使用第 6 行的 console.log 語句列印出這個資料。

5. 在第 7 行程式碼，客戶端呼叫 emit，向伺服器端傳送一個請求，通知伺服器自己已經收到了伺服器傳送過來的資料。

![](https://img-blog.csdnimg.cn/img_convert/66aadaa6670f51518ca0b84eca23a87a.png)

使用命令列 `node wsServer.js` 啟動伺服器端，看到如下輸出：

![](https://img-blog.csdnimg.cn/img_convert/81815e5b06a9d5c87d9cbcd26e131327.png)

新開一個命令列視窗，使用 `node wsClient.js` 啟動客戶端，能看到客戶端列印出的成功建立連線，以及從伺服器端傳送過來的資料：

![](https://img-blog.csdnimg.cn/img_convert/93aecaa9e8998f41b39437f1158e93b8.png)

切換回伺服器端，紅色高亮的內容，就是客戶端與伺服器端建立連線之後，伺服器端新列印出的資料：

![](https://img-blog.csdnimg.cn/img_convert/58fcb5ef2b6fdc20bb02045f6c48e963.png)
回到本文開頭丟擲的問題：

### 問題1
> 為什麼 Cypress 的 visit 方法選擇了 WebSocket 作為與目標網站的通訊技術呢？為什麼不直接走 HTTP 協議，比如用 ES6 原生支援的 fetch 去訪問目標網站呢？

筆者猜測，是不是因為 Cypress 裡某些 API，比如 `cy.XXX` 需要利用到 WebSocket 這種全雙工通訊的特性才能夠充分發揮作用？

### 問題2
那麼問題又來了，在我們 `cy.visit('http://xxx.com')` 的程式碼裡，如果說最終 Cypress 透過 WebSocket 協議向 `http://xxx.com` 傳送資料包，但是 `http://xxx.com` 不支援 WebSocket 怎麼辦？就像本文前一部分介紹的例子一樣，WebSocket 需要客戶端和伺服器端同時支援才行。

那麼會不會 cy.visit 和 visit 引數裡指定的 webSite 之間，還存在著一箇中間層？

![在這裡插入圖片描述](https://img-blog.csdnimg.cn/dc4bd1ef8f93435bac13374fdad8a83e.png)
### 問題3
WebSocket Connection，HTTP Connection，TCP connection，這三者的區別和聯絡是什麼？

# 參考資料

- [Difference between HTTP and WebSocket (HTTP 2.0 )](https://developerinsider.co/difference-between-http-and-http-2-0-websocket)

關於 WebSocket 和 HTTP 區別的思考以及一個最簡單的 WebSocket 的客戶端和伺服器實現

相關文章