--- title: "SSE vs. Streamable HTTP: as tecnologias de transporte por trás do MCP" slug: sse-vs-streamable-http date: 2025-07-15T07:44:03+00:00 modified: 2025-07-15T07:46:54+00:00 permalink: https://brightdata.com.br/blog/ai/sse-vs-streamable-http type: blog --- [ Blog ](https://brightdata.com.br/blog "Blog") / [AI](https://brightdata.com.br/blog/ai) [AI](https://brightdata.com.br/blog/ai) # SSE vs. Streamable HTTP: as tecnologias de transporte por trás do MCP Explore a mudança do MCP para o Streamable HTTP, comparando-o com o SSE, e saiba como esses protocolos afetam o transporte de dados de IA em tempo real. 10 min de leitura [ ![Antonello Zanini](https://media.brightdata.com.br/2022/12/Antonello-Zanini-2-50x50.jpg) ](https://brightdata.com/blog/authors/antonello-zanini) [Antonello Zanini Technical Writer ](https://brightdata.com/blog/authors/antonello-zanini) ![SSE vs. Streamable HTTP](https://media.brightdata.com.br/2025/06/SSE-vs.-Streamable-HTTP.png) Neste guia, você verá: - O histórico das tecnologias de transporte MCP e por que a mudança de SSE para Streamable HTTP aconteceu. - O que é o SSE e como ele era usado em versões anteriores do MCP. - O que é o Streamable HTTP e como ele é aplicado na versão atual do MCP. - Uma tabela de resumo comparando SSE e Streamable HTTP. - Como se manter atualizado sobre os desenvolvimentos das especificações de protocolo. Vamos mergulhar de cabeça! ## Um pouco da história por trás dos protocolos de transporte usados pela MCP O MCP[(Modal Context Protocol](https://modelcontextprotocol.io/introduction)), um dos protocolos de IA mais populares e amplamente usados atualmente, substituiu o mecanismo de transporte [HTTP+SSE](https://modelcontextprotocol.io/specification/2024-11-05/basic/transports#http-with-sse) pelo [Streamable HTTP](https://modelcontextprotocol.io/specification/2025-03-26/basic/transports#streamable-http) a partir da versão 2026-03-26 do protocolo. Isso marcou uma mudança significativa na arquitetura do protocolo. Agora, vamos entender melhor essa mudança antes de explicar o que são esses dois mecanismos de transporte. ### Por que os protocolos de IA precisam de mecanismos de transporte [Os protocolos de IA, como o MCP](https://hackernoon.com/mcp-a2a-agp-acp-making-sense-of-the-new-ai-protocols), precisam de mecanismos de transporte para facilitar a troca de informações entre os diferentes componentes da arquitetura do protocolo. Especificamente, o MCP usa [o JSON-RPC 2.0](https://www.jsonrpc.org/) como seu formato de conexão entre clientes e servidores. Para a transmissão de mensagens JSON-RPC, ele se baseia em mecanismos de transporte padrão como HTTP+SSE ou Streamable HTTP (entre [`stdio`](https://modelcontextprotocol.io/specification/2025-03-26/basic/transports#stdio) – para comunicação sobre entrada e saída padrão em servidores locais). Essas camadas de transporte especializadas são necessárias porque [o modelo](https://developer.mozilla.org/en-US/docs/Web/HTTP) tradicional [de solicitação-resposta do HTTP](https://developer.mozilla.org/en-US/docs/Web/HTTP) é ineficiente para a comunicação de IA em tempo real. Isso ocorre porque o HTTP simples apresenta alta sobrecarga e latência devido às frequentes configurações de conexão. Por outro lado, o MCP exige fluxos de dados contínuos e de baixa latência, algo que o HTTP+SSE e o Streamable HTTP foram projetados para lidar. ### Por que a mudança foi feita Inicialmente, o MCP usava HTTP+SSE para permitir o streaming de servidor para cliente em cenários remotos. No entanto, essas [três grandes limitações justificaram a mudança](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/206): - Não há suporte para fluxos retomáveis. - Requer que o servidor mantenha uma conexão de longa duração e altamente disponível. - Permite apenas que as mensagens do servidor sejam entregues via SSE. O Streamable HTTP resolve esses problemas. Ele permite a comunicação sem estado e até mesmo suporta atualizações sob demanda para o SSE. Isso melhora a compatibilidade com a infraestrutura moderna e garante uma comunicação mais estável e eficiente. ### Impacto da transição de HTTP+SSE para HTTP com streaming A transição do HTTP+SSE para o Streamable HTTP como protocolo de transporte foi uma mudança importante para o MCP. Ela introduziu mudanças notáveis na implementação do protocolo, exigindo que muitas bibliotecas de clientes e servidores MCP de terceiros se adaptassem. No entanto, até o momento em que este texto foi escrito, os clientes e servidores MCP podem [manter a compatibilidade com versões anteriores do transporte HTTP+SSE obsoleto](https://modelcontextprotocol.io/specification/2025-03-26/basic/transports#backwards-compatibility). ## SSE (eventos enviados pelo servidor) O SSE[(Server-Sent Events](https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events)) é um mecanismo que permite que os clientes da Web recebam atualizações automáticas de um servidor. Essas atualizações são conhecidas como “*eventos*” e são enviadas por meio de uma única conexão HTTP de longa duração. Diferentemente dos [WebSockets](https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API), o SSE é unidirecional, o que significa que os dados fluem apenas do servidor para o cliente. O SSE funciona com o servidor enviando um fluxo de eventos por essa conexão aberta, normalmente formatado como [tipo`text/event-streamMIME`](https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events/Using_server-sent_events). ### Uso de HTTP+SSE no MCP Foi assim que o MCP contou com o SSE na [versão 2024-11-05](https://modelcontextprotocol.io/specification/2024-11-05/): ![Uso do SSE na versão 2024-11-05 do MCP](https://media.brightdata.com/2025/06/SSE-usage-in-MCP-version-2024-11-05.png)O servidor deve fornecer dois pontos de extremidade: 1. Um ponto de extremidade SSE GET para que os clientes estabeleçam uma conexão e recebam mensagens do servidor. 2. Um ponto de extremidade HTTP POST regular para que os clientes enviem mensagens JSON-RPC para o servidor. Quando um cliente se conecta, o servidor deve enviar um evento de `ponto de extremidade` contendo um URI que o cliente usará para enviar mensagens. Todas as mensagens JSON-RPC do cliente são então enviadas como solicitações HTTP POST para esse URI. O servidor responde transmitindo eventos pela conexão SSE aberta, simulando uma sessão persistente. Em detalhes, as mensagens do servidor são entregues como eventos `de mensagem` SSE, com o conteúdo codificado como JSON nos dados do evento. Para respostas únicas, o servidor envia a mensagem e fecha o fluxo. Para a comunicação contínua, a conexão permanece aberta. ### Prós e contras Estes são os principais prós e contras do uso do SSE no MCP: **Transmissão de grandes resultados**: Permite o envio imediato de resultados parciais, evitando atrasos enquanto as ferramentas de MCP processam dados grandes ou aguardam respostas de API externas. **Acionadores acionados por eventos**: Oferece suporte a eventos de servidor não solicitados para notificar os clientes sobre alterações, com alertas ou atualizações de status. **Simplicidade**: Usa HTTP padrão, não exigindo protocolos especiais ou configurações complexas. **Somente unidirecional**: Os dados só podem fluir de servidores para clientes no canal SSE. Os clientes devem usar solicitações HTTP POST separadas para enviar mensagens. **Uso de recursos de conexão de longa duração**: A manutenção de conexões abertas pode consumir muitos recursos do servidor, especialmente em escala. ## HTTP transmitido No contexto do MCP, o HTTP transmissível é um método de transmissão de dados entre o cliente e o servidor usando HTTP puro. Ele abre a porta para a comunicação em tempo real sem exigir conexões de longa duração. Embora ele ainda possa usar o SSE para flexibilidade e compatibilidade com versões anteriores, esse método de transporte não é mais necessário. Isso permite que o MCP ofereça suporte a servidores sem estado sem a sobrecarga de manter conexões persistentes de alta disponibilidade. ℹ️ **Extra**: Por que HTTP com streaming + SSE opcional em vez de WebSockets? 1. O uso de WebSockets para chamadas RPC simples e sem estado adiciona uma sobrecarga operacional e de rede desnecessária. 2. Os navegadores não podem anexar cabeçalhos como `Autorização` aos WebSockets e, ao contrário do SSE, os WebSockets não podem ser reimplementados com ferramentas HTTP padrão. 3. [As atualizações do WebSocket](https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Protocol_upgrade_mechanism) só funcionam com solicitações GET, tornando os fluxos baseados em POST complexos e mais lentos devido às etapas de atualização necessárias. ### HTTP com streaming no MCP No transporte Streamable HTTP, o servidor atua como um processo autônomo capaz de lidar com várias conexões de clientes. Ele usa solicitações HTTP POST e GET padrão para comunicação. Opcionalmente, o servidor pode usar o SSE para transmitir várias mensagens para o cliente. Isso acomoda tanto servidores MCP básicos para ferramentas simples de solicitação/resposta quanto aqueles que oferecem recursos mais avançados, como streaming e notificações de servidor para cliente em tempo real. O servidor deve expor um único ponto de extremidade HTTP (chamado de “[*ponto de extremidade MCP*](https://langchain-ai.github.io/langgraph/concepts/server-mcp/)“) que ofereça suporte aos métodos POST e GET. O diagrama abaixo ilustra o fluxo de comunicação entre clientes e servidores MCP usando Streamable HTTP: ![Uso de HTTP com streaming na versão MCP 2026-03-26](https://media.brightdata.com/2025/06/Streamable-HTTP-usage-in-MCP-version-2025-03-26.png)Para dar suporte à retomada de conexões interrompidas e à reentrega de mensagens possivelmente perdidas, o servidor MCP atribui IDs por fluxo. Essas IDs funcionam como cursores em cada fluxo. Dada a variedade de interações possíveis, [consulte a documentação oficial do MCP para obter detalhes completos sobre a implementação](https://modelcontextprotocol.io/specification/2025-03-26/basic/transports#streamable-http). ### Prós e contras Estas são as principais vantagens de usar o Streamable HTTP no MCP: 👍 **Suporte a servidores sem estado**: Elimina a necessidade de conexões sempre ativas e de longa duração. **HTTP simples**: pode ser implementado usando qualquer servidor HTTP padrão sem a necessidade de SSE. Compatível **com a infraestrutura**: Compatível com middleware HTTP comum, [proxies](/blog/proxy-101/what-is-proxy-server) e plataformas de hospedagem. Compatível **com versões anteriores**: É desenvolvido de forma incremental com base no transporte HTTP+SSE anterior. **Transmissão opcional**: Os servidores podem fazer upgrade para SSE para respostas de streaming quando necessário. **Observação**: no momento em que este artigo foi escrito, não havia nenhuma desvantagem no mecanismo de transporte Streamable HTTP que valesse a pena mencionar. ## SSE vs. HTTP de fluxo contínuo: comparação resumida Compare os dois mecanismos de transporte na tabela SSE vs. Streamable HTTP abaixo: **Aspecto****HTTP+SSE****HTTP transmitido****Tipo de comunicação**Unidirecional (servidor → cliente)Bidirecional (Cliente ↔ Servidor via GET/POST)**Uso do protocolo HTTP**GET para streaming, POST separado para mensagens do clienteUsa HTTP POST e GET padrão de um único ponto de extremidade**Estado**EstatalEstatal, mas suporta servidores sem estado**Requer conexão HTTP de longa duração**SimNão**Alta disponibilidade necessária**Sim, para persistência de conexãoNão, funciona com servidores sem estado ou efêmeros**Escalabilidade**LimitadaAlta**Suporte a streaming**Sim (via `texto/fluxo de eventos`)Sim (via SSE como aprimoramento opcional)**Suporte à autenticação**SimSim**Suporte para a possibilidade de retomada e nova entrega**NãoNão**Número de clientes**MúltiplosMúltiplos**Uso em MCP**Preterido desde a versão `2026-03-26` do protocoloIntroduzido na versão do protocolo `2026-03-26`**Compatibilidade com versões anteriores**–Totalmente compatível com versões anteriores de clientes baseados em SSE## Futuro dos métodos de transporte no MCP O MCP foi lançado em novembro de 2024, portanto, ainda é um protocolo muito novo. Para colocar isso em perspectiva, o HTTP 1.1 – a versão mais usada – existe há quase 20 anos. Portanto, não é de surpreender que a especificação MCP ainda esteja evoluindo. Assim como alguns meses após o lançamento, a comunidade decidiu fazer a transição de SSE para Streamable HTTP, mais mudanças podem ocorrer em breve. Mantenha-se atualizado verificando a [página Discussões no repositório oficial do MCP no GitHub](https://github.com/modelcontextprotocol/modelcontextprotocol/discussions). O site do MCP também permite que você analise o [rascunho mais recente da próxima versão do protocolo](https://modelcontextprotocol.io/specification/draft). ## Conclusão Nesta postagem do blog de comparação entre SSE e HTTP Streamable, você aprendeu por que o MCP fez a transição de SSE para HTTP Streamable. Em particular, você entendeu o que são esses dois mecanismos de transporte e como eles afetam a transmissão de informações no popular protocolo de IA MCP. Conforme explicado aqui, os servidores MCP de terceiros que desejam seguir as especificações MCP mais recentes e não obsoletas devem implementar o Streamable HTTP. Se estiver procurando um servidor MCP atualizado, avançado e repleto de recursos, dê uma olhada no [servidor MCP da Bright Data](https://docs.brightdata.com/api-reference/MCP-Server). [O servidor MCP da Bright Data](/ai/mcp-server) foi desenvolvido com base na versão mais recente do `fastmcp`, garantindo suporte total ao Streamable HTTP e mantendo a compatibilidade com versões anteriores do SSE. [Ele oferece mais de 20 ferramentas](https://github.com/brightdata/brightdata-mcp?tab=readme-ov-file#-available-tools) para expandir seus fluxos de trabalho de IA com dados novos da Web, interações [do navegador do agente](/ai/agent-browser) em qualquer página da Web e muito mais. Para obter um tutorial completo, siga nosso artigo sobre [a integração do Google ADK com um servidor MCP para o desenvolvimento de agentes de IA.](/blog/ai/google-adk-with-bright-data-mcp-server) Crie uma conta da Bright Data gratuitamente hoje mesmo e teste nossa infraestrutura para alimentar seus agentes e aplicativos de IA! Contate-nosTeste grátis![google social icon](/wp-content/themes/brightdata/assets/images/ic_google.svg) Índice [ ](https://news.ycombinator.com/submitlink?t=SSE+vs.+Streamable+HTTP%3A+as+tecnologias+de+transporte+por+tr%C3%A1s+do+MCP&u=https://brightdata.com.br/blog/ai/sse-vs-streamable-http) [ ](https://www.linkedin.com/shareArticle?mini=true&title=SSE+vs.+Streamable+HTTP%3A+as+tecnologias+de+transporte+por+tr%C3%A1s+do+MCP&url=https://brightdata.com.br/blog/ai/sse-vs-streamable-http) [ ](http://www.reddit.com/submit?title=SSE+vs.+Streamable+HTTP%3A+as+tecnologias+de+transporte+por+tr%C3%A1s+do+MCP&url=https://brightdata.com.br/blog/ai/sse-vs-streamable-http) ## Você também pode estar interessado em [ ![OpenHuman with Bright Data](https://media.brightdata.com.br/2026/09/OpenHuman-with-Bright-Data.png) ](https://brightdata.com.br/blog/ai/openhuman-with-bright-data "Acesso à Web Pronto para Produção no OpenHuman Através do Bright Data CLI") [AI ![Antonello Zanini](https://media.brightdata.com.br/2022/12/Antonello-Zanini-2-50x50.jpg) Antonello Zanini Technical Writer ### Acesso à Web Pronto para Produção no OpenHuman Através do Bright Data CLI Integre o Bright Data CLI ao OpenHuman para habilitar acesso à web pronto para produção e coleta de dados para agentes de IA. 09-Sep-2026 14 min de leitura ](https://brightdata.com.br/blog/ai/openhuman-with-bright-data) [ ![Multimodal Web Scraping with MiniMax](https://media.brightdata.com.br/2026/09/Multimodal-Web-Scraping-with-MiniMax.png) ](https://brightdata.com.br/blog/dados-do-site/multimodal-web-scraping-with-minimax "Scraping de Dados Multimodal com MiniMax") [Dados do site ![Antonello Zanini](https://media.brightdata.com.br/2022/12/Antonello-Zanini-2-50x50.jpg) Antonello Zanini Technical Writer ### Scraping de Dados Multimodal com MiniMax Combine a API Web Unlocker da Bright Data com a visão MiniMax M3 para extrair dados estruturados de imagens e capturas de tela de páginas web. 09-Sep-2026 5 min de leitura ](https://brightdata.com.br/blog/dados-do-site/multimodal-web-scraping-with-minimax) [ ![The 10 Best CLI Tools for Codex in 2026](https://media.brightdata.com.br/2026/08/The-10-Best-CLI-Tools-for-Codex-in-2026.png) ](https://brightdata.com.br/blog/ai/best-cli-tools-for-codex "As 10 Melhores Ferramentas CLI para Codex em 2026 – Testadas & Classificadas") [AI ![Daniel Shashko](https://media.brightdata.com.br/2022/04/Daniel-Shashko-2-50x50.png) Daniel Shashko Web Data & AI Expert ### As 10 Melhores Ferramentas CLI para Codex em 2026 – Testadas & Classificadas As 10 ferramentas CLI que tornam o Codex mais rápido e capaz, começando com o Bright Data CLI para acesso real à web de dentro do sandbox. 06-Sep-2026 24 min de leitura ](https://brightdata.com.br/blog/ai/best-cli-tools-for-codex)