全民AI時代，大模型客戶端和服務端的實時通信到底用什么協(xié)議？

Posted on 2025-03-27 15:14 Jack Jiang 閱讀(64) 評論(0) 編輯收藏

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

1、引言

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

本文將分享 SSE 和 WebSocket 這兩個AI大模型應用的標配網(wǎng)絡通信協(xié)議，一起重新認識下這兩位新時代里的老朋友。

技術交流：

- 移動端IM開發(fā)入門文章：《新手入門一篇就夠：從零開發(fā)移動端IM》

- 開源IM框架源碼：https://github.com/JackJiang2011/MobileIMSDK（備用地址點此）

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

2、什么是SSE和WebSocket

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

它的主要特點是：

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

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

它的主要特點是：

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

關于SSE和WebSocket的更詳盡資料可閱讀：

詳解Web端通信方式的演進：從Ajax、JSONP 到 SSE、Websocket
網(wǎng)頁端IM通信技術快速入門：短輪詢、長輪詢、SSE、WebSocket
搞懂現(xiàn)代Web端即時通訊技術一文就夠：WebSocket、socket.io、SSE

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

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

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

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

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

它具有以下特點：

1）基于請求-響應模型；
2）無狀態(tài)：每次請求都是獨立的，服務器不會保存客戶端的狀態(tài)；
3）數(shù)據(jù)加密，防止數(shù)據(jù)被竊聽或篡改；身份驗證，確?？蛻舳伺c正確的服務器通信；數(shù)據(jù)完整性，防止數(shù)據(jù)在傳輸過程中被修改。（HTTP 是明文傳輸）

它的優(yōu)勢是：

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

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

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

TLS 1.3 簡化了以往的握手過程，性能損耗更小、響應更快。關于TLS1.3的應用實踐可見微信團隊的分享：《微信新一代通信安全解決方案：基于TLS1.3的MMTLS詳解》。

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

不同類型的大模型應用，對網(wǎng)絡通信的需求不盡相同，但幾乎都離不開以下需求。

具體就是：

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

這些場景對實時性和雙向通信有較高要求，沿用 Web 類應用的主流通信協(xié)議 - HTTPS，將會存在很多問題。

以下是主要的問題：

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

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

5、SSE和WebSocket更適合支持大模型應用

5.1 SSE的通信原理

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

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

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

2）服務器返回 HTTP 響應：

服務器響應頭中必須包含以下字段：

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

示例響應頭：

HTTP/1.1 200 OK
Content-Type: text/event-stream
Cache-Control: no-cache
Connection: keep-alive

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

1）服務器通過 HTTP 長連接持續(xù)推送數(shù)據(jù)，每條消息以 data: 開頭，以兩個換行符 \n\n 結束；
2）示例數(shù)據(jù)流。

data: {"message": "Hello"}

data: {"message": "World"}

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

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

eventSource.onmessage = (event) => {
console.log('Received data:', event.data);
};

5）連接關閉或錯誤處理：

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

retry: 5000

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

調用 API 并檢查響應頭：使用 stream=True 參數(shù)請求流式響應，通過開發(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 # 查看詳細響應頭

預期輸出：

< HTTP/1.1 200 OK
< Content-Type: text/event-stream
< Transfer-Encoding: chunked

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

示例響應片段：

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

5.2 WebSocket的通信原理

1）客戶端發(fā)起 WebSocket 握手請求：

客戶端通過 HTTP 請求發(fā)起 WebSocket 握手，請求頭中包含以下字段：

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

示例請求頭：

GET /ws-endpoint HTTP/1.1
Host: example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13

2）服務器返回 WebSocket 握手響應：

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

響應頭中包含以下字段：

1）Upgrade: websocket：確認協(xié)議升級；
2）Connection: Upgrade：確認連接升級；
3）Sec-WebSocket-Accept：基于客戶端的 Sec-WebSocket-Key 計算的值，用于驗證握手。

示例響應頭：

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

3）WebSocket 連接建立：

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

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

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

{"message": "Hello"}

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

[0x01, 0x02, 0x03]

5）連接關閉：

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

Close Frame:
- Code: 1000 (Normal Closure)
- Reason: "Connection closed by client"

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

具有以下特征：

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

可見：SSE 和 WebSocket 均能較好的支持大模型應用的實時性需求，前者更加輕量化，后者因為是雙向通信在實時性要求更高的場景更有優(yōu)勢。這里我們通過一張表來比對下各個協(xié)議的特點。

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

此外：WebRTC 也廣泛應用于大模型應用場景，例如，當調用 Realtime API 時，OpenAI 官方推薦使用 WebSocket 或 WebRTC。

6、實時通信協(xié)議的技術挑戰(zhàn)和應對方案

6.1 概述

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

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

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

6.2 軟件變更和服務擴縮容導致的穩(wěn)定性風險

技術挑戰(zhàn)：

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

2）服務擴容過程中（增加實例），現(xiàn)有的 SSE 和 WebSocket 可能無法連接到新實例，服務縮容過程中（減少實例），現(xiàn)有的 SSE 和 WebSocket 可能會因服務的下線而被強制關閉，這些對實時性要求比較高的應用，例如游戲、大模型實時聊天，都會帶來用戶體驗的下降。

應對方案：

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

6.3 大帶寬導致內存快速上漲的穩(wěn)定性風險和帶寬成本

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

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

6.4 高延時導致防范惡意攻擊的資源成本增高

技術挑戰(zhàn)：相比 Web 類應用，大模型應用推理時消耗的計算資源更多。例如發(fā)生 DDoS 攻擊時， Web 類應用應對攻擊會消耗1:1的計算資源，大模型應用則會消耗1:x(x 遠大于1) 的后端資源，導致大模型應在面對惡意攻擊時，更加脆弱。

應對方案：在網(wǎng)關層部署立體的防護措施，包括認證鑒權、安全防護、流量管控等。

具體就是：

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

7、未來趨勢

大模型應用除了帶來了 SSE 和 WebSocket 的使用頻率越來越高，也在助推 API First 的理念。

以往：在線應用都是通過 Service 來對外暴露提供能力，但大模型應用將通過 API 對外提供服務能力，除了基模類廠商已經(jīng)通過提供 API 來服務廣大開發(fā)者群體，大模型應用類廠商也開始提供 API 服務。

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

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