HTTPS Стримінг з протоколом Model Context Protocol (MCP)

Цей розділ надає детальний посібник з впровадження безпечного, масштабованого та реального часу стримінгу з використанням протоколу Model Context Protocol (MCP) через HTTPS. Він охоплює мотивацію для стримінгу, доступні транспортні механізми, як реалізувати стримінг HTTP у MCP, найкращі практики безпеки, міграцію з SSE та практичні рекомендації для створення власних стримінгових додатків MCP.

Транспортні механізми та стримінг у MCP

Цей розділ досліджує різні транспортні механізми, доступні в MCP, та їх роль у забезпеченні можливостей стримінгу для реального часу комунікації між клієнтами та серверами.

Що таке транспортний механізм?

Транспортний механізм визначає, як дані обмінюються між клієнтом і сервером. MCP підтримує кілька типів транспорту для задоволення різних середовищ і вимог:

stdio: Стандартний ввід/вивід, підходить для локальних і CLI-інструментів. Простий, але не підходить для вебу чи хмари.
SSE (Server-Sent Events): Дозволяє серверам надсилати оновлення в реальному часі клієнтам через HTTP. Добре підходить для веб-інтерфейсів, але має обмеження в масштабованості та гнучкості.
Streamable HTTP: Сучасний HTTP-стримінговий транспорт, що підтримує сповіщення та кращу масштабованість. Рекомендується для більшості виробничих і хмарних сценаріїв.

Таблиця порівняння

Ознайомтеся з таблицею порівняння нижче, щоб зрозуміти відмінності між цими транспортними механізмами:

Транспорт	Оновлення в реальному часі	Стримінг	Масштабованість	Сценарій використання
stdio	Ні	Ні	Низька	Локальні CLI-інструменти
SSE	Так	Так	Середня	Веб, оновлення в реальному часі
Streamable HTTP	Так	Так	Висока	Хмара, багатоклієнтські додатки

Порада: Вибір правильного транспорту впливає на продуктивність, масштабованість і досвід користувача. Streamable HTTP рекомендується для сучасних, масштабованих і хмарних додатків.

Зверніть увагу на транспорти stdio та SSE, які були розглянуті в попередніх розділах, і як Streamable HTTP є транспортом, що охоплюється в цьому розділі.

Стримінг: Концепції та мотивація

Розуміння основних концепцій і мотивації стримінгу є важливим для впровадження ефективних систем комунікації в реальному часі.

Стримінг — це техніка в мережевому програмуванні, яка дозволяє надсилати та отримувати дані невеликими, керованими частинами або як послідовність подій, а не чекати, поки весь відповідь буде готовий. Це особливо корисно для:

Великих файлів або наборів даних.
Оновлень у реальному часі (наприклад, чат, індикатори прогресу).
Тривалих обчислень, де потрібно інформувати користувача.

Ось що потрібно знати про стримінг на високому рівні:

Дані доставляються поступово, а не всі одразу.
Клієнт може обробляти дані по мірі їх надходження.
Зменшує сприйняту затримку та покращує досвід користувача.

Чому використовувати стримінг?

Причини використання стримінгу такі:

Користувачі отримують зворотний зв'язок негайно, а не лише в кінці.
Дозволяє створювати додатки в реальному часі та чуйні інтерфейси.
Більш ефективне використання мережевих і обчислювальних ресурсів.

Простий приклад: HTTP-стримінговий сервер і клієнт

Ось простий приклад того, як можна реалізувати стримінг:

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 з Flux для стримінгу.
ServerSentEvent забезпечує структурований стримінг подій з типами подій.
WebClient з bodyToFlux() дозволяє реактивне споживання стримінгу.
delayElements() симулює час обробки між подіями.
Події можуть мати типи (info, result) для кращої обробки клієнтом.

Порівняння: Класичний стримінг vs MCP-стримінг

Відмінності між тим, як стримінг працює "класичним" способом, і тим, як він працює в MCP, можна зобразити так:

Особливість	Класичний HTTP-стримінг	MCP-стримінг (сповіщення)
Основна відповідь	Частинами	Єдина, в кінці
Оновлення прогресу	Надсилаються як частини даних	Надсилаються як сповіщення
Вимоги до клієнта	Повинен обробляти стримінг	Повинен реалізувати обробник повідомлень
Сценарій використання	Великі файли, AI-токени	Прогрес, логи, зворотний зв'язок у реальному часі

Спостережувані ключові відмінності

Додатково, ось деякі ключові відмінності:

Шаблон комунікації:
- Класичний HTTP-стримінг: Використовує просте кодування chunked transfer для передачі даних частинами.
- MCP-стримінг: Використовує структуровану систему сповіщень з протоколом JSON-RPC.
Формат повідомлень:
- Класичний HTTP: Простий текст частинами з новими рядками.
- MCP: Структуровані об'єкти LoggingMessageNotification з метаданими.
Реалізація клієнта:
- Класичний HTTP: Простий клієнт, який обробляє стримінгові відповіді.
- MCP: Більш складний клієнт з обробником повідомлень для обробки різних типів повідомлень.
Оновлення прогресу:
- Класичний HTTP: Прогрес є частиною основного стримінгу відповіді.
- 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 rebinding.
Прив’язка до localhost: Для локальної розробки прив’язуйте сервери до localhost, щоб уникнути їх відкриття для публічного інтернету.
Аутентифікація: Реалізуйте аутентифікацію (наприклад, API-ключі, OAuth) для розгортання у виробничому середовищі.
CORS: Налаштуйте політики Cross-Origin Resource Sharing (CORS), щоб обмежити доступ.
HTTPS: Використовуйте HTTPS у виробничому середовищі для шифрування трафіку.

Найкращі практики

Крім того, ось кілька найкращих практик, яких слід дотримуватися при реалізації безпеки у вашому MCP-сервері потокової передачі:

Ніколи не довіряйте вхідним запитам без перевірки.
Логуйте та моніторьте всі доступи та помилки.
Регулярно оновлюйте залежності, щоб усунути вразливості безпеки.

Виклики

Ви зіткнетеся з деякими викликами при реалізації безпеки у MCP-серверах потокової передачі:

Балансування між безпекою та зручністю розробки
Забезпечення сумісності з різними клієнтськими середовищами

Завдання: Створіть власний потоковий MCP-додаток

Сценарій: Створіть MCP-сервер і клієнт, де сервер обробляє список елементів (наприклад, файлів або документів) і надсилає сповіщення для кожного обробленого елемента. Клієнт повинен відображати кожне сповіщення в реальному часі.

Кроки:

Реалізуйте серверний інструмент, який обробляє список і надсилає сповіщення для кожного елемента.
Реалізуйте клієнт з обробником повідомлень для відображення сповіщень у реальному часі.
Перевірте вашу реалізацію, запустивши сервер і клієнт, і спостерігайте за сповіщеннями.

Solution

Додаткові матеріали та подальші кроки

Щоб продовжити вивчення MCP-потоків і розширити свої знання, цей розділ надає додаткові ресурси та пропонує наступні кроки для створення більш складних додатків.

Додаткові матеріали

Що далі?

Спробуйте створити більш складні MCP-інструменти, які використовують потокову передачу для аналітики в реальному часі, чату або спільного редагування.
Досліджуйте інтеграцію MCP-потоків з фронтенд-фреймворками (React, Vue тощо) для оновлення інтерфейсу в реальному часі.
Далі: Використання AI Toolkit для VSCode

Відмова від відповідальності:
Цей документ було перекладено за допомогою сервісу автоматичного перекладу Co-op Translator. Хоча ми прагнемо до точності, будь ласка, майте на увазі, що автоматичні переклади можуть містити помилки або неточності. Оригінальний документ на його рідній мові слід вважати авторитетним джерелом. Для критичної інформації рекомендується професійний людський переклад. Ми не несемо відповідальності за будь-які непорозуміння або неправильні тлумачення, що виникають у результаті використання цього перекладу.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

HTTPS Стримінг з протоколом Model Context Protocol (MCP)

Транспортні механізми та стримінг у MCP

Що таке транспортний механізм?

Таблиця порівняння

Стримінг: Концепції та мотивація

Чому використовувати стримінг?

Простий приклад: HTTP-стримінговий сервер і клієнт

Python

Java

Порівняння: Класичний стримінг vs MCP-стримінг

Спостережувані ключові відмінності

Рекомендації

Кроки міграції

Підтримка сумісності

Виклики

Міркування щодо безпеки

Огляд

Найкращі практики

Виклики

Завдання: Створіть власний потоковий MCP-додаток

Додаткові матеріали та подальші кроки

Додаткові матеріали

Що далі?

FilesExpand file tree

README.md

Latest commit

History

README.md

File metadata and controls

HTTPS Стримінг з протоколом Model Context Protocol (MCP)

Транспортні механізми та стримінг у MCP

Що таке транспортний механізм?

Таблиця порівняння

Стримінг: Концепції та мотивація

Чому використовувати стримінг?

Простий приклад: HTTP-стримінговий сервер і клієнт

Python

Java

Порівняння: Класичний стримінг vs MCP-стримінг

Спостережувані ключові відмінності

Рекомендації

Кроки міграції

Підтримка сумісності

Виклики

Міркування щодо безпеки

Огляд

Найкращі практики

Виклики

Завдання: Створіть власний потоковий MCP-додаток

Додаткові матеріали та подальші кроки

Додаткові матеріали

Що далі?