Files

T

wehub-resource-sync c275ba2868 chore: import upstream snapshot with attribution

2026-07-13 13:31:35 +08:00

31 KiB

Raw Permalink Blame History

التدفق عبر HTTPS مع بروتوكول سياق النموذج (MCP)

يوفر هذا الفصل دليلًا شاملاً لتنفيذ تدفق آمن، وقابل للتوسع، وفوري باستخدام بروتوكول سياق النموذج (MCP) عبر HTTPS. يغطي الدوافع وراء التدفق، وآليات النقل المتاحة، وكيفية تنفيذ HTTP قابل للتدفق في MCP، وأفضل ممارسات الأمان، والهجرة من SSE، والإرشادات العملية لبناء تطبيقات MCP الخاصة بك.

آليات النقل والتدفق في MCP

يستكشف هذا القسم آليات النقل المختلفة المتاحة في MCP ودورها في تمكين قدرات التدفق للتواصل الفوري بين العملاء والخوادم.

ما هي آلية النقل؟

تعرف آلية النقل كيف يتم تبادل البيانات بين العميل والخادم. يدعم MCP عدة أنواع من النقل لتناسب بيئات ومتطلبات مختلفة:

stdio: الإدخال/الإخراج القياسي، مناسب للأدوات المحلية وقائمة الأوامر (CLI). بسيط لكنه غير مناسب للويب أو السحابة.
SSE (أحداث يرسلها الخادم): تسمح للخادم بإرسال تحديثات فورية للعملاء عبر HTTP. جيدة لواجهات الويب، لكنها محدودة في التوسع والمرونة. اعتبارًا من مواصفة MCP بتاريخ 2025-06-18، تم إهمال النقل المنفصل SSE واستبداله بالنقل عبر "HTTP القابل للتدفق".
HTTP القابل للتدفق: نقل تدفق حديث قائم على HTTP، يدعم الإشعارات وتوسع أفضل. موصى به لمعظم سيناريوهات الإنتاج والسحابة.

جدول المقارنة

اطلع على جدول المقارنة أدناه لفهم الفروقات بين هذه الآليات:

النقل	التحديثات الفورية	التدفق	القابلية للتوسع	حالة الاستخدام
stdio	لا	لا	منخفض	أدوات CLI المحلية
SSE	نعم	نعم	متوسط	الويب، التحديثات الفورية
HTTP القابل للتدفق	نعم	نعم	عالي	السحابة، تعدد العملاء

نصيحة: اختيار آلية النقل المناسبة يؤثر على الأداء، والتوسع، وتجربة المستخدم. HTTP القابل للتدفق موصى به للتطبيقات الحديثة والقابلة للتوسع والمهيئة للسحابة.

لاحظ آليات النقل stdio و SSE التي تم عرضها في الفصول السابقة وكيف أن HTTP القابل للتدفق هو النقل الذي يغطيه هذا الفصل.

التدفق: المفاهيم والدوافع

فهم المفاهيم الأساسية والدوافع وراء التدفق ضروري لتنفيذ أنظمة تواصل فورية فعالة.

التدفق هو تقنية في برمجة الشبكات تسمح بإرسال واستقبال البيانات على شكل أجزاء صغيرة يمكن إدارتها أو كسلسلة من الأحداث، بدلاً من الانتظار حتى يكون الرد كاملاً جاهزًا. هذه التقنية مفيدة بشكل خاص لـ:

الملفات أو مجموعات البيانات الكبيرة.
التحديثات الفورية (مثل الشات، أعمدة التقدم).
العمليات الطويلة التي تريد إبقاء المستخدم على اطلاع.

إليك ما تحتاج إلى معرفته عن التدفق على مستوى عالٍ:

البيانات تُرسل تدريجيًا وليس دفعة واحدة.
يمكن للعميل معالجة البيانات حال وصولها.
يقلل من زمن الاستجابة المدرك ويحسن تجربة المستخدم.

لماذا نستخدم التدفق؟

الأسباب لاستخدام التدفق هي:

يحصل المستخدمون على ردود فعل فورية، وليس فقط في النهاية.
يمكّن التطبيقات الفورية وواجهات الاستخدام السريعة الاستجابة.
استخدام أكثر كفاءة لموارد الشبكة والحوسبة.

مثال بسيط: خادم وعميل تدفق HTTP

إليك مثالًا بسيطًا على كيفية تنفيذ التدفق:

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

العميل (بايثون، باستخدام 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).
نوع المحتوى عادة يكون text/event-stream أو application/octet-stream.

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));
    }
}

العميل (جافا، باستخدام 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();
    }
}

ملاحظات تنفيذ جافا:

يستخدم تكديس Spring Boot التفاعلي مع Flux من أجل التدفق.
يوفر ServerSentEvent تدفق أحداث منظم مع أنواع الأحداث.
يمكن لـ WebClient مع bodyToFlux() استهلاك التدفق التفاعلي.
تحاكي delayElements() وقت المعالجة بين الأحداث.
يمكن أن تحتوي الأحداث على أنواع (info، result) لتحسين معالجة العميل.

مقارنة: التدفق الكلاسيكي مقابل تدفق MCP

يمكن توضيح الفروق بين كيفية عمل التدفق "الكلاسيكي" مقابل MCP بالشكل التالي:

الخاصية	تدفق HTTP الكلاسيكي	تدفق MCP (الإشعارات)
الاستجابة الرئيسية	مجزأة	واحدة، في النهاية
تحديثات التقدم	تُرسل كقطع بيانات	تُرسل كإشعارات
متطلبات العميل	يجب معالجة التدفق	يجب تنفيذ معالج رسائل
حالة الاستخدام	ملفات كبيرة، تدفقات رموز AI	التقدم، السجلات، ردود فعل فورية

الاختلافات الرئيسية الملحوظة

بالإضافة إلى ذلك، إليك بعض الفروقات الرئيسية:

نمط الاتصال:
- التدفق التقليدي عبر HTTP: يستخدم ترميز النقل المجزأ لإرسال البيانات على شكل قطع.
- تدفق MCP: يستخدم نظام إشعارات منظم مع بروتوكول JSON-RPC.
صيغة الرسالة:
- HTTP الكلاسيكي: قطع نصية عادية مع فواصل أسطر.
- MCP: كائنات LoggingMessageNotification منظمة مع بيانات وصفية.
تنفيذ العميل:
- HTTP الكلاسيكي: عميل بسيط يعالج استجابات التدفق.
- MCP: عميل أكثر تعقيدًا مع معالج رسائل لمعالجة أنواع مختلفة من الرسائل.
تحديثات التقدم:
- HTTP الكلاسيكي: التقدم جزء من تدفق الاستجابة الرئيسي.
- MCP: يُرسل التقدم عبر رسائل إشعار منفصلة بينما تأتي الاستجابة الرئيسية في النهاية.

توصيات

هناك بعض التوصيات عند الاختيار بين تنفيذ التدفق الكلاسيكي (كنقطة نهاية مثل التي عرضناها باستخدام /stream) مقابل اختيار التدفق عبر MCP.

للحاجات البسيطة للتدفق: تدفق HTTP الكلاسيكي أبسط في التنفيذ وكاف للحاجات الأساسية.
للتطبيقات المعقدة والتفاعلية: يوفر تدفق MCP نهجًا أكثر تنظيمًا مع بيانات وصفية أغنى وفصل بين الإشعارات والنتائج النهائية.
لتطبيقات AI: نظام إشعارات MCP مفيد بشكل خاص للمهام الطويلة حيث تريد إبقاء المستخدمين على اطلاع بالتقدم.

التدفق في 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، تعرف أدوات يمكنها إرسال الإشعارات أثناء معالجة الطلبات. يستخدم الخادم كائن السياق (عادة 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، ولماذا هي مهمة، وكيفية تنفيذها باستخدام HTTP القابل للتدفق. ستجد أيضًا مهمة عملية لتعزيز فهمك.

إشعارات التقدم هي رسائل فورية يُرسلها الخادم إلى العميل أثناء العمليات الطويلة. بدلاً من الانتظار حتى انتهاء العملية بالكامل، يبقي الخادم العميل محدثًا بالحالة الحالية. هذا يحسن الشفافية وتجربة المستخدم ويجعل التتبع أسهل.

مثال:


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

لماذا نستخدم إشعارات التقدم؟

إشعارات التقدم ضرورية لعدة أسباب:

تجربة مستخدم أفضل: يرى المستخدمون التحديثات أثناء تقدم العمل، وليس فقط في النهاية.
ردود فعل فورية: يمكن للعملاء عرض أشرطة تقدم أو سجلات، مما يجعل التطبيق يبدو سريع الاستجابة.
سهولة التتبع والمراقبة: يمكن للمطورين والمستخدمين رؤية أين قد تكون العملية بطيئة أو متوقفة.

كيف تنفذ إشعارات التقدم

إليك كيف يمكنك تنفيذ إشعارات التقدم في MCP:

على الخادم: استخدم ctx.info() أو ctx.log() لإرسال إشعارات أثناء معالجة كل عنصر. هذا يرسل رسالة إلى العميل قبل أن تكون النتيجة الرئيسية جاهزة.
على العميل: نفذ معالج رسائل يستمع للرسائل ويعرض الإشعارات عند وصولها. يميز هذا المعالج بين الإشعارات والنتيجة النهائية.

مثال الخادم:

Python

@mcp.tool(description="A tool that sends progress notifications")
async def process_files(message: str, ctx: Context) -> TextContent:
    for i in range(1, 11):
        await ctx.info(f"Processing document {i}/10")
    await ctx.info("Processing complete!")
    return TextContent(type="text", text=f"Done: {message}")

مثال العميل:

Python

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

اعتبارات الأمان

عند تنفيذ خوادم MCP مع نقل HTTP، يصبح الأمان مسألة حاسمة تتطلب اهتمامًا دقيقًا لعدة نقاط ضعف وهجمات محتملة وآليات الحماية.

نظرة عامة

الأمان أمر حيوي عند تعريض خوادم MCP عبر HTTP. يُدخل HTTP القابل للتدفق أسطح هجوم جديدة ويتطلب تكوينًا دقيقًا.

نقاط رئيسية

التحقق من رأس Origin: تحقق دائمًا من رأس Origin لمنع هجمات إعادة ربط DNS.
الربط على localhost: للتطوير المحلي، اربط الخوادم على localhost لتجنب تعريضها للإنترنت العام.
المصادقة: طبق المصادقة (مثل مفاتيح API، OAuth) لنشر الإنتاج.
CORS: قم بتكوين سياسات مشاركة الموارد بين الأصول لتقييد الوصول.
HTTPS: استخدم HTTPS في الإنتاج لتشفير الحركة.

أفضل الممارسات

لا تثق بالطلبات الواردة دون تحقق.
سجل ورصد كل الوصول والأخطاء.
حدث الاعتمادات بانتظام لسد ثغرات الأمان.

التحديات

تحقيق التوازن بين الأمان وسهولة التطوير
ضمان التوافق مع بيئات العملاء المختلفة

الترقية من SSE إلى Streamable HTTP

بالنسبة للتطبيقات التي تستخدم حاليًا أحداث الخادم المرسلة (SSE)، يوفر الانتقال إلى Streamable HTTP قدرات محسنة واستدامة أفضل على المدى الطويل لتطبيقات MCP الخاصة بك.

لماذا الترقية؟

هناك سببان مهمان للترقية من 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: قم دائمًا بالتحقق من رأس Origin لمنع هجمات ربط DNS.
ربط localhost: للتطوير المحلي، اربط الخوادم بـlocalhost لتجنب تعريضها للإنترنت العام.
المصادقة: قم بتنفيذ المصادقة (مثل مفاتيح API، OAuth) لنشرات الإنتاج.
CORS: قم بتكوين سياسات مشاركة الموارد عبر الأصل (CORS) لتقييد الوصول.
HTTPS: استخدم HTTPS في الإنتاج لتشفير حركة المرور.

أفضل الممارسات

بالإضافة إلى ذلك، فيما يلي بعض أفضل الممارسات الواجب اتباعها عند تنفيذ الأمان في خادم البث الخاص بك في MCP:

لا تثق أبدًا بالطلبات الواردة دون تحقق.
سجل وراقب كل عمليات الوصول والأخطاء.
حدث التبعيات بانتظام لسد ثغرات الأمان.

التحديات

ستواجه بعض التحديات عند تنفيذ الأمان في خوادم البث MCP:

تحقيق التوازن بين الأمان وسهولة التطوير
ضمان التوافق مع بيئات العملاء المختلفة

المهمة: بناء تطبيق MCP للبث الخاص بك

السيناريو: قم ببناء خادم وعميل MCP حيث يقوم الخادم بمعالجة قائمة من العناصر (مثل الملفات أو المستندات) ويرسل إشعارًا عن كل عنصر تتم معالجته. يجب أن يعرض العميل كل إشعار فور وصوله.

الخطوات:

نفذ أداة خادم تعالج قائمة وتُرسل إشعارات لكل عنصر.
نفذ عميلًا مع معالج رسائل لعرض الإشعارات في الوقت الحقيقي.
اختبر تطبيقك بتشغيل كل من الخادم والعميل، ومراقبة الإشعارات.

الحل

المزيد من القراءة وماذا بعد؟

للاستمرار في رحلتك مع بث MCP وتوسيع معرفتك، يقدم هذا القسم موارد إضافية وخطوات مقترحة للبناء على تطبيقات أكثر تقدمًا.

ماذا بعد؟

حاول بناء أدوات MCP أكثر تقدمًا تستخدم البث للتحليلات في الوقت الحقيقي، الدردشة، أو التحرير التعاوني.
استكشف دمج بث MCP مع أُطُر عمل الواجهة الأمامية (React، Vue، إلخ) لتحديثات واجهة المستخدم الحية.
التالي: استخدام مجموعة أدوات AI لـ VSCode

تنويه: تمت ترجمة هذا المستند باستخدام خدمة الترجمة بالذكاء الاصطناعي Co-op Translator. بينما نسعى للدقة، يرجى العلم أن الترجمات الآلية قد تحتوي على أخطاء أو عدم دقة. يجب اعتبار المستند الأصلي بلغته الأصلية المصدر الرسمي والمعتمد. للمعلومات الهامة، يُنصح بالاستعانة بترجمة بشرية محترفة. نحن غير مسؤولين عن أي سوء فهم أو تفسير ناتج عن استخدام هذه الترجمة.

31 KiB Raw Permalink Blame History

التدفق عبر HTTPS مع بروتوكول سياق النموذج (MCP)

آليات النقل والتدفق في MCP

ما هي آلية النقل؟

جدول المقارنة

التدفق: المفاهيم والدوافع

لماذا نستخدم التدفق؟

مثال بسيط: خادم وعميل تدفق HTTP

Python

Java

مقارنة: التدفق الكلاسيكي مقابل تدفق MCP

الاختلافات الرئيسية الملحوظة

توصيات

التدفق في MCP

كيف يعمل

ما هي الإشعارات؟

تنفيذ الإشعارات في MCP

جانب الخادم: إرسال الإشعارات

Python

.NET

جانب العميل: استقبال الإشعارات

Python

.NET

إشعارات التقدم والسيناريوهات

لماذا نستخدم إشعارات التقدم؟

كيف تنفذ إشعارات التقدم

Python

Python

اعتبارات الأمان

نظرة عامة

نقاط رئيسية

أفضل الممارسات

التحديات

الترقية من SSE إلى Streamable HTTP

لماذا الترقية؟

خطوات الترحيل

الحفاظ على التوافق

التحديات

اعتبارات الأمان

نظرة عامة

أفضل الممارسات

التحديات

المهمة: بناء تطبيق MCP للبث الخاص بك

المزيد من القراءة وماذا بعد؟

المزيد من القراءة

ماذا بعد؟

31 KiB

Raw Permalink Blame History