Skip to content

Latest commit

 

History

History
494 lines (351 loc) · 42 KB

README.md

File metadata and controls

494 lines (351 loc) · 42 KB

การสตรีม HTTPS ด้วย Model Context Protocol (MCP)

บทนี้ให้คำแนะนำที่ครอบคลุมเกี่ยวกับการใช้งานการสตรีมที่ปลอดภัย ขยายขนาดได้ และแบบเรียลไทม์ด้วย Model Context Protocol (MCP) ผ่าน HTTPS โดยครอบคลุมแรงจูงใจในการสตรีม กลไกการขนส่งที่มีอยู่ วิธีการใช้งาน HTTP แบบสตรีมใน MCP แนวทางปฏิบัติด้านความปลอดภัย การย้ายจาก SSE และคำแนะนำเชิงปฏิบัติสำหรับการสร้างแอปพลิเคชัน MCP แบบสตรีมของคุณเอง

กลไกการขนส่งและการสตรีมใน MCP

ส่วนนี้สำรวจกลไกการขนส่งที่แตกต่างกันใน MCP และบทบาทของมันในการเปิดใช้งานความสามารถในการสตรีมสำหรับการสื่อสารแบบเรียลไทม์ระหว่างไคลเอนต์และเซิร์ฟเวอร์

กลไกการขนส่งคืออะไร?

กลไกการขนส่งกำหนดวิธีการแลกเปลี่ยนข้อมูลระหว่างไคลเอนต์และเซิร์ฟเวอร์ MCP รองรับประเภทการขนส่งหลายประเภทเพื่อให้เหมาะกับสภาพแวดล้อมและความต้องการที่แตกต่างกัน:

  • stdio: การป้อนข้อมูล/เอาต์พุตมาตรฐาน เหมาะสำหรับเครื่องมือ CLI และการใช้งานในเครื่อง เรียบง่ายแต่ไม่เหมาะสำหรับเว็บหรือคลาวด์
  • SSE (Server-Sent Events): อนุญาตให้เซิร์ฟเวอร์ส่งการอัปเดตแบบเรียลไทม์ไปยังไคลเอนต์ผ่าน HTTP ดีสำหรับ UI บนเว็บ แต่มีข้อจำกัดในด้านการขยายขนาดและความยืดหยุ่น
  • Streamable HTTP: การขนส่งแบบสตรีมที่ทันสมัยบน HTTP รองรับการแจ้งเตือนและการขยายขนาดที่ดีกว่า แนะนำสำหรับการใช้งานในระบบผลิตและคลาวด์ส่วนใหญ่

ตารางเปรียบเทียบ

ดูตารางเปรียบเทียบด้านล่างเพื่อทำความเข้าใจความแตกต่างระหว่างกลไกการขนส่งเหล่านี้:

การขนส่ง การอัปเดตแบบเรียลไทม์ การสตรีม การขยายขนาด กรณีการใช้งาน
stdio ไม่ ไม่ ต่ำ เครื่องมือ CLI ในเครื่อง
SSE ใช่ ใช่ ปานกลาง เว็บ, การอัปเดตแบบเรียลไทม์
Streamable HTTP ใช่ ใช่ สูง คลาวด์, หลายไคลเอนต์

เคล็ดลับ: การเลือกการขนส่งที่เหมาะสมส่งผลต่อประสิทธิภาพ การขยายขนาด และประสบการณ์ของผู้ใช้ Streamable HTTP เป็นตัวเลือกที่แนะนำสำหรับแอปพลิเคชันที่ทันสมัย ขยายขนาดได้ และพร้อมใช้งานบนคลาวด์

โปรดสังเกตการขนส่ง stdio และ SSE ที่คุณได้เห็นในบทก่อนหน้า และวิธีที่ Streamable HTTP เป็นการขนส่งที่ครอบคลุมในบทนี้

การสตรีม: แนวคิดและแรงจูงใจ

การทำความเข้าใจแนวคิดพื้นฐานและแรงจูงใจเบื้องหลังการสตรีมเป็นสิ่งสำคัญสำหรับการใช้งานระบบการสื่อสารแบบเรียลไทม์ที่มีประสิทธิภาพ

การสตรีม เป็นเทคนิคในโปรแกรมเครือข่ายที่อนุญาตให้ส่งและรับข้อมูลในชิ้นส่วนเล็ก ๆ ที่จัดการได้ หรือเป็นลำดับของเหตุการณ์ แทนที่จะรอให้การตอบสนองทั้งหมดพร้อมใช้งาน สิ่งนี้มีประโยชน์อย่างยิ่งสำหรับ:

  • ไฟล์หรือชุดข้อมูลขนาดใหญ่
  • การอัปเดตแบบเรียลไทม์ (เช่น แชท แถบความคืบหน้า)
  • การคำนวณที่ใช้เวลานานซึ่งคุณต้องการแจ้งให้ผู้ใช้ทราบ

นี่คือสิ่งที่คุณต้องรู้เกี่ยวกับการสตรีมในระดับสูง:

  • ข้อมูลถูกส่งมอบอย่างต่อเนื่อง ไม่ใช่ทั้งหมดในครั้งเดียว
  • ไคลเอนต์สามารถประมวลผลข้อมูลเมื่อมาถึง
  • ลดความล่าช้าที่รับรู้และปรับปรุงประสบการณ์ของผู้ใช้

ทำไมต้องใช้การสตรีม?

เหตุผลในการใช้การสตรีมมีดังนี้:

  • ผู้ใช้ได้รับข้อมูลทันที ไม่ใช่แค่ตอนจบ
  • เปิดใช้งานแอปพลิเคชันแบบเรียลไทม์และ UI ที่ตอบสนอง
  • ใช้ทรัพยากรเครือข่ายและการประมวลผลได้อย่างมีประสิทธิภาพมากขึ้น

ตัวอย่างง่าย ๆ: เซิร์ฟเวอร์และไคลเอนต์ HTTP Streaming

นี่คือตัวอย่างง่าย ๆ ของวิธีการใช้งานการสตรีม:

Python

เซิร์ฟเวอร์ (Python, ใช้ FastAPI และ StreamingResponse):

from fastapi import FastAPI
from fastapi.responses import StreamingResponse
import time

app = FastAPI()

async def event_stream():
    for i in range(1, 6):
        yield f"data: Message {i}\n\n"
        time.sleep(1)

@app.get("/stream")
def stream():
    return StreamingResponse(event_stream(), media_type="text/event-stream")

ไคลเอนต์ (Python, ใช้ requests):

import requests

with requests.get("http://localhost:8000/stream", stream=True) as r:
    for line in r.iter_lines():
        if line:
            print(line.decode())

ตัวอย่างนี้แสดงให้เห็นว่าเซิร์ฟเวอร์ส่งชุดข้อความไปยังไคลเอนต์เมื่อข้อความพร้อมใช้งาน แทนที่จะรอให้ข้อความทั้งหมดพร้อม

วิธีการทำงาน:

  • เซิร์ฟเวอร์ส่งข้อความแต่ละข้อความเมื่อพร้อม
  • ไคลเอนต์รับและพิมพ์แต่ละชิ้นเมื่อมาถึง

ข้อกำหนด:

  • เซิร์ฟเวอร์ต้องใช้การตอบสนองแบบสตรีม (เช่น StreamingResponse ใน FastAPI)
  • ไคลเอนต์ต้องประมวลผลการตอบสนองเป็นสตรีม (stream=True ใน requests)
  • Content-Type มักจะเป็น text/event-stream หรือ application/octet-stream

Java

เซิร์ฟเวอร์ (Java, ใช้ Spring Boot และ Server-Sent Events):

@RestController
public class CalculatorController {

    @GetMapping(value = "/calculate", produces = MediaType.TEXT_EVENT_STREAM_VALUE)
    public Flux<ServerSentEvent<String>> calculate(@RequestParam double a,
                                                   @RequestParam double b,
                                                   @RequestParam String op) {
        
        double result;
        switch (op) {
            case "add": result = a + b; break;
            case "sub": result = a - b; break;
            case "mul": result = a * b; break;
            case "div": result = b != 0 ? a / b : Double.NaN; break;
            default: result = Double.NaN;
        }

        return Flux.<ServerSentEvent<String>>just(
                    ServerSentEvent.<String>builder()
                        .event("info")
                        .data("Calculating: " + a + " " + op + " " + b)
                        .build(),
                    ServerSentEvent.<String>builder()
                        .event("result")
                        .data(String.valueOf(result))
                        .build()
                )
                .delayElements(Duration.ofSeconds(1));
    }
}

ไคลเอนต์ (Java, ใช้ Spring WebFlux WebClient):

@SpringBootApplication
public class CalculatorClientApplication implements CommandLineRunner {

    private final WebClient client = WebClient.builder()
            .baseUrl("http://localhost:8080")
            .build();

    @Override
    public void run(String... args) {
        client.get()
                .uri(uriBuilder -> uriBuilder
                        .path("/calculate")
                        .queryParam("a", 7)
                        .queryParam("b", 5)
                        .queryParam("op", "mul")
                        .build())
                .accept(MediaType.TEXT_EVENT_STREAM)
                .retrieve()
                .bodyToFlux(String.class)
                .doOnNext(System.out::println)
                .blockLast();
    }
}

หมายเหตุการใช้งาน Java:

  • ใช้ Spring Boot แบบ reactive stack กับ Flux สำหรับการสตรีม
  • ServerSentEvent ให้การสตรีมเหตุการณ์ที่มีโครงสร้างพร้อมประเภทเหตุการณ์
  • WebClient กับ bodyToFlux() ช่วยให้การบริโภคแบบ reactive streaming
  • delayElements() จำลองเวลาการประมวลผลระหว่างเหตุการณ์
  • เหตุการณ์สามารถมีประเภท (info, result) เพื่อการจัดการไคลเอนต์ที่ดีกว่า

การเปรียบเทียบ: การสตรีมแบบคลาสสิก vs MCP Streaming

ความแตกต่างระหว่างวิธีการทำงานของการสตรีมในลักษณะ "คลาสสิก" กับวิธีการทำงานใน MCP สามารถแสดงได้ดังนี้:

คุณสมบัติ การสตรีม HTTP แบบคลาสสิก MCP Streaming (Notifications)
การตอบสนองหลัก ส่งเป็นชิ้นส่วน ส่งครั้งเดียวเมื่อสิ้นสุด
การอัปเดตความคืบหน้า ส่งเป็นชิ้นส่วนข้อมูล ส่งเป็นการแจ้งเตือน
ข้อกำหนดของไคลเอนต์ ต้องประมวลผลสตรีม ต้องใช้งานตัวจัดการข้อความ
กรณีการใช้งาน ไฟล์ขนาดใหญ่, การสตรีมโทเค็น AI ความคืบหน้า, บันทึก, ข้อเสนอแนะแบบเรียลไทม์

ความแตกต่างที่สำคัญที่สังเกตได้

นอกจากนี้ ยังมีความแตกต่างที่สำคัญดังนี้:

  • รูปแบบการสื่อสาร:

    • การสตรีม HTTP แบบคลาสสิก: ใช้การเข้ารหัสการถ่ายโอนแบบ chunked เพื่อส่งข้อมูลเป็นชิ้นส่วน
    • MCP Streaming: ใช้ระบบการแจ้งเตือนที่มีโครงสร้างพร้อมโปรโตคอล JSON-RPC

  • รูปแบบข้อความ:

    • HTTP แบบคลาสสิก: ชิ้นส่วนข้อความธรรมดาพร้อมบรรทัดใหม่
    • MCP: วัตถุ LoggingMessageNotification ที่มีโครงสร้างพร้อมเมตาดาต้า

  • การใช้งานไคลเอนต์:

    • HTTP แบบคลาสสิก: ไคลเอนต์ง่าย ๆ ที่ประมวลผลการตอบสนองแบบสตรีม
    • MCP: ไคลเอนต์ที่ซับซ้อนมากขึ้นพร้อมตัวจัดการข้อความเพื่อประมวลผลข้อความประเภทต่าง ๆ

  • การอัปเดตความคืบหน้า:

    • HTTP แบบคลาสสิก: ความคืบหน้าเป็นส่วนหนึ่งของสตรีมการตอบสนองหลัก
    • MCP: ความคืบหน้าถูกส่งผ่านข้อความแจ้งเตือนแยกต่างหากในขณะที่การตอบสนองหลักมาถึงในตอนท้าย

คำแนะนำ

มีบางสิ่งที่เราแนะนำเมื่อพูดถึงการเลือกใช้งานการสตรีมแบบคลาสสิก (เป็น endpoint ที่เราแสดงให้คุณเห็นด้านบนโดยใช้ /stream) กับการเลือกการสตรีมผ่าน MCP

  • สำหรับความต้องการการสตรีมง่าย ๆ: การสตรีม HTTP แบบคลาสสิกนั้นง่ายต่อการใช้งานและเพียงพอสำหรับความต้องการการสตรีมพื้นฐาน
  • สำหรับแอปพลิเคชันที่ซับซ้อนและโต้ตอบได้: MCP Streaming ให้แนวทางที่มีโครงสร้างมากขึ้นพร้อมเมตาดาต้าที่สมบูรณ์ยิ่งขึ้นและการแยกการแจ้งเตือนออกจากผลลัพธ์สุดท้าย
  • สำหรับแอปพลิเคชัน AI: ระบบการแจ้งเตือนของ MCP มีประโยชน์อย่างยิ่งสำหรับงาน AI ที่ใช้เวลานานซึ่งคุณต้องการแจ้งให้ผู้ใช้ทราบถึงความคืบหน้า

การสตรีมใน MCP

โอเค คุณได้เห็นคำแนะนำและการเปรียบเทียบเกี่ยวกับความแตกต่างระหว่างการสตรีมแบบคลาสสิกและการสตรีมใน MCP แล้ว มาดูรายละเอียดกันว่าคุณสามารถใช้การสตรีมใน MCP ได้อย่างไร

การทำความเข้าใจวิธีการทำงานของการสตรีมภายในกรอบ MCP เป็นสิ่งสำคัญสำหรับการสร้างแอปพลิเคชันที่ตอบสนองซึ่งให้ข้อเสนอแนะแบบเรียลไทม์แก่ผู้ใช้ระหว่างการดำเนินการที่ใช้เวลานาน

ใน MCP การสตรีมไม่ได้เกี่ยวกับการส่งการตอบสนองหลักเป็นชิ้นส่วน แต่เกี่ยวกับการส่ง การแจ้งเตือน ไปยังไคลเอนต์ในขณะที่เครื่องมือกำลังประมวลผลคำขอ การแจ้งเตือนเหล่านี้สามารถรวมการอัปเดตความคืบหน้า บันทึก หรือเหตุการณ์อื่น ๆ

วิธีการทำงาน

ผลลัพธ์หลักยังคงถูกส่งเป็นการตอบสนองเดียว อย่างไรก็ตาม การแจ้งเตือนสามารถส่งเป็นข้อความแยกต่างหากระหว่างการประมวลผลและอัปเดตไคลเอนต์แบบเรียลไทม์ ไคลเอนต์ต้องสามารถจัดการและแสดงการแจ้งเตือนเหล่านี้ได้

การแจ้งเตือนคืออะไร?

เราได้กล่าวถึง "การแจ้งเตือน" แล้ว การแจ้งเตือนหมายถึงอะไรในบริบทของ MCP?

การแจ้งเตือนคือข้อความที่ส่งจากเซิร์ฟเวอร์ไปยังไคลเอนต์เพื่อแจ้งเกี่ยวกับความคืบหน้า สถานะ หรือเหตุการณ์อื่น ๆ ระหว่างการดำเนินการที่ใช้เวลานาน การแจ้งเตือนช่วยปรับปรุงความโปร่งใสและประสบการณ์ของผู้ใช้

ตัวอย่างเช่น ไคลเอนต์ควรส่งการแจ้งเตือนเมื่อการจับมือครั้งแรกกับเซิร์ฟเวอร์เสร็จสิ้น

การแจ้งเตือนมีลักษณะดังนี้ในรูปแบบข้อความ JSON:

{
  jsonrpc: "2.0";
  method: string;
  params?: {
    [key: string]: unknown;
  };
}

การแจ้งเตือนเป็นส่วนหนึ่งของหัวข้อใน MCP ที่เรียกว่า "Logging"

เพื่อให้การบันทึกทำงาน เซิร์ฟเวอร์ต้องเปิดใช้งานเป็นฟีเจอร์/ความสามารถดังนี้:

{
  "capabilities": {
    "logging": {}
  }
}

Note

ขึ้นอยู่กับ SDK ที่ใช้ การบันทึกอาจเปิดใช้งานโดยค่าเริ่มต้น หรือคุณอาจต้องเปิดใช้งานอย่างชัดเจนในการกำหนดค่าเซิร์ฟเวอร์ของคุณ

มีประเภทการแจ้งเตือนที่แตกต่างกัน:

ระดับ คำอธิบาย กรณีการใช้งานตัวอย่าง
debug ข้อมูลการดีบักโดยละเอียด จุดเข้า/ออกของฟังก์ชัน
info ข้อความข้อมูลทั่วไป การอัปเดตความคืบหน้าของการดำเนินการ
notice เหตุการณ์ปกติแต่สำคัญ การเปลี่ยนแปลงการกำหนดค่า
warning เงื่อนไขการเตือน การใช้ฟีเจอร์ที่เลิกใช้แล้ว
error เงื่อนไขข้อผิดพลาด ความล้มเหลวของการดำเนินการ
critical เงื่อนไขวิกฤต ความล้มเหลวของส่วนประกอบระบบ
alert ต้องดำเนินการทันที ตรวจพบการเสียหายของข้อมูล
emergency ระบบไม่สามารถใช้งานได้ ความล้มเหลวของระบบทั้งหมด

การใช้งานการแจ้งเตือนใน MCP

ในการใช้งานการแจ้งเตือนใน MCP คุณต้องตั้งค่าทั้งฝั่งเซิร์ฟเวอร์และไคลเอนต์เพื่อจัดการการอัปเดตแบบเรียลไทม์ สิ่งนี้ช่วยให้แอปพลิเคชันของคุณให้ข้อเสนอแนะทันทีแก่ผู้ใช้ระหว่างการดำเนินการที่ใช้เวลานาน

ฝั่งเซิร์ฟเวอร์: การส่งการแจ้งเตือน

เริ่มต้นด้วยฝั่งเซิร์ฟเวอร์ ใน MCP คุณกำหนดเครื่องมือที่สามารถส่งการแจ้งเตือนในขณะที่ประมวลผลคำขอ เซิร์ฟเวอร์ใช้วัตถุ context (โดยปกติคือ ctx) เพื่อส่งข้อความไปยังไคลเอนต์

Python

@mcp.tool(description="A tool that sends progress notifications")
async def process_files(message: str, ctx: Context) -> TextContent:
    await ctx.info("Processing file 1/3...")
    await ctx.info("Processing file 2/3...")
    await ctx.info("Processing file 3/3...")
    return TextContent(type="text", text=f"Done: {message}")

ในตัวอย่างก่อนหน้า เครื่องมือ process_files ส่งการแจ้งเตือนสามครั้งไปยังไคลเอนต์ในขณะที่ประมวลผลแต่ละไฟล์ วิธี ctx.info() ถูกใช้เพื่อส่งข้อความข้อมูล

นอกจากนี้ เพื่อเปิดใช้งานการแจ้งเตือน ตรวจสอบให้แน่ใจว่าเซิร์ฟเวอร์ของคุณใช้การขนส่งแบบสตรีม (เช่น streamable-http) และไคลเอนต์ของคุณใช้งานตัวจัดการข้อความเพื่อประมวลผลการแจ้งเตือน นี่คือวิธีตั้งค่าเซิร์ฟเวอร์ให้ใช้การขนส่ง streamable-http:

mcp.run(transport="streamable-http")

.NET

[Tool("A tool that sends progress notifications")]
public async Task<TextContent> ProcessFiles(string message, ToolContext ctx)
{
    await ctx.Info("Processing file 1/3...");
    await ctx.Info("Processing file 2/3...");
    await ctx.Info("Processing file 3/3...");
    return new TextContent
    {
        Type = "text",
        Text = $"Done: {message}"
    };
}

ในตัวอย่าง .NET นี้ เครื่องมือ ProcessFiles ถูกตกแต่งด้วยแอตทริบิวต์ Tool และส่งการแจ้งเตือนสามครั้งไปยังไคลเอนต์ในขณะที่ประมวลผลแต่ละไฟล์ วิธี ctx.Info() ถูกใช้เพื่อส่งข้อความข้อมูล

เพื่อเปิดใช้งานการแจ้งเตือนในเซิร์ฟเวอร์ MCP .NET ของคุณ ตรวจสอบให้แน่ใจว่าคุณใช้การขนส่งแบบสตรีม:

var builder = McpBuilder.Create();
await builder
    .UseStreamableHttp() // Enable streamable HTTP transport
    .Build()
    .RunAsync();

ฝั่งไคลเอนต์: การรับการแจ้งเตือน

ไคลเอนต์ต้องใช้งานตัวจัดการข้อความเพื่อประมวลผลและแสดงการแจ้งเตือนเมื่อมาถึง

Python

async def message_handler(message):
    if isinstance(message, types.ServerNotification):
        print("NOTIFICATION:", message)
    else:
        print("SERVER MESSAGE:", message)

async with ClientSession(
   read_stream, 
   write_stream,
   logging_callback=logging_collector,
   message_handler=message_handler,
) as session:

ในโค้ดก่อนหน้า ฟังก์ชัน message_handler ตรวจสอบว่าข้อความที่เข้ามาเป็นการแจ้งเตือนหรือไม่ หากใช่ จะพิมพ์การแจ้งเตือน มิฉะนั้นจะประมวลผลเป็นข้อความเซิร์ฟเวอร์ปกติ นอกจากนี้ โปรดสังเกตว่า ClientSession ถูกเริ่มต้นด้วย message_handler เพื่อจัดการการแจ้งเตือนที่เข้ามา

.NET

// Define a message handler
void MessageHandler(IJsonRpcMessage message)
{
    if (message is ServerNotification notification)
    {
        Console.WriteLine($"NOTIFICATION: {notification}");
    }
    else
    {
        Console.WriteLine($"SERVER MESSAGE: {message}");
    }
}

// Create and use a client session with the message handler
var clientOptions = new ClientSessionOptions
{
    MessageHandler = MessageHandler,
    LoggingCallback = (level, message) => Console.WriteLine($"[{level}] {message}")
};

using var client = new ClientSession(readStream, writeStream, clientOptions);
await client.InitializeAsync();

// Now the client will process notifications through the MessageHandler

ในตัวอย่าง .NET นี้ ฟังก์ชัน MessageHandler ตรวจสอบว่าข้อความที่เข้ามาเป็นการแจ้งเตือนหรือไม่ หากใช่ จะพิมพ์การแจ้งเตือน มิฉะนั้นจะประมวลผลเป็นข้อความเซิร์ฟเวอร์ปกติ ClientSession ถูกเริ่มต้นด้วยตัวจัดการข้อความผ่าน ClientSessionOptions

เพื่อเปิดใช้งานการแจ้งเตือน ตรวจสอบให้แน่ใจว่าเซิร์ฟเวอร์ของคุณใช้การขนส่งแบบสตรีม (เช่น streamable-http) และไคลเอนต์ของคุณใช้งานตัวจัดการข้อความเพื่อประมวลผลการแจ้งเตือน

การแจ้งเตือนความคืบหน้าและสถานการณ์

ส่วนนี้อธิบายแนวคิดของการแจ้งเตือนความคืบหน้าใน MCP เหตุใดจึงสำคัญ และวิธีการใช้งานโดยใช้ Streamable HTTP คุณจะพบการมอบหมายเชิงปฏิบัติเพื่อเสริมสร้างความเข้าใจของคุณ

การแจ้งเตือนความคืบ มีสองเหตุผลสำคัญที่ควรอัปเกรดจาก SSE เป็น Streamable HTTP:

  • Streamable HTTP มีความสามารถในการปรับขนาดที่ดีกว่า, ความเข้ากันได้ที่มากกว่า, และรองรับการแจ้งเตือนที่หลากหลายกว่า SSE
  • เป็นวิธีการส่งข้อมูลที่แนะนำสำหรับแอปพลิเคชัน MCP ใหม่

ขั้นตอนการย้ายระบบ

นี่คือวิธีการย้ายจาก SSE ไปยัง Streamable HTTP ในแอปพลิเคชัน MCP ของคุณ:

  • อัปเดตโค้ดฝั่งเซิร์ฟเวอร์ เพื่อใช้ transport="streamable-http" ใน mcp.run()
  • อัปเดตโค้ดฝั่งไคลเอนต์ เพื่อใช้ streamablehttp_client แทน SSE client
  • สร้างตัวจัดการข้อความ ในไคลเอนต์เพื่อประมวลผลการแจ้งเตือน
  • ทดสอบความเข้ากันได้ กับเครื่องมือและเวิร์กโฟลว์ที่มีอยู่

การรักษาความเข้ากันได้

แนะนำให้รักษาความเข้ากันได้กับ SSE client ที่มีอยู่ในระหว่างกระบวนการย้ายระบบ นี่คือกลยุทธ์บางอย่าง:

  • คุณสามารถรองรับทั้ง SSE และ Streamable HTTP โดยการใช้งานทั้งสองวิธีบน endpoints ที่แตกต่างกัน
  • ค่อยๆ ย้ายไคลเอนต์ไปยังวิธีการส่งข้อมูลใหม่

ความท้าทาย

ตรวจสอบให้แน่ใจว่าคุณจัดการกับความท้าทายต่อไปนี้ในระหว่างการย้ายระบบ:

  • การอัปเดตไคลเอนต์ทั้งหมด
  • การจัดการความแตกต่างในการส่งการแจ้งเตือน

ข้อควรพิจารณาด้านความปลอดภัย

ความปลอดภัยควรเป็นสิ่งสำคัญที่สุดเมื่อใช้งานเซิร์ฟเวอร์ โดยเฉพาะอย่างยิ่งเมื่อใช้วิธีการส่งข้อมูลผ่าน HTTP เช่น Streamable HTTP ใน MCP

เมื่อใช้งานเซิร์ฟเวอร์ MCP ด้วยวิธีการส่งข้อมูลผ่าน HTTP ความปลอดภัยจะกลายเป็นเรื่องสำคัญที่ต้องให้ความสนใจอย่างรอบคอบต่อช่องทางการโจมตีและกลไกการป้องกันต่างๆ

ภาพรวม

ความปลอดภัยเป็นสิ่งสำคัญเมื่อเปิดเผยเซิร์ฟเวอร์ MCP ผ่าน HTTP Streamable HTTP เพิ่มช่องทางการโจมตีใหม่และต้องการการตั้งค่าที่รอบคอบ

นี่คือข้อควรพิจารณาด้านความปลอดภัยที่สำคัญ:

  • การตรวจสอบ Header Origin: ตรวจสอบ Origin header เสมอเพื่อป้องกันการโจมตี DNS rebinding
  • การผูกกับ Localhost: สำหรับการพัฒนาในเครื่อง ให้ผูกเซิร์ฟเวอร์กับ localhost เพื่อหลีกเลี่ยงการเปิดเผยต่ออินเทอร์เน็ตสาธารณะ
  • การตรวจสอบสิทธิ์: ใช้การตรวจสอบสิทธิ์ (เช่น API keys, OAuth) สำหรับการใช้งานในสภาพแวดล้อมการผลิต
  • CORS: ตั้งค่านโยบาย Cross-Origin Resource Sharing (CORS) เพื่อจำกัดการเข้าถึง
  • HTTPS: ใช้ HTTPS ในการผลิตเพื่อเข้ารหัสข้อมูล

แนวทางปฏิบัติที่ดีที่สุด

นอกจากนี้ นี่คือแนวทางปฏิบัติที่ดีที่สุดที่ควรปฏิบัติตามเมื่อใช้งานความปลอดภัยในเซิร์ฟเวอร์ MCP streaming:

  • อย่าไว้วางใจคำขอที่เข้ามาโดยไม่มีการตรวจสอบ
  • บันทึกและตรวจสอบการเข้าถึงและข้อผิดพลาดทั้งหมด
  • อัปเดต dependencies อย่างสม่ำเสมอเพื่อแก้ไขช่องโหว่ด้านความปลอดภัย

ความท้าทาย

คุณจะพบกับความท้าทายบางอย่างเมื่อใช้งานความปลอดภัยในเซิร์ฟเวอร์ MCP streaming:

  • การสร้างสมดุลระหว่างความปลอดภัยและความง่ายในการพัฒนา
  • การรักษาความเข้ากันได้กับสภาพแวดล้อมไคลเอนต์ที่หลากหลาย

งาน: สร้างแอป MCP Streaming ของคุณเอง

สถานการณ์: สร้างเซิร์ฟเวอร์และไคลเอนต์ MCP ที่เซิร์ฟเวอร์ประมวลผลรายการของไอเท็ม (เช่น ไฟล์หรือเอกสาร) และส่งการแจ้งเตือนสำหรับแต่ละไอเท็มที่ประมวลผล ไคลเอนต์ควรแสดงการแจ้งเตือนแต่ละรายการเมื่อมาถึง

ขั้นตอน:

  1. สร้างเครื่องมือเซิร์ฟเวอร์ที่ประมวลผลรายการและส่งการแจ้งเตือนสำหรับแต่ละไอเท็ม
  2. สร้างไคลเอนต์ที่มีตัวจัดการข้อความเพื่อแสดงการแจ้งเตือนแบบเรียลไทม์
  3. ทดสอบการใช้งานของคุณโดยการรันทั้งเซิร์ฟเวอร์และไคลเอนต์ และสังเกตการแจ้งเตือน

Solution

การอ่านเพิ่มเติมและสิ่งที่ควรทำต่อไป

เพื่อดำเนินการต่อในเส้นทาง MCP streaming และขยายความรู้ของคุณ ส่วนนี้ให้ทรัพยากรเพิ่มเติมและขั้นตอนถัดไปที่แนะนำสำหรับการสร้างแอปพลิเคชันขั้นสูงมากขึ้น

การอ่านเพิ่มเติม

สิ่งที่ควรทำต่อไป

  • ลองสร้างเครื่องมือ MCP ขั้นสูงที่ใช้การส่งข้อมูลแบบสตรีมสำหรับการวิเคราะห์แบบเรียลไทม์, แชท, หรือการแก้ไขร่วมกัน
  • สำรวจการผสาน MCP streaming กับเฟรมเวิร์กฝั่งหน้า (React, Vue, ฯลฯ) เพื่ออัปเดต UI แบบสด
  • ถัดไป: Utilising AI Toolkit for VSCode

ข้อจำกัดความรับผิดชอบ:
เอกสารนี้ได้รับการแปลโดยใช้บริการแปลภาษา AI Co-op Translator แม้ว่าเราจะพยายามให้การแปลมีความถูกต้อง แต่โปรดทราบว่าการแปลอัตโนมัติอาจมีข้อผิดพลาดหรือความไม่ถูกต้อง เอกสารต้นฉบับในภาษาดั้งเดิมควรถือเป็นแหล่งข้อมูลที่เชื่อถือได้ สำหรับข้อมูลที่สำคัญ แนะนำให้ใช้บริการแปลภาษามนุษย์ที่เป็นมืออาชีพ เราไม่รับผิดชอบต่อความเข้าใจผิดหรือการตีความที่ผิดพลาดซึ่งเกิดจากการใช้การแปลนี้