本文由阿里云望宸分享，原題“大模型推理主戰(zhàn)場(chǎng)：什么才是通信協(xié)議標(biāo)配？”，下文進(jìn)行了排版優(yōu)化和內(nèi)容修訂。
1、引言
DeepSeek 加速了模型平權(quán)，隨之而來的是大模型推理需求的激增，大模型性能提升的主戰(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í)代里的老朋友。
技術(shù)交流：
2、什么是SSE和WebSocket
SSE（Server-Sent Events，服務(wù)器推送事件）：是一種基于 HTTP 的網(wǎng)絡(luò)通信協(xié)議，允許服務(wù)器向客戶端單向推送實(shí)時(shí)數(shù)據(jù)。戶端和服務(wù)端之間需要頻繁地傳輸生成的內(nèi)容。支持服務(wù)器可以一邊生成結(jié)果，一邊分塊發(fā)送給客戶端，這樣用戶就能逐步看到生成的內(nèi)容，而不是等待服務(wù)端處理完所有內(nèi)容才能看到。
它的主要特點(diǎn)是：
- 1）高效的單向通信：轉(zhuǎn)為服務(wù)端到客戶端的單向通信所設(shè)計(jì)，完美匹配大模型場(chǎng)景（客戶端發(fā)送一次請(qǐng)求，服務(wù)端持續(xù)返回流式結(jié)果）；
- 2）低延遲：每次生成一個(gè)邏輯段落或標(biāo)記（token）即可立即推送，避免傳統(tǒng) HTTP 請(qǐng)求-響應(yīng)模式的長(zhǎng)等待；
- 3）輕量協(xié)議：基于HTTP/HTTPS，無需額外協(xié)議握手（如 WebSocket 的雙向協(xié)商），減少連接開銷。
WebSocket：是一種網(wǎng)絡(luò)通信協(xié)議，允許在客戶端和服務(wù)器之間建立全雙工、持久的連接，實(shí)現(xiàn)實(shí)時(shí)、雙向的數(shù)據(jù)傳輸。不同于 SSE，WebSocket 連接一旦建立，雙方可以隨時(shí)發(fā)送數(shù)據(jù)，實(shí)效性更強(qiáng)，即無須等待服務(wù)端返回內(nèi)容，客戶端就能發(fā)起請(qǐng)求，適用于多人在線游戲操作實(shí)時(shí)同步、社交軟件的聊天室、在線文檔多人同時(shí)編輯等。
它的主要特點(diǎn)是：
- 1）全雙工通信：客戶端和服務(wù)器可以同時(shí)發(fā)送和接收數(shù)據(jù)；
- 2）持久連接：連接建立后保持打開狀態(tài)，直到主動(dòng)關(guān)閉；
- 3）低延遲：數(shù)據(jù)可以即時(shí)傳輸，適合實(shí)時(shí)應(yīng)用。
關(guān)于SSE和WebSocket的更詳盡資料可閱讀：
- 詳解Web端通信方式的演進(jìn)：從Ajax、JSONP 到 SSE、Websocket
- 網(wǎng)頁端IM通信技術(shù)快速入門：短輪詢、長(zhǎng)輪詢、SSE、WebSocket
- 搞懂現(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)在線應(yīng)用以 Web 類應(yīng)用為主，基于瀏覽器運(yùn)行，通常通過 HTTP/HTTPS 協(xié)議與服務(wù)器通信，例如電商應(yīng)用、新零售/新金融/出行等交易類應(yīng)用，教育、傳媒、醫(yī)療等行業(yè)應(yīng)用，以及公共網(wǎng)站、CRM 等企業(yè)內(nèi)部應(yīng)用，適用范圍非常廣泛。
其中，HTTPS 是 HTTP 的安全版本，通過 SSL/TLS 協(xié)議，對(duì)傳輸數(shù)據(jù)進(jìn)行加密保護(hù)，加解密過程中會(huì)帶來一些性能損耗。
從 API 管理的視角，看不同類型的網(wǎng)絡(luò)通信協(xié)議：
HTTPS 是一種無狀態(tài)的、應(yīng)用層的協(xié)議，用于在客戶端（如瀏覽器）和服務(wù)器之間傳輸超文本（如 HTML 文件、圖片、視頻等）。
它具有以下特點(diǎn)：
- 1）基于請(qǐng)求-響應(yīng)模型；
- 2）無狀態(tài)：每次請(qǐng)求都是獨(dú)立的，服務(wù)器不會(huì)保存客戶端的狀態(tài)；
- 3）數(shù)據(jù)加密，防止數(shù)據(jù)被竊聽或篡改；身份驗(yàn)證，確保客戶端與正確的服務(wù)器通信；數(shù)據(jù)完整性，防止數(shù)據(jù)在傳輸過程中被修改。（HTTP 是明文傳輸）
它的優(yōu)勢(shì)是：
- 1）簡(jiǎn)單易用：HTTP 協(xié)議設(shè)計(jì)簡(jiǎn)單，易于實(shí)現(xiàn)和使用；
- 2）廣泛支持：幾乎所有瀏覽器、服務(wù)器和開發(fā)框架都支持 HTTP；
- 3）靈活性：支持多種數(shù)據(jù)格式（如 JSON、XML、HTML）和內(nèi)容類型；
- 4）無狀態(tài)：簡(jiǎn)化了服務(wù)器的設(shè)計(jì)，適合分布式系統(tǒng)；
5）安全和合規(guī)性：通過加密技術(shù)保護(hù)數(shù)據(jù)傳輸，防止竊聽和篡改；符合現(xiàn)代網(wǎng)絡(luò)安全標(biāo)準(zhǔn)（如 GDPR、PCI DSS）。
這里我們以 TLS 1.3 為例，通過一張圖了解下 HTTPS 在客戶端和服務(wù)端之間的握手過程。
4、為什么傳統(tǒng)Web端網(wǎng)絡(luò)通信協(xié)議不適合大模型
不同類型的大模型應(yīng)用，對(duì)網(wǎng)絡(luò)通信的需求不盡相同，但幾乎都離不開以下需求。
具體就是：
- 1）實(shí)時(shí)對(duì)話：用戶與模型進(jìn)行連續(xù)交互，模型需要即時(shí)響應(yīng)。例如通義千問，HIgress 官網(wǎng)的答疑機(jī)器人，都是需要依據(jù)客戶問題，即時(shí)做出響應(yīng)；
- 2）流式輸出：大模型生成內(nèi)容時(shí)，逐字或逐句返回結(jié)果，而不是一次性返回。但是釘釘、微信等應(yīng)用，兩個(gè)人相互對(duì)話時(shí)，采用的就不是流式輸出了，文字等內(nèi)容都是一次性返回的；
- 3）長(zhǎng)時(shí)任務(wù)處理：大模型可能需要較長(zhǎng)時(shí)間處理復(fù)雜任務(wù)，同時(shí)需要向客戶端反饋進(jìn)度，尤其是處理長(zhǎng)文本、以及圖片、視頻等多模態(tài)內(nèi)容；這是因?yàn)橐蕾嚧竽Ｐ陀?jì)算的響應(yīng)，要比依賴人為寫入的業(yè)務(wù)邏輯的響應(yīng)，消耗的資源多的多，這也是為什么大模型的計(jì)算要依靠 GPU，而非 CPU，CPU 在并行計(jì)算和大規(guī)模矩陣計(jì)算上遠(yuǎn)不如 GPU；
- 4）多輪交互：用戶與模型之間需要多次往返交互，保持上下文。這是大模型應(yīng)用保障用戶體驗(yàn)的必備能力。
這些場(chǎng)景對(duì)實(shí)時(shí)性和雙向通信有較高要求，沿用 Web 類應(yīng)用的主流通信協(xié)議 - HTTPS，將會(huì)存在很多問題。
以下是主要的問題：
- 1）僅支持單向通信，即請(qǐng)求-響應(yīng)模型，必須是客戶端發(fā)起時(shí)，服務(wù)端才能做出響應(yīng)，無法進(jìn)行雙向通信，導(dǎo)致無法支持流式輸出，無法處理長(zhǎng)時(shí)任務(wù)；
- 2）客戶端每次發(fā)出請(qǐng)求都需要重新建立連接，延遲增加，導(dǎo)致無法支持實(shí)時(shí)對(duì)話；
- 3）HTTPS 是一種無狀態(tài)的通信協(xié)議，每次請(qǐng)求都是獨(dú)立的，服務(wù)端不會(huì)保存客戶端的狀態(tài)，即便客戶端可以在每次請(qǐng)求時(shí)重復(fù)發(fā)送上下文信息，但會(huì)帶來額外的網(wǎng)絡(luò)開銷，導(dǎo)致無法高效的支持多輪交互場(chǎng)景。
雖然 HTTPS 已經(jīng)發(fā)展到 HTTPS/2 和 HTTPS/3，在性能上了有了提升，但是面對(duì)大模型應(yīng)用這類對(duì)實(shí)時(shí)性要求較高的場(chǎng)景，依舊不夠原生，并未成為這類場(chǎng)景下的主流通信協(xié)議。
5、SSE和WebSocket更適合支持大模型應(yīng)用
5.1 SSE的通信原理
1）客戶端發(fā)起 SSE 連接：
- 1）客戶端通過 JavaScript 的 EventSource API 向服務(wù)器發(fā)起 HTTP 請(qǐng)求；
- 2）請(qǐng)求頭中包含 Accept: text/event-stream，表明客戶端支持 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ù)器通過 HTTP 長(zhǎng)連接持續(xù)推送數(shù)據(jù)，每條消息以 data: 開頭，以兩個(gè)換行符 \n\n 結(jié)束；
- 2）示例數(shù)據(jù)流。
data: {"message": "Hello"}
data: {"message": "World"}
4）客戶端處理數(shù)據(jù)：
- 1）客戶端通過 EventSource 的 onmessage 事件監(jiān)聽服務(wù)器推送的數(shù)據(jù)；
- 2）示例代碼。
eventSource.onmessage = (event) => {
console.log('Received data:', event.data);
};
5）連接關(guān)閉或錯(cuò)誤處理：
- 1）如果連接中斷（如網(wǎng)絡(luò)問題），客戶端會(huì)自動(dòng)嘗試重新連接；
- 2）服務(wù)器可以通過發(fā)送 retry: 字段指定重連時(shí)間（毫秒）；
- 3）示例重連設(shè)置。
retry: 5000
我們可以通過下方方式驗(yàn)證大模型 APP 使用的網(wǎng)絡(luò)通信協(xié)議。
調(diào)用 API 并檢查響應(yīng)頭：使用 stream=True 參數(shù)請(qǐng)求流式響應(yīng)，通過開發(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）客戶端發(fā)起 WebSocket 握手請(qǐng)求：
客戶端通過 HTTP 請(qǐng)求發(fā)起 WebSocket 握手，請(qǐng)求頭中包含以下字段：
- 1）Upgrade: websocket：表明客戶端希望升級(jí)到 WebSocket 協(xié)議；
- 2）Connection: Upgrade：表明客戶端希望升級(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)證客戶端的握手請(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：基于客戶端的 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 連接，客戶端和服務(wù)器可以通過 WebSocket 協(xié)議進(jìn)行雙向通信；
- 2）連接基于 TCP，支持全雙工通信。
4）數(shù)據(jù)傳輸：
- 1）客戶端和服務(wù)器通過 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）客戶端或服務(wù)器可以主動(dòng)發(fā)送關(guān)閉幀（Close Frame）來終止連接；
- 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)景，客戶端在不需要等待服務(wù)端發(fā)送完內(nèi)容后就能發(fā)起請(qǐng)求），推薦基于 WebSocket 協(xié)議，以支持低延遲的多模態(tài)交互，包括文本和音頻輸入輸出。
具有以下特征 ：
- 1）基于事件的通信：Realtime API 通過 WebSocket 進(jìn)行有狀態(tài)的事件驅(qū)動(dòng)交互，客戶端和服務(wù)器之間通過發(fā)送和接收 JSON 格式的事件進(jìn)行通信135；
- 2）持久連接：WebSocket 協(xié)議使得 API 能夠保持一個(gè)持續(xù)的雙向連接，允許即時(shí)的數(shù)據(jù)流動(dòng)，這對(duì)于實(shí)時(shí)對(duì)話和交互至關(guān)重要；
- 3）多模態(tài)支持：該 API 不僅支持文本輸入，還可以處理音頻數(shù)據(jù)，提供更加豐富和自然的用戶體驗(yàn)。
可見：SSE 和 WebSocket 均能較好的支持大模型應(yīng)用的實(shí)時(shí)性需求，前者更加輕量化，后者因?yàn)槭请p向通信在實(shí)時(shí)性要求更高的場(chǎng)景更有優(yōu)勢(shì)。這里我們通過一張表來比對(duì)下各個(gè)協(xié)議的特點(diǎn)。
總結(jié)來看：HTTP/1.1 適合傳統(tǒng)網(wǎng)頁和簡(jiǎn)單 API 請(qǐng)求，但性能較低。HTTP/2 適合現(xiàn)代高性能網(wǎng)頁，解決了 HTTP/1.1 的隊(duì)頭阻塞問題，SSE 適合服務(wù)器主動(dòng)推送實(shí)時(shí)數(shù)據(jù)的場(chǎng)景，如一問一答的大模型應(yīng)用，WebSocket 適合需要雙向?qū)崟r(shí)通信的場(chǎng)景如在線游戲、多人協(xié)作、實(shí)時(shí)性要求更高的大模型應(yīng)用場(chǎng)景（隨時(shí)可以打斷生成過程進(jì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)景。但是用戶體量擴(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)大廳，且單次訪問數(shù)據(jù)量大、訪問用戶多，對(duì)扮演管理 SSE 和WebSocket 的連接建立和維護(hù)的網(wǎng)關(guān)，提出了更高的要求。
以下羅列了具體的挑戰(zhàn)和網(wǎng)關(guān)層的應(yīng)對(duì)方案，方案部分僅供參考，工程上的問題沒有唯一的答案，應(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ò)容過程中（增加實(shí)例），現(xiàn)有的 SSE 和 WebSocket 可能無法連接到新實(shí)例，服務(wù)縮容過程中（減少實(shí)例），現(xiàn)有的 SSE 和 WebSocket 可能會(huì)因服務(wù)的下線而被強(qiáng)制關(guān)閉，這些對(duì)實(shí)時(shí)性要求比較高的應(yīng)用，例如游戲、大模型實(shí)時(shí)聊天，都會(huì)帶來用戶體驗(yàn)的下降。
應(yīng)對(duì)方案：
- 1）無損上下線能力：該能力在微服務(wù)變更時(shí)，應(yīng)用比較廣泛，可以有效降低版本發(fā)布和擴(kuò)縮容的穩(wěn)定性風(fēng)險(xiǎn)。常見于云產(chǎn)品的商業(yè)能力。例如，阿里云的云原生 API 網(wǎng)關(guān)提供了面向 HTTPS/WebSocket 的微服務(wù)治理能力；
- 2）客戶端重連機(jī)制：在客戶端設(shè)計(jì)自動(dòng)重連機(jī)制，減少中斷影響，和無損上下線一樣，使用心跳包檢測(cè)連接狀態(tài)，一旦中斷自動(dòng)重連，此外，還可以在服務(wù)器端記錄已發(fā)送的數(shù)據(jù)，實(shí)現(xiàn)斷點(diǎn)續(xù)傳；
- 3）協(xié)議切換機(jī)制：在 SSE 和 WebSocket 不可用時(shí)，回退到長(zhǎng)輪詢（Long Polling），不過這個(gè)依賴于網(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 類應(yīng)用，導(dǎo)致內(nèi)存快速上漲，同時(shí)帶來更高的帶寬成本。
應(yīng)對(duì)方案：選擇支持流式處理的網(wǎng)關(guān)（如 Higress），將生成的內(nèi)容分塊傳輸，減少單次傳輸?shù)臄?shù)據(jù)量。同時(shí)，采用壓縮算法（如 Gzip），減少數(shù)據(jù)傳輸量，控制帶寬成本。阿里云云原生 API 網(wǎng)關(guān)即將上線軟硬一體化的內(nèi)容壓縮方案，帶寬傳輸成本可下降20%+。
6.4 高延時(shí)導(dǎo)致防范惡意攻擊的資源成本增高
技術(shù)挑戰(zhàn)：相比 Web 類應(yīng)用，大模型應(yīng)用推理時(shí)消耗的計(jì)算資源更多。例如發(fā)生 DDoS 攻擊時(shí)， Web 類應(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ì)來自客戶端的請(qǐng)求，進(jìn)行合規(guī)性的校驗(yàn)。基于具體的業(yè)務(wù)需求，選擇第三方的認(rèn)證協(xié)議，從我們服務(wù)的客戶經(jīng)驗(yàn)上看，選擇 OAuth2、JWT 的居多；
- 2）安全防護(hù)：通過 IP 限制，或者基于URL、請(qǐng)求頭等特征，設(shè)計(jì)安全防護(hù)措施；
- 3）流量管控：基于 URL 參數(shù)、HTTP 請(qǐng)求頭、客戶端 IP 地址、消費(fèi)者名稱或 Cookie 中的 Key，進(jìn)行 token 級(jí)別的限流。
7、未來趨勢(shì)
大模型應(yīng)用除了帶來了 SSE 和 WebSocket 的使用頻率越來越高，也在助推 API First 的理念。
以往：在線應(yīng)用都是通過 Service 來對(duì)外暴露提供能力，但大模型應(yīng)用將通過 API 對(duì)外提供服務(wù)能力，除了基模類廠商已經(jīng)通過提供 API 來服務(wù)廣大開發(fā)者群體，大模型應(yīng)用類廠商也開始提供 API 服務(wù)。
例如：近日 Perplexity 將面向企業(yè)客戶和開發(fā)人員推出其 AI 搜索的 API 服務(wù)——基礎(chǔ)版 Sonar 和高級(jí)版 Sonar Pro，以允許企業(yè)和開發(fā)人員把 Perplexity 的生成式 AI 搜索工具構(gòu)建到自己的應(yīng)用中去。
這樣做的好處是：Perplexity 可以因此讓自己的 AI 搜索無處不在，而不只局限在它的應(yīng)用與網(wǎng)站里。一個(gè)案例是其客戶 Zoom：Sonar 允許 Zoom 的 AI 聊天機(jī)器人根據(jù)帶有引文的網(wǎng)絡(luò)搜索提供實(shí)時(shí)答案，而不需要 Zoom 的視頻用戶離開聊天窗口。隨著國(guó)內(nèi)大模型應(yīng)用的成熟，相信這一趨勢(shì)會(huì)越加明顯。
8、參考資料
[1] 深入淺出，全面理解HTTP協(xié)議
[2] HTTP協(xié)議必知必會(huì)的一些知識(shí)
[3] 一分鐘理解 HTTPS 到底解決了什么問題
[4] 如果這樣來理解HTTPS原理，一篇就夠了
[5] 為什么要用HTTPS？深入淺出，探密短連接的安全性
[6] 新手入門貼：史上最全Web端即時(shí)通訊技術(shù)原理詳解
[7] Web端即時(shí)通訊技術(shù)盤點(diǎn)：短輪詢、Comet、Websocket、SSE
[8] SSE技術(shù)詳解：一種全新的HTML5服務(wù)器推送事件技術(shù)
[9] Comet技術(shù)詳解：基于HTTP長(zhǎng)連接的Web端實(shí)時(shí)通信技術(shù)
[10] WebSocket從入門到精通，半小時(shí)就夠！
[11] 刨根問底WebSocket與Socket的關(guān)系
[12] 使用WebSocket和SSE技術(shù)實(shí)現(xiàn)Web端消息推送
[13] 詳解Web端通信方式的演進(jìn)：從Ajax、JSONP 到 SSE、Websocket
[14] 網(wǎng)頁端IM通信技術(shù)快速入門：短輪詢、長(zhǎng)輪詢、SSE、WebSocket
[15] 搞懂現(xiàn)代Web端即時(shí)通訊技術(shù)一文就夠：WebSocket、socket.io、SSE
[16] 淺談網(wǎng)頁端IM技術(shù)及相關(guān)測(cè)試方法實(shí)踐（包括WebSocket性能測(cè)試）
（本文已同步發(fā)布于：http://www.52im.net/thread-4797-1-1.html）