In diesem Leitfaden werden Sie sehen:
- Die Geschichte der MCP-Transporttechnologien und warum der Wechsel von SSE zu Streamable HTTP erfolgte.
- Was SSE ist und wie es in älteren MCP-Versionen verwendet wurde.
- Was Streamable HTTP ist und wie es in der aktuellen Version von MCP angewendet wird.
- Eine zusammenfassende Tabelle zum Vergleich von SSE und Streamable HTTP.
- Wie Sie über die Entwicklung der Protokollspezifikationen auf dem Laufenden bleiben.
Lasst uns eintauchen!
Ein wenig Geschichte hinter den von MCP verwendeten Transportprotokollen
MCP(Modal Context Protocol), eines der beliebtesten und am weitesten verbreiteten KI-Protokolle, hat ab der Protokollversion 2025-03-26 den Transportmechanismus HTTP+SSE durch Streamable HTTP ersetzt. Dies stellt eine wesentliche Änderung der Protokollarchitektur dar.
Wir wollen diese Veränderung besser verstehen, bevor wir die beiden Transportmechanismen erläutern.
Warum KI-Protokolle Transportmechanismen brauchen
KI-Protokolle wie MCP benötigen Transportmechanismen, um den Austausch von Informationen zwischen den verschiedenen Komponenten der Protokollarchitektur zu erleichtern.
MCP verwendet insbesondere JSON-RPC 2.0 als Übertragungsformat zwischen Clients und Servern. Für die Übertragung von JSON-RPC-Nachrichten werden Standard-Transportmechanismen wie HTTP+SSE oder Streamable HTTP (neben stdio – für die Kommunikation über Standard-In und Standard-Out auf lokalen Servern) verwendet.
Diese spezialisierten Transportschichten sind notwendig, weil das herkömmliche HTTP-Anfrage-Antwort-Modell für die KI-Kommunikation in Echtzeit ineffizient ist. Das liegt daran, dass einfaches HTTP aufgrund des häufigen Verbindungsaufbaus einen hohen Overhead und hohe Latenzzeiten verursacht. Im Gegensatz dazu erfordert MCP kontinuierliche Datenströme mit geringer Latenz – etwas, wofür HTTP+SSE und Streamable HTTP ausgelegt sind.
Warum die Änderung vorgenommen wurde
MCP verwendete ursprünglich HTTP+SSE, um Server-zu-Client-Streaming in Remote-Szenarien zu ermöglichen. Diese drei wesentlichen Einschränkungen rechtfertigten jedoch die Änderung:
- Keine Unterstützung für wiederaufnehmbare Streams.
- Erfordert, dass der Server eine langlebige, hochverfügbare Verbindung unterhält.
- Erlaubt nur die Zustellung von Server-Nachrichten über SSE.
Streamable HTTP löst diese Probleme. Es ermöglicht zustandslose Kommunikation und unterstützt sogar Upgrades auf SSE nach Bedarf. Dies verbessert die Kompatibilität mit moderner Infrastruktur und garantiert eine stabilere und effizientere Kommunikation.
Auswirkungen des Übergangs von HTTP+SSE zu Streamable HTTP
Der Übergang von HTTP+SSE zu Streamable HTTP als Transportprotokoll war eine wichtige Änderung für MCP. Es wurden erhebliche Änderungen an der Protokollimplementierung vorgenommen, so dass viele MCP-Client- und -Server-Bibliotheken von Drittanbietern angepasst werden mussten.
Zum jetzigen Zeitpunkt können MCP-Clients und -Server jedoch die Abwärtskompatibilität mit dem veralteten HTTP+SSE-Transport beibehalten.
SSE (Server-gesendete Ereignisse)
SSE(Server-Sent Events) ist ein Mechanismus, der es Web-Clients ermöglicht, automatische Aktualisierungen von einem Server zu erhalten. Diese Aktualisierungen sind als “Ereignisse” bekannt und werden über eine einzige, langlebige HTTP-Verbindung gesendet.
Im Gegensatz zu WebSockets ist SSE unidirektional, was bedeutet, dass Daten nur vom Server zum Client fließen. SSE funktioniert, indem der Server einen Strom von Ereignissen über diese offene Verbindung sendet, typischerweise formatiert als text/event-streamMIMEtype.
HTTP+SSE-Verwendung in MCP
So stützte sich MCP in der Version 2024-11-05 auf SSE:
Der Server muss zwei Endpunkte bereitstellen:
- Ein SSE-GET-Endpunkt für Clients, um eine Verbindung herzustellen und Nachrichten vom Server zu empfangen.
- Ein regulärer HTTP-POST-Endpunkt für Clients zum Senden von JSON-RPC-Nachrichten an den Server.
Wenn ein Client eine Verbindung herstellt, muss der Server ein Endpunkt-Ereignis senden, das eine URI enthält, die der Client zum Senden von Nachrichten verwenden wird. Alle JSON-RPC-Nachrichten des Clients werden dann als HTTP-POST-Anforderungen an diese URI gesendet.
Der Server antwortet mit dem Streaming von Ereignissen über die offene SSE-Verbindung und simuliert so eine dauerhafte Sitzung. Im Einzelnen werden die Server-Nachrichten als SSE-Nachrichtenereignisse übermittelt, wobei der Inhalt in den Ereignisdaten als JSON kodiert ist.
Bei einmaligen Antworten sendet der Server die Nachricht und schließt den Stream. Bei laufender Kommunikation bleibt die Verbindung offen.
Pro und Kontra
Dies sind die wichtigsten Vor- und Nachteile der Verwendung von SSE in MCP:
👍 Streaming großer Ergebnisse: Ermöglicht das sofortige Senden von Teilergebnissen und vermeidet Verzögerungen, während MCP-Tools große Daten verarbeiten oder auf externe API-Antworten warten.
👍 Ereignisgesteuerte Auslöser: Unterstützt unaufgeforderte Serverereignisse zur Benachrichtigung von Clients über Änderungen, mit Warnungen oder Statusaktualisierungen.
👍 Einfachheit: Verwendet Standard-HTTP, erfordert keine speziellen Protokolle oder komplexe Einrichtung.
👎 Nur unidirektional: Daten können nur von Servern zu Clients im SSE-Kanal fließen. Die Clients müssen separate HTTP-POST-Anfragen zum Senden von Nachrichten verwenden.
👎 Langfristige Nutzung von Verbindungsressourcen: Die Aufrechterhaltung offener Verbindungen kann eine Menge Serverressourcen verbrauchen, insbesondere im großen Maßstab.
Streamingfähiges HTTP
Im Zusammenhang mit MCP ist streamable HTTP eine Methode zum Streaming von Daten zwischen Client und Server unter Verwendung von reinem HTTP. Es öffnet die Tür zur Echtzeitkommunikation, ohne dass langlebige Verbindungen erforderlich sind.
SSE kann zwar aus Gründen der Flexibilität und Abwärtskompatibilität weiterhin verwendet werden, diese Transportmethode ist jedoch nicht mehr erforderlich. Dadurch kann MCP zustandslose Server unterstützen, ohne dass der Overhead für die Aufrechterhaltung hochverfügbarer dauerhafter Verbindungen anfällt.
ℹ️ Extra: Warum streamingfähiges HTTP + optional SSE anstelle von WebSockets?
- Die Verwendung von WebSockets für einfache, zustandslose RPC-Aufrufe führt zu unnötigem Netzwerk- und Betriebs-Overhead.
- Browser können keine Header wie
Authorizationan WebSockets anhängen, und im Gegensatz zu SSE können WebSockets nicht mit Standard-HTTP-Tools neu implementiert werden. - WebSocket-Upgrades funktionieren nur mit GET-Anfragen, was POST-basierte Abläufe aufgrund der erforderlichen Upgrade-Schritte komplexer und langsamer macht.
Streamingfähiges HTTP in MCP
Beim Streamable HTTP-Transport agiert der Server als eigenständiger Prozess, der mehrere Client-Verbindungen verarbeiten kann. Er verwendet für die Kommunikation standardmäßige HTTP-POST- und GET-Anfragen.
Optional kann der Server SSE verwenden, um mehrere Nachrichten an den Client zu streamen. Dies eignet sich sowohl für einfache MCP-Server für einfache Anfrage/Antwort-Tools als auch für solche, die fortgeschrittenere Funktionen wie Streaming und Echtzeit-Benachrichtigungen zwischen Server und Client bieten.
Der Server muss einen einzigen HTTP-Endpunkt (als “MCP-Endpunkt” bezeichnet) bereitstellen, der sowohl POST- als auch GET-Methoden unterstützt.
Das folgende Diagramm veranschaulicht den Kommunikationsfluss zwischen MCP-Clients und Servern, die Streamable HTTP verwenden:
Um die Wiederaufnahme unterbrochener Verbindungen und die erneute Zustellung potenziell verlorener Nachrichten zu unterstützen, weist der MCP-Server IDs pro Stream zu. Diese IDs dienen als Cursor innerhalb jedes Streams.
In Anbetracht der Vielzahl möglicher Wechselwirkungen sollten Sie die offizielle MCP-Dokumentation zu Rate ziehen, um alle Einzelheiten der Implementierung zu erfahren.
Pro und Kontra
Dies sind die wichtigsten Vorteile der Verwendung von Streamable HTTP in MCP:
👍 Unterstützung zustandsloser Server: Keine Notwendigkeit für ständig aktive, langlebige Verbindungen mehr.
👍 Plain HTTP: Kann mit jedem Standard-HTTP-Server implementiert werden, ohne dass SSE erforderlich ist.
👍 Infrastrukturfreundlich: Kompatibel mit gängiger HTTP-Middleware, Proxies und Hosting-Plattformen.
👍 Rückwärtskompatibel: Baut schrittweise auf dem vorherigen HTTP+SSE-Transport auf.
👍 Optionales Streaming: Server können bei Bedarf auf SSE aufrüsten, um Antworten zu streamen.
Hinweis: Zum Zeitpunkt der Erstellung dieses Dokuments gibt es keine nennenswerten Nachteile des Streamable HTTP-Transportmechanismus.
SSE vs. Streamable HTTP: Zusammenfassender Vergleich
Vergleichen Sie die beiden Transportmechanismen in der folgenden Tabelle SSE vs. Streamable HTTP:
| Aspekt | HTTP+SSE | Streamingfähiges HTTP |
|---|---|---|
| Art der Kommunikation | Unidirektional (Server → Client) | Bidirektional (Client ↔ Server über GET/POST) |
| Verwendung des HTTP-Protokolls | GET für Streaming, separates POST für Client-Nachrichten | Verwendet standardmäßige HTTP POST und GET von einem einzigen Endpunkt |
| Zustandsabhängigkeit | Zustandsabhängig | Zustandsabhängig, unterstützt aber zustandslose Server |
| Erfordert langlebige HTTP-Verbindung | Ja | Nein |
| Hohe Verfügbarkeit erforderlich | Ja, für die Aufrechterhaltung der Verbindung | Nein, funktioniert mit zustandslosen oder ephemeren Servern |
| Skalierbarkeit | Begrenzt | Hoch |
| Unterstützung von Streaming | Ja (über Text/Ereignis-Stream) |
Ja (über SSE als optionale Erweiterung) |
| Unterstützung der Authentifizierung | Ja | Ja |
| Unterstützung für Wiederaufnahme und erneute Zustellung | Nein | Nein |
| Anzahl der Kunden | Mehrere | Mehrere |
| Verwendung in MCP | Veraltet seit Protokollversion 2025-03-26 |
Eingeführt in Protokollversion 2025-03-26 |
| Abwärtskompatibilität | – | Vollständige Abwärtskompatibilität mit SSE-basierten Clients |
Zukunft der Transportmethoden in MCP
MCP wurde im November 2024 veröffentlicht, ist also noch ein sehr junges Protokoll. Zum Vergleich: HTTP 1.1 – die am weitesten verbreitete Version – gibt es schon seit fast 20 Jahren.
Daher ist es nicht verwunderlich, dass die MCP-Spezifikation immer noch weiterentwickelt wird. So wie die Gemeinschaft einige Monate nach dem Start beschlossen hat, von SSE auf Streamable HTTP umzusteigen, könnten bald weitere Änderungen folgen.
Bleiben Sie auf dem Laufenden, indem Sie die Diskussionsseite auf dem offiziellen MCP-GitHub-Repository besuchen. Auf der MCP-Website können Sie auch den neuesten Entwurf der kommenden Version des Protokolls einsehen.
Schlussfolgerung
In diesem Blogbeitrag zum Vergleich von SSE und Streamable HTTP haben Sie erfahren, warum MCP von SSE auf Streamable HTTP umgestiegen ist. Insbesondere haben Sie verstanden, was diese beiden Transportmechanismen sind und wie sie die Informationsübertragung im beliebten KI-Protokoll MCP beeinflussen.
Wie hier erläutert, müssen MCP-Server von Drittanbietern, die die neuesten, nicht veralteten MCP-Spezifikationen befolgen möchten, Streamable HTTP implementieren. Wenn Sie auf der Suche nach einem aktuellen, leistungsstarken und funktionsreichen MCP-Server sind, sollten Sie sich den MCP-Server von Bright Data ansehen.
Der MCP-Server von Bright Data basiert auf der neuesten Version von fastmcp und bietet vollständige Unterstützung für Streamable HTTP bei gleichzeitiger Abwärtskompatibilität mit SSE. Er bietet mehr als 20 Tools zur Erweiterung Ihrer KI-Workflows mit frischen Webdaten, Agent-Browser-Interaktionen auf beliebigen Webseiten und vielem mehr.
Eine vollständige Anleitung finden Sie in unserem Artikel über die Integration von Google ADK mit einem MCP-Server für die Entwicklung von KI-Agenten.
Erstellen Sie noch heute ein kostenloses Bright Data-Konto und testen Sie unsere Infrastruktur, um Ihre KI-Agenten und Anwendungen zu betreiben!
