Skip to content

Latest commit

 

History

History
518 lines (366 loc) · 41.6 KB

README.md

File metadata and controls

518 lines (366 loc) · 41.6 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):

Python

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):

Python

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:

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

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

ความแตกต่างระหว่างการสตรีมแบบ "คลาสสิก" กับ MCP Streaming สามารถแสดงได้ดังนี้:

คุณสมบัติ การสตรีม HTTP แบบคลาสสิก MCP Streaming (การแจ้งเตือน)
การตอบสนองหลัก แบ่งเป็นชิ้น ตอบครั้งเดียวตอนจบ
การอัปเดตความคืบหน้า ส่งเป็นชิ้นข้อมูล ส่งเป็นการแจ้งเตือน
ความต้องการของไคลเอนต์ ต้องประมวลผลสตรีม ต้องมีตัวจัดการข้อความ
กรณีการใช้งาน ไฟล์ใหญ่, สตรีมโทเค็น 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"

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

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

Note

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

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

ระดับ คำอธิบาย ตัวอย่างการใช้งาน
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 ของคุณ ให้แน่ใจว่าใช้การขนส่งแบบสตรีม:

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 พร้อมแบบฝึกหัดเชิงปฏิบัติเพื่อเสริมความเข้าใจ

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

ตัวอย่าง:


"Processing document 1/10"
"Processing document 2/10"
...
"Processing complete!"

ทำไมต้องใช้การแจ้งเตือนความคืบหน้า?

การแจ้งเตือนความคืบหน้ามีความสำคัญด้วยเหตุผลหลายประการ:

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

ทำไมต้องอัปเกรด?

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

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

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

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

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

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

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

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

ความท้าทาย

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

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

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

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

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

ภาพรวม

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

นี่คือข้อควรพิจารณาด้านความปลอดภัยหลักๆ:

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

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

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

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

ความท้าทาย

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

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

แบบฝึกหัด: สร้างแอป MCP สตรีมมิ่งของคุณเอง

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

ขั้นตอน:

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

Solution

อ่านเพิ่มเติม & ก้าวต่อไป

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

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

ก้าวต่อไป

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

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