• 正文
  • 相關(guān)推薦
申請(qǐng)入駐 產(chǎn)業(yè)圖譜

MCP傳輸協(xié)議改進(jìn)提案解讀：從HTTP+SSE 到“可流式 HTTP”

03/20 14:39
1503
加入交流群
掃碼加入
獲取工程師必備禮包
參與熱點(diǎn)資訊討論

這個(gè) Pull Request (#206) 提出了一個(gè)名為 "可流式 HTTP" (Streamable HTTP)的新傳輸協(xié)議，用于替代 MCP (Model Context Protocol) 當(dāng)前使用的 HTTP+SSE 傳輸方式。這是一個(gè)重要的技術(shù)改進(jìn)，旨在解決現(xiàn)有傳輸方式的一些關(guān)鍵限制，同時(shí)保留其優(yōu)勢(shì)。

地址：https://github.com/modelcontextprotocol/specification/pull/206

主要變更點(diǎn)

與當(dāng)前的 HTTP+SSE 傳輸相比，新提案做出了以下改變：

1. 移除了?/sse 端點(diǎn)

2. 所有客戶(hù)端→服務(wù)器的消息都通過(guò)?/message（或類(lèi)似）端點(diǎn)傳輸

3. 所有客戶(hù)端→服務(wù)器的請(qǐng)求可以被服務(wù)器升級(jí)為 SSE，用于發(fā)送通知/請(qǐng)求

4. 服務(wù)器可以選擇建立會(huì)話(huà) ID 來(lái)維持狀態(tài)

5. 客戶(hù)端可以通過(guò)向?/message 發(fā)送空 GET 請(qǐng)求來(lái)初始化 SSE 流這種方法可以向后兼容實(shí)現(xiàn)，并允許服務(wù)器在需要時(shí)完全無(wú)狀態(tài)運(yùn)行。

解決的問(wèn)題

當(dāng)前的 HTTP+SSE 傳輸存在以下限制：

    ? 不支持可恢復(fù)性? 要求服務(wù)器維護(hù)高可用性的長(zhǎng)連接? 服務(wù)器消息只能通過(guò) SSE 傳遞

新方案的優(yōu)勢(shì)

支持無(wú)狀態(tài)服務(wù)器?- 不再需要高可用性的長(zhǎng)連接
純 HTTP 實(shí)現(xiàn)?- MCP 可以在普通 HTTP 服務(wù)器上實(shí)現(xiàn)，不一定需要 SSE
基礎(chǔ)設(shè)施兼容性?- 因?yàn)?只是 HTTP"，確保與中間件和基礎(chǔ)設(shè)施兼容
向后兼容?- 這是對(duì)當(dāng)前傳輸方式的漸進(jìn)式演進(jìn)
靈活的升級(jí)路徑?- 服務(wù)器可以在需要時(shí)選擇使用 SSE 進(jìn)行流式響應(yīng)

使用場(chǎng)景示例

無(wú)狀態(tài)服務(wù)器

提案支持完全無(wú)狀態(tài)的服務(wù)器實(shí)現(xiàn)，無(wú)需支持長(zhǎng)連接：

1. 始終確認(rèn)初始化（但無(wú)需保留任何狀態(tài)）

2. 對(duì)任何傳入的?ToolListRequest 用單個(gè)?JSON-RPC 響應(yīng)

3. 處理?CallToolRequest 時(shí)執(zhí)行工具，等待完成，然后發(fā)送單個(gè)?CallToolResponse 作為 HTTP 響應(yīng)體

帶流式處理的無(wú)狀態(tài)服務(wù)器

即使是完全無(wú)狀態(tài)且不支持長(zhǎng)連接的服務(wù)器，在這個(gè)設(shè)計(jì)中仍然可以利用流式處理：

1. 當(dāng)收到?CallToolRequest 時(shí)，服務(wù)器指示響應(yīng)將是 SSE

2. 服務(wù)器開(kāi)始執(zhí)行工具

3. 工具執(zhí)行過(guò)程中，服務(wù)器通過(guò) SSE 發(fā)送任意數(shù)量的?ProgressNotification

4. 工具執(zhí)行完成后，服務(wù)器通過(guò) SSE 發(fā)送?CallToolResponse

5. 服務(wù)器關(guān)閉 SSE 流

有狀態(tài)服務(wù)器

有狀態(tài)服務(wù)器的實(shí)現(xiàn)與現(xiàn)在非常相似，主要區(qū)別是服務(wù)器需要生成會(huì)話(huà) ID，客戶(hù)端需要在每個(gè)請(qǐng)求中傳回該 ID。服務(wù)器可以使用會(huì)話(huà) ID 進(jìn)行粘性路由或在消息總線(xiàn)上路由消息。

為什么不使用 WebSocket

團(tuán)隊(duì)詳細(xì)討論了將 WebSocket 作為主要遠(yuǎn)程傳輸方式的可能性，但最終決定不采用，原因包括：

    1. 1. 對(duì)于"RPC 式"使用場(chǎng)景，WebSocket 會(huì)帶來(lái)不必要的運(yùn)營(yíng)和網(wǎng)絡(luò)開(kāi)銷(xiāo)2. 在瀏覽器中，無(wú)法為 WebSocket 附加頭信息（如

Authorization

    ），且第三方庫(kù)無(wú)法在瀏覽器中從頭實(shí)現(xiàn) WebSocket3. 只有 GET 請(qǐng)求可以透明升級(jí)為 WebSocket，這意味著在 POST 端點(diǎn)上需要兩步升級(jí)過(guò)程，增加復(fù)雜性和延遲

團(tuán)隊(duì)也避免將 WebSocket 作為規(guī)范中的額外選項(xiàng)，以限制 MCP 官方指定的傳輸方式數(shù)量，避免客戶(hù)端和服務(wù)器之間的組合兼容性問(wèn)題。

待辦事項(xiàng)

? 將會(huì)話(huà) ID 責(zé)任轉(zhuǎn)移到服務(wù)器

? 定義可接受的會(huì)話(huà) ID 空間

? 確保中間件/WAF 可以?xún)?nèi)省會(huì)話(huà) ID

? 使取消操作明確化

? 要求集中式 SSE GET 用于服務(wù)器→客戶(hù)端請(qǐng)求和通知

? 將可恢復(fù)性轉(zhuǎn)換為每個(gè)流的概念

? 設(shè)計(jì)主動(dòng)"結(jié)束會(huì)話(huà)"的方式

? "如果客戶(hù)端有認(rèn)證令牌，應(yīng)在每個(gè) MCP 請(qǐng)求中包含它"

后續(xù)工作

    ? 標(biāo)準(zhǔn)化對(duì) JSON-RPC 批處理的支持? 支持流式請(qǐng)求體? 在規(guī)范中加入關(guān)于超時(shí)的建議，可能還會(huì)制定約定，如"發(fā)出進(jìn)度通知應(yīng)重置默認(rèn)超時(shí)"

這個(gè)提案是在廣泛社區(qū)討論和反饋的基礎(chǔ)上形成的，表明 MCP 正在積極發(fā)展以滿(mǎn)足更廣泛的使用場(chǎng)景需求。

 



	
				
			

															
						
						

		
	
	
						

	

		
相關(guān)推薦