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

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

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

1、引言

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

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

技術交流：

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

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

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

2、什么是SSE和WebSocket

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

它的主要特點是：

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

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

它的主要特點是：

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

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

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

3、傳統Web端網絡通信協議是什么

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

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

從 API 管理的視角，看不同類型的網絡通信協議：

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

它具有以下特點：

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

它的優勢是：

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

5）安全和合規性：通過加密技術保護數據傳輸，防止竊聽和篡改；符合現代網絡安全標準（如 GDPR、PCI DSS）。

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

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

4、為什么傳統Web端網絡通信協議不適合大模型

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

具體就是：

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

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

以下是主要的問題：

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

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

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

5.1 SSE的通信原理

1）客戶端發起 SSE 連接：

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

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

2）服務器返回 HTTP 響應：

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

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

示例響應頭：

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

3）服務器推送數據流：　　

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

data: {"message": "Hello"}

data: {"message": "World"}

4）客戶端處理數據：

1）客戶端通過 EventSource 的 onmessage 事件監聽服務器推送的數據；
2）示例代碼。

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

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

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

retry: 5000

我們可以通過下方方式驗證大模型 APP 使用的網絡通信協議。

調用 API 并檢查響應頭：使用 stream=True 參數請求流式響應，通過開發者工具或 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

數據格式驗證：流式響應的數據體格式為 data: {...}\n\n，符合 SSE 規范。

示例響應片段：

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

5.2 WebSocket的通信原理

1）客戶端發起 WebSocket 握手請求：

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

1）Upgrade: websocket：表明客戶端希望升級到 WebSocket 協議；
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 狀態碼（Switching Protocols），表示協議升級成功。

響應頭中包含以下字段：

1）Upgrade: websocket：確認協議升級；
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 協議進行雙向通信；
2）連接基于 TCP，支持全雙工通信。

4）數據傳輸：

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

{"message": "Hello"}

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

[0x01, 0x02, 0x03]

5）連接關閉：

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

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

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

具有以下特征：

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

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

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

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

6、實時通信協議的技術挑戰和應對方案

6.1 概述

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

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

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

6.2 軟件變更和服務擴縮容導致的穩定性風險

技術挑戰：

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

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

應對方案：

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

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

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

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

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

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

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

具體就是：

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

7、未來趨勢

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

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

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

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