В этом руководстве вы увидите:
- История транспортных технологий MCP и причины перехода от SSE к Streamable HTTP.
- Что такое SSE и как он использовался в старых версиях MCP.
- Что такое потоковый HTTP и как он применяется в текущей версии MCP.
- Сводная таблица, сравнивающая SSE и Streamable HTTP.
- Как быть в курсе развития спецификаций протоколов.
Давайте погрузимся!
Немного истории о транспортных протоколах, используемых в MCP
MCP(Modal Context Protocol), один из самых популярных и широко используемых сегодня AI-протоколов, начиная с версии протокола 2025-03-26, заменил транспортный механизм HTTP+SSE на Streamable HTTP. Это ознаменовало значительные изменения в архитектуре протокола.
Давайте лучше поймем это изменение, прежде чем объяснять, что представляют собой эти два транспортных механизма.
Почему протоколам искусственного интеллекта нужны транспортные механизмы
Протоколы искусственного интеллекта, такие как MCP, нуждаются в транспортных механизмах для облегчения обмена информацией между различными компонентами архитектуры протокола.
В частности, MCP использует JSON-RPC 2.0 в качестве формата передачи данных между клиентами и серверами. Для передачи сообщений JSON-RPC используются стандартные транспортные механизмы, такие как HTTP+SSE или Streamable HTTP (среди stdio – для связи по стандартным входам и выходам на локальных серверах).
Эти специализированные транспортные уровни необходимы, потому что традиционная модель HTTP “запрос-ответ” неэффективна для обмена данными между ИИ в реальном времени. Это связано с тем, что обычный HTTP создает большие накладные расходы и задержки из-за частой установки соединения. В отличие от этого, MCP требует непрерывных потоков данных с низкой задержкой – то, для чего предназначены HTTP+SSE и Streamable HTTP.
Почему были внесены изменения
Изначально MCP использовал HTTP+SSE для обеспечения потоковой передачи данных от сервера к клиенту в удаленных сценариях. Однако эти три основных ограничения оправдывали изменения:
- Нет поддержки возобновляемых потоков.
- Требуется, чтобы сервер поддерживал долговременное высокодоступное соединение.
- Позволяет доставлять сообщения сервера только через SSE.
Потоковый HTTP решает эти проблемы. Он обеспечивает связь без статических данных и даже поддерживает обновление SSE по требованию. Это улучшает совместимость с современной инфраструктурой и гарантирует более стабильную и эффективную связь.
Влияние перехода с HTTP+SSE на потоковый HTTP
Переход от HTTP+SSE к Streamable HTTP в качестве транспортного протокола стал важным изменением для MCP. Он внес заметные изменения в реализацию протокола, потребовав адаптации многих сторонних клиентских и серверных библиотек MCP.
Однако на момент написания этой статьи клиенты и серверы MCP могут поддерживать обратную совместимость с устаревшим транспортом HTTP+SSE.
SSE (события, отправляемые сервером)
SSE(Server-Sent Events) – это механизм, позволяющий веб-клиентам получать автоматические обновления с сервера. Эти обновления называются “событиями” и отправляются через одно долговременное HTTP-соединение.
В отличие от WebSockets, SSE является однонаправленным, то есть данные передаются только от сервера к клиенту. SSE работает за счет того, что сервер отправляет поток событий по открытому соединению, обычно оформленному в виде типаtext/event-streamMIME.
Использование HTTP+SSE в MCP
Именно так MCP опирался на SSE в версии 2024-11-05:
Сервер должен предоставить две конечные точки:
- Конечная точка SSE GET, позволяющая клиентам устанавливать соединение и получать сообщения от сервера.
- Обычная конечная точка HTTP POST для отправки клиентами JSON-RPC-сообщений на сервер.
Когда клиент подключается, сервер должен отправить событие конечной точки, содержащее URI, который клиент будет использовать для отправки сообщений. Все клиентские JSON-RPC-сообщения затем отправляются в виде HTTP POST-запросов на этот URI.
Сервер отвечает потоковой передачей событий по открытому SSE-соединению, имитируя постоянный сеанс. В деталях, сообщения сервера доставляются как события сообщений SSE, с содержимым, закодированным в виде JSON в данных события.
При однократном ответе сервер отправляет сообщение и закрывает поток. При непрерывной связи соединение остается открытым.
Плюсы и минусы
Вот основные плюсы и минусы использования SSE в MCP:
👍 Потоковая передача больших результатов: Позволяет отправлять частичные результаты немедленно, избегая задержек, пока инструменты MCP обрабатывают большие данные или ожидают внешних ответов API.
👍 Триггеры, управляемые событиями: Поддержка незапрашиваемых событий сервера для уведомления клиентов об изменениях, с оповещениями или обновлениями состояния.
👍 Простота: Используется стандартный HTTP, не требующий специальных протоколов или сложной настройки.
👎 Только однонаправленный: Данные могут передаваться от серверов к клиентам только по каналу SSE. Клиенты должны использовать отдельные HTTP POST-запросы для отправки сообщений.
👎 Длительное использование ресурсов соединения: Поддержание открытых соединений может потреблять много ресурсов сервера, особенно при масштабировании.
Потоковый HTTP
В контексте MCP потоковый HTTP – это метод потоковой передачи данных между клиентом и сервером с использованием чистого HTTP. Он открывает возможности для общения в реальном времени, не требуя длительных соединений.
Хотя для гибкости и обратной совместимости он по-прежнему может использовать SSE, этот транспортный метод больше не требуется. Это позволяет MCP поддерживать серверы без статического состояния без необходимости поддерживать постоянные соединения высокой доступности.
ℹ️ Extra: Почему потоковый HTTP + опциональный SSE вместо WebSockets?
- Использование WebSockets для простых вызовов RPC без статического состояния приводит к лишним сетевым и операционным затратам.
- Браузеры не могут прикреплять к WebSockets такие заголовки, как
Authorization, и, в отличие от SSE, WebSockets не могут быть реализованы с помощью стандартных инструментов HTTP. - Обновления WebSocket работают только с GET-запросами, что делает потоки на основе POST сложными и более медленными из-за необходимости выполнять шаги по обновлению.
Потоковый HTTP в MCP
В потоковом HTTP-транспорте сервер выступает в роли отдельного процесса, способного обрабатывать множество клиентских соединений. Для связи он использует стандартные запросы HTTP POST и GET.
В качестве опции сервер может использовать SSE для потоковой передачи нескольких сообщений клиенту. Это позволяет использовать как базовые MCP-серверы для простых запросов/ответов, так и серверы с более продвинутыми возможностями, такими как потоковая передача и уведомления от сервера к клиенту в реальном времени.
Сервер должен предоставлять одну конечную точку HTTP (называемую “конечной точкой MCP“), которая поддерживает методы POST и GET.
На диаграмме ниже показан поток обмена данными между клиентами и серверами MCP, использующими потоковый HTTP:
Для поддержки возобновления разорванных соединений и повторной доставки потенциально потерянных сообщений сервер MCP назначает идентификаторы на основе каждого потока. Эти идентификаторы выступают в качестве курсоров в каждом потоке.
Учитывая разнообразие возможных взаимодействий, обратитесь к официальной документации MCP для получения подробной информации о реализации.
Плюсы и минусы
Вот основные преимущества использования Streamable HTTP в MCP:
👍 Поддерживаются серверы Stateless: Устраняет необходимость в постоянных долговременных соединениях.
👍 Обычный HTTP: может быть реализован с помощью любого стандартного HTTP-сервера, не требующего SSE.
👍 Удобство для инфраструктуры: Совместим с распространенным промежуточным ПО HTTP, прокси-серверами и хостинговыми платформами.
👍 Обратная совместимость: Постепенно развивается на базе предыдущего транспорта HTTP+SSE.
👍 Дополнительная потоковая передача: При необходимости серверы могут перейти на SSE для потоковой передачи ответов.
Примечание: На момент написания статьи у транспортного механизма Streamable HTTP не было недостатков, о которых стоило бы упоминать.
SSE против Streamable HTTP: краткое сравнение
Сравните эти два транспортных механизма в таблице SSE vs Streamable HTTP ниже:
| Аспект | HTTP+SSE | Потоковый HTTP |
|---|---|---|
| Тип связи | Однонаправленный (сервер → клиент) | Двунаправленный (клиент ↔ сервер через GET/POST) |
| Использование протокола HTTP | GET для потоковой передачи, отдельный POST для клиентских сообщений | Использует стандартные HTTP POST и GET с одной конечной точки. |
| Устойчивость к внешним воздействиям | Stateful | Государственный, но поддерживает серверы без статического состояния |
| Требуется долговременное HTTP-соединение | Да | Нет |
| Требуется высокая доступность | Да, для сохранения соединения | Нет, работает с серверами без статусов или эфемерными серверами |
| Масштабируемость | Ограниченный | Высокий |
| Поддержка потокового вещания | Да (через текстовый/событийный поток) |
Да (через SSE как дополнительное расширение) |
| Поддержка аутентификации | Да | Да |
| Поддержка возобновления и повторной доставки | Нет | Нет |
| Количество клиентов | Множество | Множество |
| Использование в MCP | Утрачено с версии протокола 2025-03-26 |
Введено в версию протокола 2025-03-26 |
| Обратная совместимость | – | Полная обратная совместимость с клиентами на базе SSE |
Будущее транспортных методов в MCP
MCP был выпущен в ноябре 2024 года, так что это еще очень молодой протокол. Для сравнения, HTTP 1.1 – наиболее распространенная версия – существует уже почти 20 лет.
Поэтому неудивительно, что спецификация MCP продолжает развиваться. Как через несколько месяцев после запуска сообщество решило перейти от SSE к Streamable HTTP, так и в ближайшее время могут произойти новые изменения.
Следите за новостями на странице обсуждений в официальном репозитории MCP на GitHub. На сайте MCP вы также можете ознакомиться с последним проектом грядущей версии протокола.
Заключение
В этой статье блога, посвященной сравнению SSE и Streamable HTTP, вы узнали, почему MCP перешла с SSE на Streamable HTTP. В частности, вы поняли, что представляют собой эти два транспортных механизма и как они влияют на передачу информации в популярном AI-протоколе MCP.
Как объясняется здесь, MCP-серверы сторонних производителей, которые хотят следовать последним, не устаревшим спецификациям MCP, должны реализовать Streamable HTTP. Если вы ищете современный, мощный и многофункциональный MCP-сервер, обратите внимание на MCP-сервер Bright Data.
Сервер MCP от Bright Data построен на последней версии fastmcp, что обеспечивает полную поддержку потокового HTTP при сохранении обратной совместимости с SSE. Он предлагает 20+ инструментов для расширения рабочих процессов ИИ за счет свежих веб-данных, взаимодействия с браузером агентов на любой веб-странице и многое другое.
Для получения полного руководства следуйте нашей статье об интеграции Google ADK с MCP Server для разработки агентов искусственного интеллекта.
Создайте бесплатную учетную запись Bright Data уже сегодня и протестируйте нашу инфраструктуру для работы ваших агентов и приложений искусственного интеллекта!
