Dans ce guide, vous verrez :
- L’histoire des technologies de transport MCP et les raisons du passage de SSE à Streamable HTTP.
- Ce qu’est le SSE et comment il était utilisé dans les anciennes versions de MCP.
- Ce qu’est le Streamable HTTP et comment il est appliqué dans la version actuelle de MCP.
- Un tableau récapitulatif comparant SSE et Streamable HTTP.
- Comment se tenir au courant de l’évolution des spécifications du protocole.
Plongeons dans l’aventure !
Un peu d’histoire derrière les protocoles de transport utilisés par MCP
MCP(Modal Context Protocol), l’un des protocoles d’IA les plus populaires et les plus largement utilisés aujourd’hui, a remplacé le mécanisme de transport HTTP+SSE par le protocole Streamable HTTP à partir de la version 2025-03-26 du protocole. Cela a marqué un changement important dans l’architecture du protocole.
Comprenons mieux ce changement avant d’expliquer ce que sont ces deux mécanismes de transport.
Pourquoi les protocoles d’IA ont-ils besoin de mécanismes de transport ?
Les protocoles d’IA comme le MCP ont besoin de mécanismes de transport pour faciliter l’échange d’informations entre les différents composants de l’architecture du protocole.
Plus précisément, MCP utilise JSON-RPC 2.0 comme format de communication entre les clients et les serveurs. Pour la transmission des messages JSON-RPC, il s’appuie sur des mécanismes de transport standard tels que HTTP+SSE ou Streamable HTTP (parmi stdio – pour la communication sur les entrées et sorties standard sur les serveurs locaux).
Ces couches de transport spécialisées sont nécessaires parce que le modèle demande-réponse du protocole HTTP traditionnel est inefficace pour la communication en temps réel de l’intelligence artificielle. En effet, le HTTP ordinaire introduit une surcharge et un temps de latence élevés en raison de l’établissement fréquent de connexions. En revanche, le MCP nécessite des flux de données continus et à faible latence, ce pour quoi HTTP+SSE et Streamable HTTP sont conçus.
Pourquoi ce changement ?
MCP utilisait initialement HTTP+SSE pour permettre la diffusion en continu de serveur à client dans des scénarios à distance. Cependant, ces trois limitations majeures ont justifié le changement :
- Pas de prise en charge des flux résumables.
- Le serveur doit maintenir une connexion de longue durée et hautement disponible.
- Permet uniquement la transmission des messages du serveur via le SSE.
Le protocole HTTP en continu résout ces problèmes. Il permet une communication sans état et prend même en charge les mises à jour à la demande du SSE. Cela améliore la compatibilité avec les infrastructures modernes et garantit une communication plus stable et plus efficace.
Impact du passage du protocole HTTP+SSE au protocole HTTP fluide
Le passage de HTTP+SSE à HTTP Streamable comme protocole de transport a été un changement important pour MCP. Il a introduit des changements notables dans la mise en œuvre du protocole, obligeant de nombreuses bibliothèques tierces de clients et de serveurs MCP à s’adapter.
Toutefois, à ce jour, les clients et serveurs MCP peuvent conserver une compatibilité ascendante avec le transport HTTP+SSE, qui est obsolète.
SSE (événements envoyés par le serveur)
SSE(Server-Sent Events) est un mécanisme qui permet aux clients web de recevoir des mises à jour automatiques d’un serveur. Ces mises à jour sont appelées “événements” et sont envoyées par le biais d’une connexion HTTP unique et de longue durée.
Contrairement aux WebSockets, le SSE est unidirectionnel, ce qui signifie que les données ne circulent que du serveur vers le client. Le SSE fonctionne par l’envoi par le serveur d’un flux d’événements sur cette connexion ouverte, généralement formaté en tant que typetext/event-streamMIME.
Utilisation de HTTP+SSE dans MCP
C’est ainsi que MCP s’est appuyé sur SSE dans la version 2024-11-05:
Le serveur doit fournir deux points d’extrémité :
- Point d’arrivée SSE GET permettant aux clients d’établir une connexion et de recevoir des messages du serveur.
- Un point d’arrivée HTTP POST ordinaire permettant aux clients d’envoyer des messages JSON-RPC au serveur.
Lorsqu’un client se connecte, le serveur doit envoyer un événement de point de terminaison contenant un URI que le client utilisera pour envoyer des messages. Tous les messages JSON-RPC du client sont alors envoyés en tant que requêtes HTTP POST à cet URI.
Le serveur répond en diffusant des événements sur la connexion SSE ouverte, simulant ainsi une session persistante. En détail, les messages du serveur sont délivrés en tant qu’événements de messages SSE, avec le contenu encodé en JSON dans les données de l’événement.
Pour les réponses uniques, le serveur envoie le message et ferme le flux. Pour une communication continue, la connexion reste ouverte.
Avantages et inconvénients
Voici les principaux avantages et inconvénients de l’utilisation de SSE dans MCP :
👍 Diffusion en continu de résultats volumineux: Permet d’envoyer immédiatement des résultats partiels, en évitant les retards pendant que les outils MCP traitent des données volumineuses ou attendent des réponses d’API externes.
👍 D éclencheurs axés sur les événements: Prend en charge les événements serveur non sollicités pour informer les clients des changements, avec des alertes ou des mises à jour d’état.
👍 Simplicité: Utilise le protocole HTTP standard, ne nécessitant pas de protocoles spéciaux ou de configuration complexe.
👎 Unidirectionnel uniquement: Les données ne peuvent circuler que des serveurs vers les clients dans le canal SSE. Les clients doivent utiliser des requêtes HTTP POST distinctes pour envoyer des messages.
👎 Utilisation de ressources de connexion à long terme: Le maintien de connexions ouvertes peut consommer beaucoup de ressources serveur, en particulier à grande échelle.
HTTP en continu
Dans le contexte du projet MCP, le protocole HTTP streamable est une méthode de transmission en continu de données entre le client et le serveur à l’aide du protocole HTTP pur. Elle ouvre la porte à la communication en temps réel sans nécessiter de connexions de longue durée.
Bien qu’il puisse toujours utiliser SSE pour des raisons de flexibilité et de compatibilité ascendante, cette méthode de transport n’est plus nécessaire. Cela permet à MCP de prendre en charge des serveurs sans état, sans avoir à maintenir des connexions persistantes à haute disponibilité.
ℹ️ Extra: Pourquoi HTTP streamable + SSE optionnel au lieu de WebSockets ?
- L’utilisation de WebSockets pour des appels RPC simples et sans état ajoute une surcharge inutile au niveau du réseau et des opérations.
- Les navigateurs ne peuvent pas attacher des en-têtes comme l’
autorisationaux WebSockets et, contrairement à SSE, les WebSockets ne peuvent pas être réimplémentés avec des outils HTTP standard. - Lesmises à niveau WebSocket ne fonctionnent qu’avec les requêtes GET, ce qui rend les flux basés sur POST complexes et plus lents en raison des étapes de mise à niveau nécessaires.
HTTP en continu dans MCP
Dans le transport Streamable HTTP, le serveur agit comme un processus autonome capable de gérer plusieurs connexions de clients. Il utilise les requêtes HTTP POST et GET standard pour communiquer.
En option, le serveur peut utiliser SSE pour transmettre plusieurs messages au client. Cela convient à la fois aux serveurs MCP de base pour les outils simples de demande/réponse et à ceux qui offrent des capacités plus avancées comme la diffusion en continu et les notifications en temps réel entre le serveur et le client.
Le serveur doit exposer un seul point de terminaison HTTP (appelé “point de terminaison MCP“) qui prend en charge les méthodes POST et GET.
Le diagramme ci-dessous illustre le flux de communication entre les clients MCP et les serveurs utilisant le protocole HTTP fluide :
Pour permettre la reprise des connexions interrompues et la retransmission des messages potentiellement perdus, le serveur MCP attribue des identifiants par flux. Ces identifiants servent de curseurs dans chaque flux.
Compte tenu de la diversité des interactions possibles, il convient de se référer à la documentation officielle du programme MCP pour obtenir tous les détails de la mise en œuvre.
Avantages et inconvénients
Voici les principaux avantages de l’utilisation de Streamable HTTP dans MCP :
👍 Prise en charge des serveurs sans état: Supprime le besoin de connexions permanentes et durables.
👍 HTTP simple: peut être mis en œuvre à l’aide de n’importe quel serveur HTTP standard sans nécessiter de SSE.
👍 Infrastructure conviviale: Compatible avec les intergiciels HTTP, les proxys et les plateformes d’hébergement les plus courants.
👍 Rétrocompatibilité: S’appuie de manière incrémentale sur le transport HTTP+SSE précédent.
👍 Streaming optionnel: Les serveurs peuvent passer au SSE pour obtenir des réponses en continu si nécessaire.
Remarque: à l’heure où nous écrivons ces lignes, le mécanisme de transport HTTP Streamable ne présente aucun inconvénient digne d’être mentionné.
SSE vs Streamable HTTP : Comparaison sommaire
Comparez les deux mécanismes de transport dans le tableau SSE vs Streamable HTTP ci-dessous :
| Aspect | HTTP+SSE | HTTP en continu |
|---|---|---|
| Type de communication | Unidirectionnel (serveur → client) | Bidirectionnel (Client ↔ Serveur via GET/POST) |
| Utilisation du protocole HTTP | GET pour le streaming, POST séparé pour les messages du client | Utilise les protocoles HTTP POST et GET standard à partir d’un point de terminaison unique. |
| Caractère évolutif | État | Avec état, mais prend en charge les serveurs sans état |
| Requiert une connexion HTTP de longue durée | Oui | Non |
| Haute disponibilité requise | Oui, pour la persistance de la connexion | Non, fonctionne avec des serveurs sans état ou éphémères. |
| Évolutivité | Limitée | Haut |
| Prise en charge de la diffusion en continu | Oui (par le biais d’un texte ou d'un flux d'événements) |
Oui (par l’intermédiaire de l’ESS en tant qu’amélioration optionnelle) |
| Support d’authentification | Oui | Oui |
| Soutien à la resumabilité et à la re-livraison | Non | Non |
| Nombre de clients | Multiple | Multiple |
| Utilisation dans MCP | Obsolète depuis la version 2025-03-26 du protocole |
Introduit dans la version du protocole 2025-03-26 |
| Compatibilité ascendante | – | Entièrement rétrocompatible avec les clients basés sur le SSE |
L’avenir des méthodes de transport dans les MCP
MCP a été publié en novembre 2024, il s’agit donc d’un protocole encore très jeune. Pour mettre les choses en perspective, HTTP 1.1 – la version la plus utilisée – existe depuis près de 20 ans.
Il n’est donc pas surprenant que la spécification MCP continue d’évoluer. Tout comme quelques mois après le lancement, la communauté a décidé de passer de SSE à Streamable HTTP, d’autres changements pourraient bientôt survenir.
Restez à jour en consultant la page Discussions sur le dépôt officiel MCP GitHub. Le site web du MCP vous permet également de consulter le dernier projet de la prochaine version du protocole.
Conclusion
Dans cet article de blog comparant SSE et Streamable HTTP, vous avez appris pourquoi MCP est passé de SSE à Streamable HTTP. En particulier, vous avez compris ce que sont ces deux mécanismes de transport et comment ils affectent la transmission d’informations dans le protocole d’IA populaire MCP.
Comme expliqué ici, les serveurs MCP tiers qui souhaitent suivre les spécifications MCP les plus récentes et non dépréciées doivent implémenter Streamable HTTP. Si vous recherchez un serveur MCP actualisé, puissant et riche en fonctionnalités, jetez un coup d’œil au serveur MCP de Bright Data.
Le serveur MCP de Bright Data est construit sur la dernière version de fastmcp, garantissant une prise en charge complète de Streamable HTTP tout en conservant une rétrocompatibilité avec SSE. Il offre plus de 20 outils pour étendre vos flux de travail d’IA avec des données Web fraîches, des interactions avec le navigateur d’agents sur n’importe quelle page Web, et bien plus encore.
Pour un tutoriel complet, suivez notre article sur l’intégration de Google ADK avec un serveur MCP pour le développement d’agents d’intelligence artificielle.
Créez un compte Bright Data gratuitement dès aujourd’hui et testez notre infrastructure pour alimenter vos agents et applications d’IA !
