前言

最近，公司有一個(gè)AI項(xiàng)目，要做一個(gè)文檔問(wèn)答的AI產(chǎn)品。前端部分呢，還是「友好借鑒」ChatGPT。別問(wèn)為什么，問(wèn)就是要站在巨人的肩膀上進(jìn)行「帶有中國(guó)特色」的創(chuàng)新。而后端是接入我們團(tuán)隊(duì)的模型，我咨詢過(guò)模型團(tuán)隊(duì)，也是基于開(kāi)源模型做參數(shù)的微調(diào)，這個(gè)魔幻的世界真讓人欲罷不能。這就是大概的業(yè)務(wù)背景。

針對(duì)前端部分，其實(shí)沒(méi)啥可聊的，就是接入模型返回的數(shù)據(jù)然后進(jìn)行展示處理。大家以為這就是一個(gè)簡(jiǎn)單到令人發(fā)指的功能時(shí)。有一個(gè)點(diǎn)卻映入眼簾，如何才能實(shí)現(xiàn)類似ChatGPT結(jié)果展示效果（逐步輸出結(jié)果，類似打字效果）。也就是在結(jié)果返回的時(shí)候，如何做打字效果。

此外，還有一個(gè)大背景就是，由于需求是可能要上傳多個(gè)文件，并且模型那邊的操作可能對(duì)文檔解析有一定的難度。所以，在客戶端發(fā)起請(qǐng)求時(shí)，可能投喂給模型的物料有點(diǎn)多，返回的結(jié)果的時(shí)間也會(huì)很長(zhǎng)。也就是如果處理不當(dāng)?shù)脑?，在結(jié)果沒(méi)返回之前或者一股腦把結(jié)果處理完再返回的話，前端會(huì)有一段很長(zhǎng)的等待時(shí)間。

從上面的需求點(diǎn)和解決方案，我們不難看出，其實(shí)結(jié)果的展示(打字效果)不是一個(gè)難點(diǎn)，我們可以借助簡(jiǎn)單的庫(kù)或者手搓一個(gè)打字效果都是可以的，而是數(shù)據(jù)的獲取制約我們應(yīng)用響應(yīng)。

我們又可以按照數(shù)據(jù)的發(fā)起方是誰(shuí)(客戶端/服務(wù)端)

1. 基于最原始的數(shù)據(jù)獲取方式，客戶端發(fā)起請(qǐng)求，服務(wù)端接入模型數(shù)據(jù)并返回，然后前端一股腦把所以結(jié)果都接入。
2. 數(shù)據(jù)的發(fā)起方是服務(wù)端，然后在有合適的數(shù)據(jù)時(shí)，就將其發(fā)布給客戶端，前端接收到數(shù)據(jù)后就進(jìn)行結(jié)果的顯示。此處我們可以按照流式將數(shù)據(jù)返回

所以，這又引起了另外一個(gè)問(wèn)題，前后端數(shù)據(jù)交互我們應(yīng)該采用何種方式。其實(shí)針對(duì)，后端主動(dòng)發(fā)起數(shù)據(jù)的方式我們有很多方案

• 長(zhǎng)輪詢（Long-Polling）
• WebSockets
• 服務(wù)器發(fā)送事件（Server-Sent Events，SSE）
• WebRTC
• WebTransport

那我們到底用哪種方式亦或者說(shuō)它們都是個(gè)啥，都有啥優(yōu)缺點(diǎn)。所以，今天我們來(lái)用一篇文章來(lái)講講它們直接的區(qū)別和聯(lián)系。

好了，天不早了，干點(diǎn)正事哇。

我們能所學(xué)到的知識(shí)點(diǎn)

1. 長(zhǎng)輪詢（Long-Polling）
2. WebSockets
3. 服務(wù)器發(fā)送事件(SSE)
4. WebTransport
5. WebRTC
6. 技術(shù)的限制
7. 性能比較
8. 適用場(chǎng)景

1. 長(zhǎng)輪詢（Long-Polling）

長(zhǎng)輪詢可以在瀏覽器上通過(guò) HTTP 啟用一種服務(wù)器-客戶端消息傳遞方法。該技術(shù)通過(guò)普通的 XHR 請(qǐng)求模擬了服務(wù)器推送通信。與傳統(tǒng)的輪詢不同，其中客戶端會(huì)在「固定的時(shí)間間隔內(nèi)重復(fù)向服務(wù)器請(qǐng)求數(shù)據(jù)」，長(zhǎng)輪詢建立了一條連接到服務(wù)器的連接，該連接保持打開(kāi)狀態(tài)，直到有新數(shù)據(jù)可用為止。一旦服務(wù)器有了新信息，就會(huì)將響應(yīng)發(fā)送給客戶端，并關(guān)閉連接。

在接收到服務(wù)器的響應(yīng)后，客戶端立即發(fā)起新的請(qǐng)求，這個(gè)過(guò)程會(huì)重復(fù)進(jìn)行。這種方法允許「更即時(shí)地更新數(shù)據(jù)，并減少不必要的網(wǎng)絡(luò)流量和服務(wù)器負(fù)載」。然而，它仍然可能引入通信延遲，并且不如其他實(shí)時(shí)技術(shù)（如 WebSockets）高效。

function longPoll() {
  fetch('http://front789.com/poll')
    .then(response => response.json())
    .then(data => {
        console.log("接收到的數(shù)據(jù):", data);
        longPoll(); // 立即發(fā)起新的長(zhǎng)輪詢請(qǐng)求
    })
    .catch(error => {
        /**
        * 在正常情況下可能會(huì)出現(xiàn)錯(cuò)誤，
        * 當(dāng)連接超時(shí)或客戶端離線時(shí)。
        * 出現(xiàn)錯(cuò)誤時(shí)，我們會(huì)在一段延遲后重新啟動(dòng)輪詢。
        */
        setTimeout(longPoll, 10000);
    });
}
longPoll(); // 初始化長(zhǎng)輪詢

長(zhǎng)輪詢解決了在網(wǎng)絡(luò)平臺(tái)上構(gòu)建雙向應(yīng)用程序的問(wèn)題，也就是我們經(jīng)常用的模式- 「客戶端發(fā)出請(qǐng)求，服務(wù)器響應(yīng)」。這是通過(guò)顛覆請(qǐng)求-響應(yīng)模型來(lái)實(shí)現(xiàn)的：

1. 客戶端向服務(wù)器發(fā)送 GET 請(qǐng)求：與傳統(tǒng)的 HTTP 請(qǐng)求不同，我們可以將其視為開(kāi)放式的。它不是請(qǐng)求特定的響應(yīng)，而是在準(zhǔn)備好時(shí)請(qǐng)求任何響應(yīng)。
2. 請(qǐng)求時(shí)間設(shè)置：HTTP 超時(shí)可以使用 Keep-Alive 頭進(jìn)行調(diào)整。

長(zhǎng)輪詢利用此功能，通過(guò)設(shè)置非常長(zhǎng)或無(wú)限期的超時(shí)時(shí)間，使請(qǐng)求保持打開(kāi)狀態(tài)，即使服務(wù)器沒(méi)有立即響應(yīng)。

3. 服務(wù)器響應(yīng)：當(dāng)服務(wù)器有要發(fā)送的內(nèi)容時(shí)，它會(huì)使用響應(yīng)關(guān)閉連接。

返回的數(shù)據(jù)可以是新的聊天消息、體育比分或突發(fā)新聞等。

4. 客戶端發(fā)送新的 GET 請(qǐng)求，循環(huán)重新開(kāi)始。

圖片

2. WebSockets

WebSockets[1] 是一種實(shí)時(shí)技術(shù)，可通過(guò)持久的單套接字(socket)連接在客戶端和服務(wù)器之間實(shí)現(xiàn)「雙向全雙工通信」。WebSockets 相對(duì)于傳統(tǒng)的 HTTP，代表了一個(gè)重大進(jìn)步，因?yàn)橐坏┙⑦B接，雙方就可以「獨(dú)立發(fā)送數(shù)據(jù)」，這使其非常適合需要低延遲和高頻更新的場(chǎng)景。

WebSocket 技術(shù)由兩個(gè)核心構(gòu)建塊組成：

• WebSocket協(xié)議:WebSocket是建立在TCP協(xié)議之上的一種「應(yīng)用層協(xié)議」。該協(xié)議旨在允許客戶端和服務(wù)器「實(shí)時(shí)通信」，從而在 Web 應(yīng)用程序中實(shí)現(xiàn)高效且響應(yīng)迅速的數(shù)據(jù)傳輸。
• WebSocket API:WebSocket API 是一個(gè)編程接口，用于創(chuàng)建 WebSocket 連接并管理 Web 應(yīng)用程序中客戶端和服務(wù)器之間的數(shù)據(jù)交換。幾乎所有現(xiàn)代瀏覽器都支持 WebSocket API

圖片

如何工作的

概括地說(shuō)，使用 WebSockets 涉及三個(gè)主要步驟：

1. 打開(kāi) WebSocket 連接

建立 WebSocket 連接的過(guò)程稱為握手，由客戶端和服務(wù)器之間的 HTTP 請(qǐng)求/響應(yīng)交換組成。

2. 通過(guò) WebSockets 傳輸數(shù)據(jù)

成功打開(kāi)握手后，客戶端和服務(wù)器可以通過(guò)持久 WebSocket 連接交換消息（幀）。WebSocket 消息可能包含字符串（純文本）或二進(jìn)制數(shù)據(jù)。

3. 關(guān)閉 WebSocket 連接。

一旦持久的 WebSocket 連接達(dá)到其目的，它就可以終止;

客戶端和服務(wù)器都可以通過(guò)發(fā)送關(guān)閉消息來(lái)啟動(dòng)關(guān)閉握手。

圖片

// 創(chuàng)建 `WebSocket` 連接
const socket = new WebSocket("ws://localhost:7899");

// 打開(kāi)鏈接，并發(fā)送信息
socket.addEventListener("open", (event) => {
  socket.send("Hello Front789!");
});

// 監(jiān)聽(tīng)來(lái)自服務(wù)端的數(shù)據(jù)
socket.addEventListener("message", (event) => {
  console.log("來(lái)自服務(wù)端的數(shù)據(jù)", event.data);
});
// 關(guān)閉鏈接
socket.onclose = function(e) {
   console.log("關(guān)閉鏈接", e);
};

雖然 WebSocket API 的基礎(chǔ)用法很容易，但在生產(chǎn)環(huán)境中卻相當(dāng)復(fù)雜。一個(gè) socket 可能會(huì)斷開(kāi)連接，必須相應(yīng)地重新創(chuàng)建。特別是檢測(cè)連接是否仍然可用或不可用可能會(huì)非常棘手。通常，我們會(huì)添加一個(gè) ping-and-pong[2] 心跳以確保打開(kāi)的連接不會(huì)關(guān)閉。我們可以借助類似像 Socket.IO[3] 這樣的庫(kù)來(lái)處理重連的情況，需要時(shí)提供了以「長(zhǎng)輪詢」為回退方案。

想了解更多關(guān)于WebSocket可以參考The WebSocket API and protocol explained[4]

3. 服務(wù)器發(fā)送事件(SSE)

服務(wù)器發(fā)送事件（Server-Sent Events，SSE）提供了一種標(biāo)準(zhǔn)方法，通過(guò) HTTP 將服務(wù)器數(shù)據(jù)推送到客戶端。與 WebSockets 不同，SSE 專門設(shè)計(jì)用于「服務(wù)器到客戶端的單向通信」，使其非常適用于實(shí)時(shí)信息的更新或者那些在不向服務(wù)器發(fā)送數(shù)據(jù)的情況下實(shí)時(shí)更新客戶端的情況。

我們可以將服務(wù)器發(fā)送事件視為單個(gè) HTTP 請(qǐng)求，其中后端不會(huì)立即發(fā)送整個(gè)主體，而是保持連接打開(kāi)，并通過(guò)每次發(fā)送事件時(shí)發(fā)送單個(gè)行來(lái)逐步傳輸答復(fù)。

圖片

SSE是一個(gè)由兩個(gè)組件組成的標(biāo)準(zhǔn)：

1. 瀏覽器中的 EventSource 接口，允許客戶端訂閱事件:它提供了一種通過(guò)抽象較低級(jí)別的連接和消息處理來(lái)訂閱事件流的便捷方法。
2. 事件流協(xié)議:描述服務(wù)器發(fā)送的事件必須遵循的標(biāo)準(zhǔn)純文本格式，以便 EventSource 客戶端理解和傳播它們

在瀏覽器的客戶端上，我們可以使用服務(wù)器端生成事件腳本的 URL 初始化一個(gè) EventSource[5] 實(shí)例。

// 連接到服務(wù)器端事件流
const evtSource = new EventSource("https://front789.com/events");

// 處理通用消息事件
evtSource.onmessage = event => {
    if(event.data.trim() !== 'undefined'){
    const newData = event.data;
    // 數(shù)據(jù)追加
    setResponse((prevResponse) => prevResponse.concat(newData));
  } else{
    // 當(dāng)從服務(wù)端接收到值為`undefined`的數(shù)據(jù)時(shí)，關(guān)閉鏈接
    setTempPrompt(''); 
    eventSource.close();
  }
};

與 WebSockets 不同，EventSource 在連接丟失時(shí)會(huì)自動(dòng)重新連接。

在服務(wù)器端，我們的腳本必須將 Content-Type 標(biāo)頭設(shè)置為 text/event-stream，并根據(jù) SSE 規(guī)范[6]格式化每條消息。這包括指定事件類型、數(shù)據(jù)有效負(fù)載和可選字段，如事件 ID。

以下是使用Node.js Express處理SSE的示例：

import express from 'express';
const app = express();
const PORT = process.env.PORT || 7890;

const headers = {
    'Content-Type': 'text/event-stream',
    'Connection': 'keep-alive',
    'Cache-Control': 'no-cache'
}

app.get('/events', (req, res) => {
    res.writeHead(200, headers);

    const sendEvent = (data) => {
        // 所有數(shù)據(jù)都必須以'data:'開(kāi)頭
        const formattedData = `data: ${JSON.stringify(data)}\n\n`;
        res.write(formattedData);
    };

    // 每?jī)擅氚l(fā)送一個(gè)事件
    const intervalId = setInterval(() => {
        const message = {
            time: new Date().toTimeString(),
            message: '服務(wù)端產(chǎn)生的數(shù)據(jù)',
        };
        sendEvent(message);
    }, 2000);

    // 關(guān)閉輪詢
    req.on('close', () => {
        clearInterval(intervalId);
        res.end();
    });
});
app.listen(PORT, () => console.log(`Server running on http://localhost:${PORT}`));

文章最開(kāi)始，我們不是說(shuō)想實(shí)現(xiàn)實(shí)時(shí)響應(yīng)后端返回并且逐字顯示聊天機(jī)器人回復(fù)，我們其實(shí)就可以使用SSE的方案。而ChatGPT也是使用這個(gè)機(jī)制實(shí)現(xiàn)的。

4. WebTransport

WebTransport[7] 是一個(gè)專為 Web 客戶端和服務(wù)器之間進(jìn)行高效、低延遲通信而設(shè)計(jì)的前沿 API。它利用了 HTTP/3 QUIC 協(xié)議[8]，可以實(shí)現(xiàn)以可靠和不可靠的方式實(shí)現(xiàn)多個(gè)流的數(shù)據(jù)傳輸功能，甚至允許數(shù)據(jù)無(wú)序發(fā)送。這使得 WebTransport 成為需要高性能網(wǎng)絡(luò)的應(yīng)用程序的強(qiáng)大工具，如實(shí)時(shí)游戲、直播和協(xié)作平臺(tái)。但是，值得注意的是，WebTransport 目前是一個(gè)工作草案，尚未被廣泛采用。

圖片

截至目前（2024 年 5 月），WebTransport 仍處于工作草案階段[9]，并沒(méi)有得到廣泛支持。

圖片

目前還不能在 Safari 瀏覽器中使用 WebTransport，而且 Node.js 也沒(méi)有原生支持。這限制了其在不同平臺(tái)和環(huán)境中的可用性。

5. WebRTC

網(wǎng)頁(yè)實(shí)時(shí)通信(Web Real-time Communication,WebRTC)[10]是一個(gè)增強(qiáng)網(wǎng)頁(yè)瀏覽模式。它允許瀏覽器通過(guò)安全訪問(wèn)輸入設(shè)備（如網(wǎng)絡(luò)攝像頭和麥克風(fēng)），以「點(diǎn)對(duì)點(diǎn)的方式直接與其他瀏覽器交換實(shí)時(shí)媒體數(shù)據(jù)」。

WebRTC 既是 API 又是協(xié)議。

• WebRTC 協(xié)議是一組規(guī)則，供兩個(gè) WebRTC 代理協(xié)商雙向安全實(shí)時(shí)通信。
• WebRTC API 允許開(kāi)發(fā)人員使用 WebRTC 協(xié)議。WebRTC API 僅針對(duì) JavaScript。

傳統(tǒng)的網(wǎng)頁(yè)架構(gòu)是基于客戶端-服務(wù)器模型，客戶端發(fā)送HTTP請(qǐng)求到服務(wù)器并獲得包含所請(qǐng)求信息的響應(yīng)。與此相對(duì)，WebRTC允許N個(gè)實(shí)體之間交換數(shù)據(jù)。在這種交換中，實(shí)體彼此直接通信，而無(wú)需中間服務(wù)器。

WebRTC內(nèi)置于HTML 5，因此我們不需要第三方軟件或插件即可使用它，我們可以通過(guò)WebRTC API在瀏覽器中訪問(wèn)它。它支持瀏覽器之間的音頻、視頻和數(shù)據(jù)流交換的點(diǎn)對(duì)點(diǎn)連接。WebRTC 設(shè)計(jì)用于通過(guò) NAT 和防火墻工作，利用諸如 ICE、STUN 和 TURN 等協(xié)議來(lái)建立對(duì)等之間的連接。

雖然 WebRTC 是為客戶端-客戶端交互設(shè)計(jì)的，但也可以利用它進(jìn)行服務(wù)器-客戶端通信，其中「服務(wù)器只是模擬成一個(gè)客戶端」。這種方法只適用于特定的用例,問(wèn)題在于，要使 WebRTC 正常工作，我們?nèi)匀恍枰粋€(gè)服務(wù)器，這個(gè)服務(wù)器會(huì)再次通過(guò) WebSockets、SSE 或 WebTransport 運(yùn)行。這就背離了使用 WebRTC 作為這些技術(shù)的替代方案的初衷。

6. 技術(shù)的限制

雙向發(fā)送數(shù)據(jù)

只有 WebSockets 和 WebTransport 是「雙向全雙工通信」，這樣我們就可以在同一個(gè)連接上接收服務(wù)器數(shù)據(jù)并發(fā)送客戶端數(shù)據(jù)。

雖然理論上使用長(zhǎng)輪詢也是可能的，但并不建議，因?yàn)橄颥F(xiàn)有的長(zhǎng)輪詢連接發(fā)送“新”數(shù)據(jù)實(shí)際上還是需要額外的 HTTP 請(qǐng)求。因此，我們可以通過(guò)額外的 HTTP 請(qǐng)求直接將數(shù)據(jù)從客戶端發(fā)送到服務(wù)器，而不會(huì)中斷長(zhǎng)輪詢連接。

SSE不支持向服務(wù)器發(fā)送任何附加數(shù)據(jù)。我們只能進(jìn)行初始請(qǐng)求，即使在原生的 EventSource API 中，默認(rèn)情況下也無(wú)法在 HTTP 主體中發(fā)送類似 POST 的數(shù)據(jù)。相反，我們必須將所有數(shù)據(jù)放在 URL 參數(shù)中，這被認(rèn)為是一種不安全的做法，因?yàn)閼{據(jù)可能會(huì)泄漏到服務(wù)器日志、代理和緩存中。

每個(gè)域的 6 個(gè)請(qǐng)求限制

大多數(shù)現(xiàn)代瀏覽器允許「每個(gè)域最多六個(gè)連接」這限制了服務(wù)器-客戶端消息傳遞方法的可用性。這六個(gè)連接的限制甚至在瀏覽器選項(xiàng)卡之間共享，因此當(dāng)我們?cè)诙鄠€(gè)選項(xiàng)卡中打開(kāi)相同的頁(yè)面時(shí)，它們必須彼此共享六個(gè)連接池。

雖然這個(gè)策略可以防止D-DOS 攻擊，但當(dāng)多個(gè)連接是為了處理合法的通信時(shí)，它可能會(huì)造成很大的問(wèn)題。為了解決這個(gè)限制，我們必須使用 HTTP/2 或 HTTP/3，其中瀏覽器為每個(gè)域只會(huì)打開(kāi)一個(gè)連接，然后使用「多路復(fù)用」來(lái)通過(guò)單個(gè)連接傳輸所有數(shù)據(jù)。雖然這樣可以給我們幾乎無(wú)限量的并行連接，但有一個(gè) SETTINGS_MAX_CONCURRENT_STREAMS[11] 設(shè)置，它限制了實(shí)際的連接數(shù)量。對(duì)于大多數(shù)配置，默認(rèn)值為 100 個(gè)并發(fā)流。

在移動(dòng)應(yīng)用程序中不保持連接

在 Android 和 iOS 等操作系統(tǒng)上運(yùn)行的移動(dòng)應(yīng)用程序中，保持打開(kāi)連接（例如 WebSockets 和其他連接）會(huì)帶來(lái)很大的挑戰(zhàn)。移動(dòng)操作系統(tǒng)被設(shè)計(jì)為「在一段時(shí)間的不活動(dòng)后自動(dòng)將應(yīng)用程序移至后臺(tái)，從而有效關(guān)閉任何打開(kāi)的連接」。這種行為是操作系統(tǒng)資源管理策略的一部分，旨在節(jié)省電池并優(yōu)化性能。因此，我們通常依賴于移動(dòng)推送通知作為一種高效可靠的方法，以將數(shù)據(jù)從服務(wù)器發(fā)送到客戶端。推送通知允許服務(wù)器提醒應(yīng)用程序有新數(shù)據(jù)到達(dá)，促使執(zhí)行某個(gè)操作或更新，而無(wú)需保持持續(xù)的打開(kāi)連接。

7. 性能比較

對(duì)于一些我們平時(shí)可能會(huì)用到的技術(shù)例如WebSockets、SSE、長(zhǎng)輪詢和 WebTransport 我們可以從延遲、吞吐量、服務(wù)器負(fù)載和在不同條件下的可伸縮性的角度來(lái)比較。

延遲

• WebSockets：由于其通過(guò)單個(gè)持久連接進(jìn)行全雙工通信，提供了最低的延遲。適用于實(shí)時(shí)應(yīng)用程序，其中立即數(shù)據(jù)交換至關(guān)重要。
• SSE：也提供了低延遲的服務(wù)器到客戶端通信，但不能直接發(fā)送消息回服務(wù)器，需要額外的 HTTP 請(qǐng)求。
• 長(zhǎng)輪詢：由于依賴于為每個(gè)數(shù)據(jù)傳輸「建立新的 HTTP 連接」，因此產(chǎn)生較高的延遲，使其對(duì)實(shí)時(shí)更新不太有效。此外，當(dāng)服務(wù)器希望在客戶端仍在打開(kāi)新連接的過(guò)程中發(fā)送事件時(shí)，可能會(huì)出現(xiàn)延遲顯著較大的情況。
• WebTransport：承諾提供類似于 WebSockets 的低延遲，同時(shí)利用 HTTP/3 協(xié)議進(jìn)行更高效的多路復(fù)用和擁塞控制。

吞吐量

• WebSockets：由于其持久連接，能夠?qū)崿F(xiàn)高吞吐量，但當(dāng)客戶端無(wú)法處理數(shù)據(jù)時(shí)，吞吐量可能會(huì)受到反壓的影響，反壓[12]是指客戶端無(wú)法處理服務(wù)器發(fā)送的數(shù)據(jù)速度。
• SSE：對(duì)于向客戶端廣播消息而言，效率高于 WebSockets，開(kāi)銷較小，因此在單向的服務(wù)器到客戶端通信中可能會(huì)實(shí)現(xiàn)更高的吞吐量。
• 長(zhǎng)輪詢：由于頻繁打開(kāi)和關(guān)閉連接的開(kāi)銷較大，通常提供較低的吞吐量，這會(huì)「消耗更多的服務(wù)器資源」。
• WebTransport：支持單個(gè)連接內(nèi)的雙向和單向數(shù)據(jù)流的高吞吐量，性能優(yōu)于需要多個(gè)流的場(chǎng)景下的 WebSockets。

可伸縮性和服務(wù)器負(fù)載

• WebSockets：維護(hù)大量 WebSocket 連接可能會(huì)顯著增加服務(wù)器負(fù)載，可能影響具有許多用戶的應(yīng)用程序的可伸縮性。
• SSE：對(duì)于主要需要來(lái)自服務(wù)器到客戶端的更新的場(chǎng)景，更具可伸縮性，因?yàn)榕c WebSockets 相比，它使用的連接開(kāi)銷更小，因?yàn)樗褂玫氖浅Ｒ?guī)的 HTTP 請(qǐng)求，而不是像 WebSockets 那樣需要運(yùn)行協(xié)議更新的請(qǐng)求。
• 長(zhǎng)輪詢：由于頻繁建立連接產(chǎn)生的高服務(wù)器負(fù)載，所以是最不可伸縮的，通常僅適用于作為「后備機(jī)制」。
• WebTransport：設(shè)計(jì)為高度可伸縮，受益于 HTTP/3 在處理連接和流時(shí)的高效性，與 WebSockets 和 SSE 相比，可能減少服務(wù)器負(fù)載。

8. 適用場(chǎng)景

在服務(wù)器-客戶端通信技術(shù)的領(lǐng)域中，每種技術(shù)都有其獨(dú)特的優(yōu)勢(shì)和適用用例。SSE是最簡(jiǎn)單的實(shí)現(xiàn)選項(xiàng)，利用與傳統(tǒng) Web 請(qǐng)求相同的 HTTP/S 協(xié)議，因此可以規(guī)避企業(yè)防火墻限制和其他可能出現(xiàn)的技術(shù)問(wèn)題。它們很容易集成到 Node.js 和其他服務(wù)器框架中，因此非常適合需要頻繁服務(wù)器到客戶端更新的應(yīng)用程序，如新聞源、股票行情和實(shí)時(shí)事件流。

另一方面，WebSockets 在需要持續(xù)的雙向通信的場(chǎng)景中表現(xiàn)出色。它們支持連續(xù)互動(dòng)的能力，使其成為瀏覽器游戲、聊天應(yīng)用程序和實(shí)時(shí)體育更新的首選。

然而，WebTransport 雖然潛力巨大，但面臨著采用挑戰(zhàn)。它在包括 Node.js 在內(nèi)的服務(wù)器框架中得到的支持不廣泛，并且與 Safari 不兼容。此外，它對(duì) HTTP/3 的依賴進(jìn)一步限制了其即時(shí)適用性，因?yàn)樵S多 Web 服務(wù)器（如 nginx）只有實(shí)驗(yàn)性的 HTTP/3 支持。雖然在支持可靠和不可靠數(shù)據(jù)傳輸?shù)奈磥?lái)應(yīng)用程序中有所希望，但在大多數(shù)用例中，WebTransport 還不是一個(gè)可行的選擇。

長(zhǎng)輪詢?cè)?jīng)是一種常見(jiàn)的技術(shù)，但由于其效率低下和頻繁建立新的 HTTP 連接的高開(kāi)銷，現(xiàn)在已經(jīng)大大過(guò)時(shí)。雖然它可以作為沒(méi)有對(duì) WebSockets 或 SSE 進(jìn)行支持的環(huán)境的后備方案，但由于存在顯著的性能限制，通常不建議使用。