本文由阿里云望宸分享，原題“大模型推理主戰(zhàn)場(chǎng)：什么才是通信協(xié)議標(biāo)配？”，下文進(jìn)行了排版優(yōu)化和內(nèi)容修訂。

1、引言

DeepSeek 加速了模型平權(quán)，隨之而來(lái)的是大模型推理需求的激增，大模型性能提升的主戰(zhàn)場(chǎng)從訓(xùn)練轉(zhuǎn)移到了推理。推理并發(fā)的提升，將催生計(jì)算、存儲(chǔ)、網(wǎng)絡(luò)、中間件、數(shù)據(jù)庫(kù)等領(lǐng)域新的工程化需求。

本文將分享 SSE 和 WebSocket 這兩個(gè)AI大模型應(yīng)用的標(biāo)配網(wǎng)絡(luò)通信協(xié)議，一起重新認(rèn)識(shí)下這兩位新時(shí)代里的老朋友。

2、什么是SSE和WebSocket

SSE（Server-Sent Events，服務(wù)器推送事件）：是一種基于 HTTP 的網(wǎng)絡(luò)通信協(xié)議，允許服務(wù)器向客戶(hù)端單向推送實(shí)時(shí)數(shù)據(jù)。戶(hù)端和服務(wù)端之間需要頻繁地傳輸生成的內(nèi)容。支持服務(wù)器可以一邊生成結(jié)果，一邊分塊發(fā)送給客戶(hù)端，這樣用戶(hù)就能逐步看到生成的內(nèi)容，而不是等待服務(wù)端處理完所有內(nèi)容才能看到。

它的主要特點(diǎn)是：

• 1）高效的單向通信：轉(zhuǎn)為服務(wù)端到客戶(hù)端的單向通信所設(shè)計(jì)，完美匹配大模型場(chǎng)景（客戶(hù)端發(fā)送一次請(qǐng)求，服務(wù)端持續(xù)返回流式結(jié)果）；
• 2）低延遲：每次生成一個(gè)邏輯段落或標(biāo)記（token）即可立即推送，避免傳統(tǒng) HTTP 請(qǐng)求-響應(yīng)模式的長(zhǎng)等待；
• 3）輕量協(xié)議：基于HTTP/HTTPS，無(wú)需額外協(xié)議握手（如 WebSocket 的雙向協(xié)商），減少連接開(kāi)銷(xiāo)。

WebSocket：是一種網(wǎng)絡(luò)通信協(xié)議，允許在客戶(hù)端和服務(wù)器之間建立全雙工、持久的連接，實(shí)現(xiàn)實(shí)時(shí)、雙向的數(shù)據(jù)傳輸。不同于 SSE，WebSocket 連接一旦建立，雙方可以隨時(shí)發(fā)送數(shù)據(jù)，實(shí)效性更強(qiáng)，即無(wú)須等待服務(wù)端返回內(nèi)容，客戶(hù)端就能發(fā)起請(qǐng)求，適用于多人在線(xiàn)游戲操作實(shí)時(shí)同步、社交軟件的聊天室、在線(xiàn)文檔多人同時(shí)編輯等。

它的主要特點(diǎn)是：

• 1）全雙工通信：客戶(hù)端和服務(wù)器可以同時(shí)發(fā)送和接收數(shù)據(jù)；
• 2）持久連接：連接建立后保持打開(kāi)狀態(tài)，直到主動(dòng)關(guān)閉；
• 3）低延遲：數(shù)據(jù)可以即時(shí)傳輸，適合實(shí)時(shí)應(yīng)用。

關(guān)于SSE和WebSocket的更詳盡資料可閱讀：

1. 詳解Web端通信方式的演進(jìn)：從Ajax、JSONP 到 SSE、Websocket
2. 網(wǎng)頁(yè)端IM通信技術(shù)快速入門(mén)：短輪詢(xún)、長(zhǎng)輪詢(xún)、SSE、WebSocket
3. 搞懂現(xiàn)代Web端即時(shí)通訊技術(shù)一文就夠：WebSocket、socket.io、SSE

3、傳統(tǒng)Web端網(wǎng)絡(luò)通信協(xié)議是什么

大模型應(yīng)用出現(xiàn)前，互聯(lián)網(wǎng)在線(xiàn)應(yīng)用以 Web 類(lèi)應(yīng)用為主，基于瀏覽器運(yùn)行，通常通過(guò) HTTP/HTTPS 協(xié)議與服務(wù)器通信，例如電商應(yīng)用、新零售/新金融/出行等交易類(lèi)應(yīng)用，教育、傳媒、醫(yī)療等行業(yè)應(yīng)用，以及公共網(wǎng)站、CRM 等企業(yè)內(nèi)部應(yīng)用，適用范圍非常廣泛。

其中，HTTPS 是 HTTP 的安全版本，通過(guò) SSL/TLS 協(xié)議，對(duì)傳輸數(shù)據(jù)進(jìn)行加密保護(hù)，加解密過(guò)程中會(huì)帶來(lái)一些性能損耗。

從 API 管理的視角，看不同類(lèi)型的網(wǎng)絡(luò)通信協(xié)議：

HTTPS 是一種無(wú)狀態(tài)的、應(yīng)用層的協(xié)議，用于在客戶(hù)端（如瀏覽器）和服務(wù)器之間傳輸超文本（如 HTML 文件、圖片、視頻等）。

它具有以下特點(diǎn)：

• 1）基于請(qǐng)求-響應(yīng)模型；
• 2）無(wú)狀態(tài)：每次請(qǐng)求都是獨(dú)立的，服務(wù)器不會(huì)保存客戶(hù)端的狀態(tài)；
• 3）數(shù)據(jù)加密，防止數(shù)據(jù)被竊聽(tīng)或篡改；身份驗(yàn)證，確保客戶(hù)端與正確的服務(wù)器通信；數(shù)據(jù)完整性，防止數(shù)據(jù)在傳輸過(guò)程中被修改。（HTTP 是明文傳輸）

它的優(yōu)勢(shì)是：

• 1）簡(jiǎn)單易用：HTTP 協(xié)議設(shè)計(jì)簡(jiǎn)單，易于實(shí)現(xiàn)和使用；
• 2）廣泛支持：幾乎所有瀏覽器、服務(wù)器和開(kāi)發(fā)框架都支持 HTTP；
• 3）靈活性：支持多種數(shù)據(jù)格式（如 JSON、XML、HTML）和內(nèi)容類(lèi)型；
• 4）無(wú)狀態(tài)：簡(jiǎn)化了服務(wù)器的設(shè)計(jì)，適合分布式系統(tǒng)；

5）安全和合規(guī)性：通過(guò)加密技術(shù)保護(hù)數(shù)據(jù)傳輸，防止竊聽(tīng)和篡改；符合現(xiàn)代網(wǎng)絡(luò)安全標(biāo)準(zhǔn)（如 GDPR、PCI DSS）。

這里我們以 TLS 1.3 為例，通過(guò)一張圖了解下 HTTPS 在客戶(hù)端和服務(wù)端之間的握手過(guò)程。

TLS 1.3 簡(jiǎn)化了以往的握手過(guò)程，性能損耗更小、響應(yīng)更快。關(guān)于TLS1.3的應(yīng)用實(shí)踐可見(jiàn)微信團(tuán)隊(duì)的分享：《微信新一代通信安全解決方案：基于TLS1.3的MMTLS詳解》。

4、為什么傳統(tǒng)Web端網(wǎng)絡(luò)通信協(xié)議不適合大模型

不同類(lèi)型的大模型應(yīng)用，對(duì)網(wǎng)絡(luò)通信的需求不盡相同，但幾乎都離不開(kāi)以下需求。

具體就是：

• 1）實(shí)時(shí)對(duì)話(huà)：用戶(hù)與模型進(jìn)行連續(xù)交互，模型需要即時(shí)響應(yīng)。例如通義千問(wèn)，HIgress 官網(wǎng)的答疑機(jī)器人，都是需要依據(jù)客戶(hù)問(wèn)題，即時(shí)做出響應(yīng)；
• 2）流式輸出：大模型生成內(nèi)容時(shí)，逐字或逐句返回結(jié)果，而不是一次性返回。但是釘釘、微信等應(yīng)用，兩個(gè)人相互對(duì)話(huà)時(shí)，采用的就不是流式輸出了，文字等內(nèi)容都是一次性返回的；
• 3）長(zhǎng)時(shí)任務(wù)處理：大模型可能需要較長(zhǎng)時(shí)間處理復(fù)雜任務(wù)，同時(shí)需要向客戶(hù)端反饋進(jìn)度，尤其是處理長(zhǎng)文本、以及圖片、視頻等多模態(tài)內(nèi)容；這是因?yàn)橐蕾?lài)大模型計(jì)算的響應(yīng)，要比依賴(lài)人為寫(xiě)入的業(yè)務(wù)邏輯的響應(yīng)，消耗的資源多的多，這也是為什么大模型的計(jì)算要依靠 GPU，而非 CPU，CPU 在并行計(jì)算和大規(guī)模矩陣計(jì)算上遠(yuǎn)不如 GPU；
• 4）多輪交互：用戶(hù)與模型之間需要多次往返交互，保持上下文。這是大模型應(yīng)用保障用戶(hù)體驗(yàn)的必備能力。

這些場(chǎng)景對(duì)實(shí)時(shí)性和雙向通信有較高要求，沿用 Web 類(lèi)應(yīng)用的主流通信協(xié)議 - HTTPS，將會(huì)存在很多問(wèn)題。

以下是主要的問(wèn)題：

• 1）僅支持單向通信，即請(qǐng)求-響應(yīng)模型，必須是客戶(hù)端發(fā)起時(shí)，服務(wù)端才能做出響應(yīng)，無(wú)法進(jìn)行雙向通信，導(dǎo)致無(wú)法支持流式輸出，無(wú)法處理長(zhǎng)時(shí)任務(wù)；
• 2）客戶(hù)端每次發(fā)出請(qǐng)求都需要重新建立連接，延遲增加，導(dǎo)致無(wú)法支持實(shí)時(shí)對(duì)話(huà)；
• 3）HTTPS 是一種無(wú)狀態(tài)的通信協(xié)議，每次請(qǐng)求都是獨(dú)立的，服務(wù)端不會(huì)保存客戶(hù)端的狀態(tài)，即便客戶(hù)端可以在每次請(qǐng)求時(shí)重復(fù)發(fā)送上下文信息，但會(huì)帶來(lái)額外的網(wǎng)絡(luò)開(kāi)銷(xiāo)，導(dǎo)致無(wú)法高效的支持多輪交互場(chǎng)景。

雖然 HTTPS 已經(jīng)發(fā)展到 HTTPS/2 和 HTTPS/3，在性能上了有了提升，但是面對(duì)大模型應(yīng)用這類(lèi)對(duì)實(shí)時(shí)性要求較高的場(chǎng)景，依舊不夠原生，并未成為這類(lèi)場(chǎng)景下的主流通信協(xié)議。

5、SSE和WebSocket更適合支持大模型應(yīng)用

5.1 SSE的通信原理

1）客戶(hù)端發(fā)起 SSE 連接：

• 1）客戶(hù)端通過(guò) JavaScript 的 EventSource API 向服務(wù)器發(fā)起 HTTP 請(qǐng)求；
• 2）請(qǐng)求頭中包含 Accept: text/event-stream，表明客戶(hù)端支持 SSE 協(xié)議；
• 3）示例代碼。

const eventSource = new EventSource('https://example.com/sse-endpoint');

2）服務(wù)器返回 HTTP 響應(yīng)：

服務(wù)器響應(yīng)頭中必須包含以下字段：

• 1）Content-Type: text/event-stream：表明響應(yīng)內(nèi)容為 SSE 數(shù)據(jù)流；
• 2）Cache-Control: no-cache：禁用緩存，確保數(shù)據(jù)實(shí)時(shí)更新；
• 3）Connection: keep-alive：保持長(zhǎng)連接。

示例響應(yīng)頭：

HTTP/1.1 200 OK

Content-Type: text/event-stream

Cache-Control: no-cache

Connection: keep-alive

3）服務(wù)器推送數(shù)據(jù)流：　　

• 1）服務(wù)器通過(guò) HTTP 長(zhǎng)連接持續(xù)推送數(shù)據(jù)，每條消息以 data: 開(kāi)頭，以?xún)蓚€(gè)換行符 \n\n 結(jié)束；
• 2）示例數(shù)據(jù)流。

data: {"message": "Hello"}

 

data: {"message": "World"}

4）客戶(hù)端處理數(shù)據(jù)：

• 1）客戶(hù)端通過(guò) EventSource 的 onmessage 事件監(jiān)聽(tīng)服務(wù)器推送的數(shù)據(jù)；
• 2）示例代碼。

eventSource.onmessage = (event) => {

    console.log('Received data:', event.data);

};

5）連接關(guān)閉或錯(cuò)誤處理：

• 1）如果連接中斷（如網(wǎng)絡(luò)問(wèn)題），客戶(hù)端會(huì)自動(dòng)嘗試重新連接；
• 2）服務(wù)器可以通過(guò)發(fā)送 retry: 字段指定重連時(shí)間（毫秒）；
• 3）示例重連設(shè)置。

retry: 5000

我們可以通過(guò)下方方式驗(yàn)證大模型 APP 使用的網(wǎng)絡(luò)通信協(xié)議。

調(diào)用 API 并檢查響應(yīng)頭：使用 stream=True 參數(shù)請(qǐng)求流式響應(yīng)，通過(guò)開(kāi)發(fā)者工具或 curl 查看返回的 Content-Type，若為 text/event-stream，則明確為 SSE。

示例命令：

curl -X POST "https://api.deepseek.com/v1/chat/completions" \

  -H "Authorization: Bearer YOUR_KEY" \

  -H "Content-Type: application/json" \

  -d '{"model":"deepseek-chat", "messages":[{"role":"user","content":"Hello"}], "stream":true}' \

  -v # 查看詳細(xì)響應(yīng)頭

預(yù)期輸出：

< HTTP/1.1 200 OK

< Content-Type: text/event-stream

< Transfer-Encoding: chunked

數(shù)據(jù)格式驗(yàn)證：流式響應(yīng)的數(shù)據(jù)體格式為 data: {...}\n\n，符合 SSE 規(guī)范。

示例響應(yīng)片段：

data: {"id":"123","choices":[{"delta":{"content":"Hi"}}]}

data: [DONE]

5.2 WebSocket的通信原理

1）客戶(hù)端發(fā)起 WebSocket 握手請(qǐng)求：

客戶(hù)端通過(guò) HTTP 請(qǐng)求發(fā)起 WebSocket 握手，請(qǐng)求頭中包含以下字段：

• 1）Upgrade: websocket：表明客戶(hù)端希望升級(jí)到 WebSocket 協(xié)議；
• 2）Connection: Upgrade：表明客戶(hù)端希望升級(jí)連接；
• 3）Sec-WebSocket-Key：隨機(jī)生成的 Base64 編碼字符串，用于握手驗(yàn)證。

示例請(qǐng)求頭：

GET /ws-endpoint HTTP/1.1

Host: example.com

Upgrade: websocket

Connection: Upgrade

Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==

Sec-WebSocket-Version: 13

2）服務(wù)器返回 WebSocket 握手響應(yīng)：

服務(wù)器驗(yàn)證客戶(hù)端的握手請(qǐng)求，并返回 HTTP 101 狀態(tài)碼（Switching Protocols），表示協(xié)議升級(jí)成功。

響應(yīng)頭中包含以下字段：

• 1）Upgrade: websocket：確認(rèn)協(xié)議升級(jí)；
• 2）Connection: Upgrade：確認(rèn)連接升級(jí)；
• 3）Sec-WebSocket-Accept：基于客戶(hù)端的 Sec-WebSocket-Key 計(jì)算的值，用于驗(yàn)證握手。

示例響應(yīng)頭：

HTTP/1.1 101 Switching Protocols

Upgrade: websocket

Connection: Upgrade

Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

3）WebSocket 連接建立：

• 1）握手成功后，HTTP 連接升級(jí)為 WebSocket 連接，客戶(hù)端和服務(wù)器可以通過(guò) WebSocket 協(xié)議進(jìn)行雙向通信；
• 2）連接基于 TCP，支持全雙工通信。

4）數(shù)據(jù)傳輸：

• 1）客戶(hù)端和服務(wù)器通過(guò) WebSocket 協(xié)議發(fā)送和接收數(shù)據(jù)幀（Frame）。數(shù)據(jù)幀可以是文本或二進(jìn)制格式；
• 2）文本幀：用于傳輸 JSON、字符串等文本數(shù)據(jù)；

{"message": "Hello"}

• 3）二進(jìn)制幀：用于傳輸圖片、音頻、視頻等二進(jìn)制數(shù)據(jù)。

[0x01, 0x02, 0x03]

5）連接關(guān)閉：

• 1）客戶(hù)端或服務(wù)器可以主動(dòng)發(fā)送關(guān)閉幀（Close Frame）來(lái)終止連接；
• 2）關(guān)閉幀包含關(guān)閉狀態(tài)碼和原因（可選）；
• 3）示例關(guān)閉幀。

   Close Frame:

- Code: 1000 (Normal Closure)

- Reason: "Connection closed by client"

例如 OpenAI 的 Realtime API （適用于對(duì)實(shí)時(shí)性要求更高的場(chǎng)景，客戶(hù)端在不需要等待服務(wù)端發(fā)送完內(nèi)容后就能發(fā)起請(qǐng)求），推薦基于 WebSocket 協(xié)議，以支持低延遲的多模態(tài)交互，包括文本和音頻輸入輸出。

具有以下特征 ：

• 1）基于事件的通信：Realtime API 通過(guò) WebSocket 進(jìn)行有狀態(tài)的事件驅(qū)動(dòng)交互，客戶(hù)端和服務(wù)器之間通過(guò)發(fā)送和接收 JSON 格式的事件進(jìn)行通信135；
• 2）持久連接：WebSocket 協(xié)議使得 API 能夠保持一個(gè)持續(xù)的雙向連接，允許即時(shí)的數(shù)據(jù)流動(dòng)，這對(duì)于實(shí)時(shí)對(duì)話(huà)和交互至關(guān)重要；
• 3）多模態(tài)支持：該 API 不僅支持文本輸入，還可以處理音頻數(shù)據(jù)，提供更加豐富和自然的用戶(hù)體驗(yàn)。

可見(jiàn)：SSE 和 WebSocket 均能較好的支持大模型應(yīng)用的實(shí)時(shí)性需求，前者更加輕量化，后者因?yàn)槭请p向通信在實(shí)時(shí)性要求更高的場(chǎng)景更有優(yōu)勢(shì)。這里我們通過(guò)一張表來(lái)比對(duì)下各個(gè)協(xié)議的特點(diǎn)。

總結(jié)來(lái)看：HTTP/1.1 適合傳統(tǒng)網(wǎng)頁(yè)和簡(jiǎn)單 API 請(qǐng)求，但性能較低。HTTP/2 適合現(xiàn)代高性能網(wǎng)頁(yè)，解決了 HTTP/1.1 的隊(duì)頭阻塞問(wèn)題，SSE 適合服務(wù)器主動(dòng)推送實(shí)時(shí)數(shù)據(jù)的場(chǎng)景，如一問(wèn)一答的大模型應(yīng)用，WebSocket 適合需要雙向?qū)崟r(shí)通信的場(chǎng)景如在線(xiàn)游戲、多人協(xié)作、實(shí)時(shí)性要求更高的大模型應(yīng)用場(chǎng)景（隨時(shí)可以打斷生成過(guò)程進(jìn)行追問(wèn)的場(chǎng)景，例如大模型實(shí)時(shí)辯論平臺(tái)）。

此外：WebRTC 也廣泛應(yīng)用于大模型應(yīng)用場(chǎng)景，例如，當(dāng)調(diào)用 Realtime API 時(shí)，OpenAI 官方推薦使用 WebSocket 或 WebRTC。

6、實(shí)時(shí)通信協(xié)議的技術(shù)挑戰(zhàn)和應(yīng)對(duì)方案

6.1 概述

雖然 SSE 和 WebSocket 的特點(diǎn)，天然適合處理游戲、社交、大模型應(yīng)用等有處理實(shí)時(shí)通信的場(chǎng)景。但是用戶(hù)體量擴(kuò)大后，依舊會(huì)遇到一些工程化上的技術(shù)挑戰(zhàn)。

如果把數(shù)據(jù)比作貨物，HTTPS 是小型渡輪，適合短距離、少量的貨物運(yùn)輸，SSE 和 WebSocket 則是大型貨輪，適合長(zhǎng)距離、大批量的貨物運(yùn)輸。此時(shí)，網(wǎng)關(guān)是負(fù)責(zé)連接陸地和水域的中轉(zhuǎn)大廳，控制船只的秩序和方向（路由、負(fù)載均衡），對(duì)貨船進(jìn)行安全檢查（身份驗(yàn)證），還設(shè)置了應(yīng)急和備用通道（流量管控、高可用保障）等。由于大型貨輪不間斷（長(zhǎng)連接）的進(jìn)入中轉(zhuǎn)大廳，且單次訪(fǎng)問(wèn)數(shù)據(jù)量大、訪(fǎng)問(wèn)用戶(hù)多，對(duì)扮演管理 SSE 和WebSocket 的連接建立和維護(hù)的網(wǎng)關(guān)，提出了更高的要求。

以下羅列了具體的挑戰(zhàn)和網(wǎng)關(guān)層的應(yīng)對(duì)方案，方案部分僅供參考，工程上的問(wèn)題沒(méi)有唯一的答案，應(yīng)結(jié)合業(yè)務(wù)和技術(shù)團(tuán)隊(duì)的實(shí)際情況，選擇適合自己的方案。

6.2 軟件變更和服務(wù)擴(kuò)縮容導(dǎo)致的穩(wěn)定性風(fēng)險(xiǎn)

技術(shù)挑戰(zhàn)：

1）越是高速發(fā)展的應(yīng)用，越是新興應(yīng)用，軟件變更頻率越高，網(wǎng)關(guān)升級(jí)是軟件變更的重要組成部分。但是，網(wǎng)關(guān)的升級(jí)通常涉及服務(wù)重啟、配置變更或網(wǎng)絡(luò)切換等作用，這會(huì)直接影響 SSE 和 WebSocket 連接的穩(wěn)定性；

2）服務(wù)擴(kuò)容過(guò)程中（增加實(shí)例），現(xiàn)有的 SSE 和 WebSocket 可能無(wú)法連接到新實(shí)例，服務(wù)縮容過(guò)程中（減少實(shí)例），現(xiàn)有的 SSE 和 WebSocket 可能會(huì)因服務(wù)的下線(xiàn)而被強(qiáng)制關(guān)閉，這些對(duì)實(shí)時(shí)性要求比較高的應(yīng)用，例如游戲、大模型實(shí)時(shí)聊天，都會(huì)帶來(lái)用戶(hù)體驗(yàn)的下降。

應(yīng)對(duì)方案：

• 1）無(wú)損上下線(xiàn)能力：該能力在微服務(wù)變更時(shí)，應(yīng)用比較廣泛，可以有效降低版本發(fā)布和擴(kuò)縮容的穩(wěn)定性風(fēng)險(xiǎn)。常見(jiàn)于云產(chǎn)品的商業(yè)能力。例如，阿里云的云原生 API 網(wǎng)關(guān)提供了面向 HTTPS/WebSocket 的微服務(wù)治理能力；
• 2）客戶(hù)端重連機(jī)制：在客戶(hù)端設(shè)計(jì)自動(dòng)重連機(jī)制，減少中斷影響，和無(wú)損上下線(xiàn)一樣，使用心跳包檢測(cè)連接狀態(tài)，一旦中斷自動(dòng)重連，此外，還可以在服務(wù)器端記錄已發(fā)送的數(shù)據(jù)，實(shí)現(xiàn)斷點(diǎn)續(xù)傳；
• 3）協(xié)議切換機(jī)制：在 SSE 和 WebSocket 不可用時(shí)，回退到長(zhǎng)輪詢(xún)（Long Polling），不過(guò)這個(gè)依賴(lài)于網(wǎng)關(guān)本身是否支持這些長(zhǎng)連接。

6.3 大帶寬導(dǎo)致內(nèi)存快速上漲的穩(wěn)定性風(fēng)險(xiǎn)和帶寬成本

技術(shù)挑戰(zhàn)：大模型經(jīng)常需要處理長(zhǎng)文本、以及圖片、視頻等多模態(tài)內(nèi)容，對(duì)帶寬的消耗遠(yuǎn)超 Web 類(lèi)應(yīng)用，導(dǎo)致內(nèi)存快速上漲，同時(shí)帶來(lái)更高的帶寬成本。

應(yīng)對(duì)方案：選擇支持流式處理的網(wǎng)關(guān)（如 Higress），將生成的內(nèi)容分塊傳輸，減少單次傳輸?shù)臄?shù)據(jù)量。同時(shí)，采用壓縮算法（如 Gzip），減少數(shù)據(jù)傳輸量，控制帶寬成本。阿里云云原生 API 網(wǎng)關(guān)即將上線(xiàn)軟硬一體化的內(nèi)容壓縮方案，帶寬傳輸成本可下降20%+。

6.4 高延時(shí)導(dǎo)致防范惡意攻擊的資源成本增高

技術(shù)挑戰(zhàn)：相比 Web 類(lèi)應(yīng)用，大模型應(yīng)用推理時(shí)消耗的計(jì)算資源更多。例如發(fā)生 DDoS 攻擊時(shí)， Web 類(lèi)應(yīng)用應(yīng)對(duì)攻擊會(huì)消耗1:1的計(jì)算資源，大模型應(yīng)用則會(huì)消耗1:x(x 遠(yuǎn)大于1) 的后端資源，導(dǎo)致大模型應(yīng)在面對(duì)惡意攻擊時(shí)，更加脆弱。

應(yīng)對(duì)方案：在網(wǎng)關(guān)層部署立體的防護(hù)措施，包括認(rèn)證鑒權(quán)、安全防護(hù)、流量管控等。

具體就是：

• 1）認(rèn)證鑒權(quán)：對(duì)來(lái)自客戶(hù)端的請(qǐng)求，進(jìn)行合規(guī)性的校驗(yàn)。基于具體的業(yè)務(wù)需求，選擇第三方的認(rèn)證協(xié)議，從我們服務(wù)的客戶(hù)經(jīng)驗(yàn)上看，選擇 OAuth2、JWT 的居多；
• 2）安全防護(hù)：通過(guò) IP 限制，或者基于URL、請(qǐng)求頭等特征，設(shè)計(jì)安全防護(hù)措施；
• 3）流量管控：基于 URL 參數(shù)、HTTP 請(qǐng)求頭、客戶(hù)端 IP 地址、消費(fèi)者名稱(chēng)或 Cookie 中的 Key，進(jìn)行 token 級(jí)別的限流。

7、未來(lái)趨勢(shì)

大模型應(yīng)用除了帶來(lái)了 SSE 和 WebSocket 的使用頻率越來(lái)越高，也在助推 API First 的理念。

以往：在線(xiàn)應(yīng)用都是通過(guò) Service 來(lái)對(duì)外暴露提供能力，但大模型應(yīng)用將通過(guò) API 對(duì)外提供服務(wù)能力，除了基模類(lèi)廠(chǎng)商已經(jīng)通過(guò)提供 API 來(lái)服務(wù)廣大開(kāi)發(fā)者群體，大模型應(yīng)用類(lèi)廠(chǎng)商也開(kāi)始提供 API 服務(wù)。

例如：近日 Perplexity 將面向企業(yè)客戶(hù)和開(kāi)發(fā)人員推出其 AI 搜索的 API 服務(wù)——基礎(chǔ)版 Sonar 和高級(jí)版 Sonar Pro，以允許企業(yè)和開(kāi)發(fā)人員把 Perplexity 的生成式 AI 搜索工具構(gòu)建到自己的應(yīng)用中去。

這樣做的好處是：Perplexity 可以因此讓自己的 AI 搜索無(wú)處不在，而不只局限在它的應(yīng)用與網(wǎng)站里。一個(gè)案例是其客戶(hù) Zoom：Sonar 允許 Zoom 的 AI 聊天機(jī)器人根據(jù)帶有引文的網(wǎng)絡(luò)搜索提供實(shí)時(shí)答案，而不需要 Zoom 的視頻用戶(hù)離開(kāi)聊天窗口。隨著國(guó)內(nèi)大模型應(yīng)用的成熟，相信這一趨勢(shì)會(huì)越加明顯。

8、參考資料

[1] 深入淺出，全面理解HTTP協(xié)議

[2] HTTP協(xié)議必知必會(huì)的一些知識(shí)

[3] 一分鐘理解 HTTPS 到底解決了什么問(wèn)題

[4] 如果這樣來(lái)理解HTTPS原理，一篇就夠了

[5] 為什么要用HTTPS？深入淺出，探密短連接的安全性

[6] 新手入門(mén)貼：史上最全Web端即時(shí)通訊技術(shù)原理詳解

[7] Web端即時(shí)通訊技術(shù)盤(pán)點(diǎn)：短輪詢(xún)、Comet、Websocket、SSE

[8] SSE技術(shù)詳解：一種全新的HTML5服務(wù)器推送事件技術(shù)

[9] Comet技術(shù)詳解：基于HTTP長(zhǎng)連接的Web端實(shí)時(shí)通信技術(shù)

[10] WebSocket從入門(mén)到精通，半小時(shí)就夠！

[11] 刨根問(wèn)底WebSocket與Socket的關(guān)系

[12] 使用WebSocket和SSE技術(shù)實(shí)現(xiàn)Web端消息推送

[13] 詳解Web端通信方式的演進(jìn)：從Ajax、JSONP 到 SSE、Websocket

[14] 網(wǎng)頁(yè)端IM通信技術(shù)快速入門(mén)：短輪詢(xún)、長(zhǎng)輪詢(xún)、SSE、WebSocket

[15] 搞懂現(xiàn)代Web端即時(shí)通訊技術(shù)一文就夠：WebSocket、socket.io、SSE

[16] 淺談網(wǎng)頁(yè)端IM技術(shù)及相關(guān)測(cè)試方法實(shí)踐（包括WebSocket性能測(cè)試）

（本文已同步發(fā)布于：http://www.52im.net/thread-4797-1-1.html）