成人a一级毛片免费看,中文字幕国产视频,最近的中文字幕2019更新

HTTP + SSE 存在的問(wèn)題

HTTP+SSE的傳輸過(guò)程實(shí)現(xiàn)中，客戶端和服務(wù)器通過(guò)兩個(gè)主要渠道進(jìn)行通信：（1）HTTP 請(qǐng)求/響應(yīng)：客戶端通過(guò)標(biāo)準(zhǔn)的 HTTP 請(qǐng)求向服務(wù)器發(fā)送消息。（2）服務(wù)器發(fā)送事件（SSE）：服務(wù)器通過(guò)專門的 /sse 端點(diǎn)向客戶端推送消息，這就導(dǎo)致存在下面三個(gè)問(wèn)題：

服務(wù)器必須維護(hù)長(zhǎng)連接，在高并發(fā)情況下會(huì)導(dǎo)致顯著的資源消耗。
服務(wù)器消息只能通過(guò) SSE 傳遞，造成了不必要的復(fù)雜性和開(kāi)銷。
基礎(chǔ)架構(gòu)兼容性，許多現(xiàn)有的網(wǎng)絡(luò)基礎(chǔ)架構(gòu)可能無(wú)法正確處理長(zhǎng)期的 SSE 連接。企業(yè)防火墻可能會(huì)強(qiáng)制終止超時(shí)連接，導(dǎo)致服務(wù)不可靠。

Streamable HTTP 的改進(jìn)

Streamable HTTP 是 MCP 協(xié)議的一次重要升級(jí)，通過(guò)下面的改進(jìn)解決了原有 HTTP + SSE 傳輸方式的多個(gè)關(guān)鍵問(wèn)題：

1. 統(tǒng)一端點(diǎn)設(shè)計(jì)

Streamable HTTP 移除了專門建立連接的 /sse 端點(diǎn)，將所有通信整合到統(tǒng)一的端點(diǎn)。這一設(shè)計(jì)帶來(lái)的好處包括：

簡(jiǎn)化架構(gòu)：減少了客戶端和服務(wù)器之間的連接數(shù)，降低了系統(tǒng)復(fù)雜度
降低資源消耗：?jiǎn)我贿B接管理更高效，減少了服務(wù)器資源占用
提高兼容性：更好地適應(yīng)現(xiàn)有網(wǎng)絡(luò)基礎(chǔ)設(shè)施，減少防火墻和代理服務(wù)器的兼容性問(wèn)題

2. 靈活的傳輸模式

服務(wù)器可以根據(jù)請(qǐng)求類型和內(nèi)容靈活選擇返回標(biāo)準(zhǔn) HTTP 響應(yīng)或通過(guò) SSE 流式返回：

按需流式傳輸：對(duì)于簡(jiǎn)單請(qǐng)求可直接返回HTTP響應(yīng)，無(wú)需建立長(zhǎng)連接
智能降級(jí)：在網(wǎng)絡(luò)條件不佳時(shí)可自動(dòng)降級(jí)為標(biāo)準(zhǔn)HTTP模式
資源優(yōu)化：根據(jù)請(qǐng)求復(fù)雜度動(dòng)態(tài)分配服務(wù)器資源，提高整體效率

3. 強(qiáng)大的會(huì)話管理

引入了完善的session機(jī)制以支持狀態(tài)管理和恢復(fù)：

會(huì)話一致性：通過(guò)Mcp-Session-Id頭確保跨請(qǐng)求的狀態(tài)一致性
斷線重連：支持Last-Event-ID機(jī)制，確保在連接中斷后能夠恢復(fù)未接收的消息
狀態(tài)恢復(fù)：允許客戶端在重新連接時(shí)恢復(fù)之前的會(huì)話狀態(tài)，提高用戶體驗(yàn)

HTTP + SSE vs Streamable HTTP

下面通過(guò)實(shí)際應(yīng)用場(chǎng)景中穩(wěn)定性，性能和客戶端復(fù)雜度三個(gè)角度對(duì)比說(shuō)明 Streamable HTTP 相比 HTTP + SSE的優(yōu)勢(shì)，AI 網(wǎng)關(guān) Higress 目前已經(jīng)支持了 Streamable HTTP 協(xié)議，通過(guò) MCP 官方 Python SDK 的樣例 Server 部署了一個(gè) HTTP + SSE 協(xié)議的 MCP Server，通過(guò) Higress 部署了一個(gè) Streamable HTTP 協(xié)議的MCP Server。

穩(wěn)定性對(duì)比

TCP 連接數(shù)對(duì)比

利用Python程序模擬1000個(gè)用戶同時(shí)并發(fā)訪問(wèn)遠(yuǎn)程的MCP Server并調(diào)用獲取工具列表，圖中可以看出 SSE Server的 SSE 連接無(wú)法復(fù)用且需要長(zhǎng)期維護(hù)，高并發(fā)的需求也會(huì)帶來(lái) TCP 連接數(shù)的突增，而 Streamable HTTP 協(xié)議則可以直接返回響應(yīng)，多個(gè)請(qǐng)求可以復(fù)用同一個(gè) TCP 連接，TCP連接數(shù)最高只到幾十條，并且整體執(zhí)行時(shí)間也只有SSE Server 的四分之一。

在1000個(gè)并發(fā)用戶的測(cè)試場(chǎng)景下，Higress 部署的 Streamable HTTP 方案的 TCP 連接數(shù)明顯低于 HTTP + SSE 方案：

HTTP + SSE：需要維持大量長(zhǎng)連接，TCP連接數(shù)隨時(shí)間持續(xù)增長(zhǎng)
Streamable HTTP：按需建立連接，TCP連接數(shù)維持在較低水平

請(qǐng)求成功率對(duì)比

實(shí)際應(yīng)用場(chǎng)景中進(jìn)程級(jí)別通常會(huì)限制最大連接數(shù)，linux默認(rèn)通常是1024。利用Python程序模擬不同數(shù)量的用戶訪問(wèn)遠(yuǎn)程的MCP Server并調(diào)用獲取工具列表，SSE Server在并發(fā)請(qǐng)求數(shù)到達(dá)最大連接數(shù)限制后，成功率會(huì)極速下降，大量的并發(fā)請(qǐng)求無(wú)法建立新的 SSE 連接而訪問(wèn)失敗。

在不同并發(fā)用戶數(shù)下的請(qǐng)求成功率測(cè)試中，Higress 部署的 Streamable HTTP 的成功率顯著高于 HTTP + SSE 方案：

HTTP + SSE：隨著并發(fā)用戶數(shù)增加，成功率顯著下降
Streamable HTTP：即使在高并發(fā)場(chǎng)景下仍能保持較高的請(qǐng)求成功率

性能對(duì)比

這里對(duì)比的是社區(qū) Python 版本的 GitHUB MCP Server 和 Higress MCP 市場(chǎng)的 GitHUB MCP Server。

利用 Python 程序模擬不同數(shù)量的用戶同時(shí)并發(fā)訪問(wèn)遠(yuǎn)程的 MCP Server 并調(diào)用獲取工具列表，并統(tǒng)計(jì)調(diào)用返回響應(yīng)的時(shí)間，圖中給出的響應(yīng)時(shí)間對(duì)比為對(duì)數(shù)刻度，SSE Server 在并發(fā)用戶數(shù)量較多時(shí)平均響應(yīng)時(shí)間會(huì)從0.0018s顯著增加到1.5112s，而 Higress 部署的 Streamable HTTP Server 則依然維持在0.0075s的響應(yīng)時(shí)間，也得益于 Higress 生產(chǎn)級(jí)的性能相比于 Python Starlette框架。

性能測(cè)試結(jié)果顯示，Higress 部署的Streamable HTTP 在響應(yīng)時(shí)間方面具有明顯優(yōu)勢(shì)：

Streamable HTTP 的平均響應(yīng)時(shí)間更短，響應(yīng)時(shí)間波動(dòng)較小，隨并發(fā)用戶數(shù)增加，響應(yīng)時(shí)間增長(zhǎng)更平。
HTTP + SSE 的平均響應(yīng)時(shí)間更長(zhǎng)，在高并發(fā)場(chǎng)景下響應(yīng)時(shí)間波動(dòng)較大。

客戶端復(fù)雜度對(duì)比

Streamable HTTP 支持無(wú)狀態(tài)的服務(wù)和有狀態(tài)的服務(wù)，目前的大部分場(chǎng)景無(wú)狀態(tài)的 Streamable HTTP的可以解決，通過(guò)對(duì)比兩種傳輸方案的客戶端實(shí)現(xiàn)代碼，可以直觀地看到無(wú)狀態(tài)的 Streamable HTTP 的客戶端實(shí)現(xiàn)簡(jiǎn)潔性。

HTTP + SSE 客戶端樣例代碼

classSSEClient:

    def __init__(self, url: str, headers: dict = None):

        self.url = url

        self.headers = headers or {}

        self.event_source = None

        self.endpoint = None



        async def connect(self):

            # 1. 建立 SSE 連接

            async with aiohttp.ClientSession(headers=self.headers) as session:

                self.event_source = await session.get(self.url)



                # 2. 處理連接事件

                print('SSE connection established')



                # 3. 處理消息事件

                async for line in self.event_source.content:

                    if line:

                        message = json.loads(line)

                        await self.handle_message(message)



                        # 4. 處理錯(cuò)誤和重連

                        if self.event_source.status != 200:

                            print(f'SSE error: {self.event_source.status}')

                            await self.reconnect()



        async def send(self, message: dict):

            # 需要額外的 POST 請(qǐng)求發(fā)送消息

            async with aiohttp.ClientSession(headers=self.headers) as session:

                async with session.post(self.endpoint, json=message) as response:

                    return await response.json()



                async def handle_message(self, message: dict):

                    # 處理接收到的消息

                    print(f'Received message: {message}')



    async def reconnect(self):

        # 實(shí)現(xiàn)重連邏輯

        print('Attempting to reconnect...')

        await self.connect()

Streamable HTTP 客戶端樣例代碼

classStreamableHTTPClient:

    def __init__(self, url: str, headers: dict = None):

        self.url = url

        self.headers = headers or {}



    async def send(self, message: dict):

        # 1. 發(fā)送 POST 請(qǐng)求

        async with aiohttp.ClientSession(headers=self.headers) as session:

            async with session.post( self.url, json=message,

                headers={'Content-Type': 'application/json'}

            ) as response:

                # 2. 處理響應(yīng)

                if response.status == 200:

                    return await response.json()

                else:

                    raise Exception(f'HTTP error: {response.status}')

從代碼對(duì)比可以看出：

1. 復(fù)雜度：Streamable HTTP 無(wú)需處理連接維護(hù)、重連等復(fù)雜邏輯

2. 可維護(hù)性：Streamable HTTP 代碼結(jié)構(gòu)更清晰，更易于維護(hù)和調(diào)試

3. 錯(cuò)誤處理：Streamable HTTP 的錯(cuò)誤處理更直接，無(wú)需考慮連接狀態(tài)

總結(jié)與展望

隨著MCP協(xié)議的不斷發(fā)展，Streamable HTTP傳輸機(jī)制的引入標(biāo)志著協(xié)議向更高效、更穩(wěn)定的方向邁進(jìn)了一大步。通過(guò)統(tǒng)一端點(diǎn)設(shè)計(jì)、靈活的傳輸模式和強(qiáng)大的會(huì)話管理，Streamable HTTP解決了HTTP+SSE方案中的諸多痛點(diǎn)，為AI應(yīng)用提供了更可靠的通信基礎(chǔ)。

對(duì)于希望快速部署高性能MCP服務(wù)的開(kāi)發(fā)者和企業(yè)，mcp.higress.ai[2]提供了基于Higress開(kāi)源AI網(wǎng)關(guān)構(gòu)建的MCP server托管市場(chǎng)。這個(gè)市場(chǎng)的獨(dú)特優(yōu)勢(shì)在于：

雙協(xié)議支持：同時(shí)提供高性能的Streamable HTTP協(xié)議和兼容POST+SSE協(xié)議的服務(wù)，確保與各類客戶端的兼容性
API直接轉(zhuǎn)換：無(wú)需編寫(xiě)代碼，從規(guī)范的API文檔直接轉(zhuǎn)換成生產(chǎn)可用的MCP服務(wù)
零成本部署：幾乎不需要任何成本即可將現(xiàn)有API轉(zhuǎn)化為MCP服務(wù)
實(shí)際價(jià)值導(dǎo)向：所有提供的能力都借助API本身的使用場(chǎng)景，具有實(shí)際應(yīng)用價(jià)值

與其他MCP市場(chǎng)不同，mcp.higress.ai不是簡(jiǎn)單收集開(kāi)源社區(qū)中未經(jīng)充分驗(yàn)證的Python/TS項(xiàng)目，而是專注于將成熟的API轉(zhuǎn)化為高質(zhì)量的MCP服務(wù)，為AI應(yīng)用提供可靠的工具和資源支持。隨著MCP協(xié)議的普及和應(yīng)用場(chǎng)景的拓展，基于Higress的MCP服務(wù)將為AI生態(tài)系統(tǒng)提供更加堅(jiān)實(shí)的基礎(chǔ)設(shè)施支持。

參考鏈接：

[1]https://github.com/modelcontextprotocol/modelcontextprotocol/pull/206

[2]https://mcp.higress.ai/

文章轉(zhuǎn)載自： MCP 協(xié)議：為什么 Streamable HTTP 是最佳選擇？