College Online
0%

Protocolos de Aplicacao

Modulo 2 · Aula 3 ~25 min de leitura Nivel: Intermediario

Video da aula estara disponivel em breve

Alem do HTTP

HTTP e o protocolo mais conhecido da camada de aplicacao, mas nao e o unico. Dependendo dos requisitos de comunicacao — unidirecional vs. bidirecional, baixa latencia vs. confiabilidade, request-response vs. streaming — existem protocolos mais adequados.

WebSocket

WebSocket e um protocolo que fornece comunicacao full-duplex (bidirecional) sobre uma unica conexao TCP. Ao contrario do HTTP (que e request-response), WebSocket permite que tanto o cliente quanto o servidor enviem mensagens a qualquer momento.

Diagrama 
HTTP (request-response):          WebSocket (full-duplex):

Client ---GET---> Server          Client ---Upgrade---> Server
Client <--200---- Server          Client <---101------- Server
Client ---GET---> Server          (handshake completo)
Client <--200---- Server
                                  Client ---msg1---> Server
(cada request abre/fecha          Client <--msg2----- Server
 ou reutiliza conexao)           Server ---msg3---> Client
                                  Client ---msg4---> Server
                                  (conexao persistente, bidirecional)
Python 
import asyncio
import websockets

# Servidor WebSocket
async def handler(websocket):
    async for message in websocket:
        print(f"Recebido: {message}")
        await websocket.send(f"Echo: {message}")

async def main():
    async with websockets.serve(handler, "localhost", 8765):
        await asyncio.Future()  # roda forever

asyncio.run(main())

Server-Sent Events (SSE)

SSE e um protocolo unidirecional — o servidor envia eventos para o cliente, mas o cliente nao envia dados de volta pelo mesmo canal. E mais simples que WebSocket e funciona sobre HTTP padrao.

Diagrama 
SSE (Server-Sent Events):

Client ---GET /events---> Server
         Accept: text/event-stream

Client <--- event: update         (servidor envia eventos)
            data: {"status": "ok"}

Client <--- event: progress
            data: {"step": 3}

Client <--- event: done
            data: {}

(unidirecional: servidor -> cliente, sobre HTTP)
Python 
from http.server import HTTPServer, BaseHTTPRequestHandler
import time, json

class SSEHandler(BaseHTTPRequestHandler):
    def do_GET(self):
        if self.path == "/events":
            self.send_response(200)
            self.send_header("Content-Type", "text/event-stream")
            self.send_header("Cache-Control", "no-cache")
            self.end_headers()

            for i in range(5):
                data = json.dumps({"step": i, "total": 5})
                self.wfile.write(f"event: progress\ndata: {data}\n\n".encode())
                self.wfile.flush()
                time.sleep(1)

            self.wfile.write(b"event: done\ndata: {}\n\n")

server = HTTPServer(("", 8080), SSEHandler)
server.serve_forever()

gRPC

gRPC (Google Remote Procedure Call) usa HTTP/2 e Protocol Buffers (protobuf) para comunicacao eficiente entre servicos. Suporta quatro padroes: unary, server streaming, client streaming, e bidirectional streaming.

Diagrama 
gRPC vs REST:

REST (HTTP/JSON):                 gRPC (HTTP/2 + Protobuf):
  Texto (JSON)                      Binario (protobuf) - menor
  HTTP/1.1 ou 2                     HTTP/2 obrigatorio
  Sem contrato tipado               Contrato .proto tipado
  Request-response                  4 padroes de streaming
  Simples, universal                Mais rapido, mais complexo

MQTT

MQTT (Message Queuing Telemetry Transport) e um protocolo pub/sub (publish/subscribe) leve, projetado para IoT e conexoes com largura de banda limitada.

Diagrama 
MQTT Pub/Sub:

  Sensor A --publish--> [Broker MQTT] --deliver--> Dashboard
  topic: "temp/sala1"        |                      (subscribed to "temp/#")
  payload: "23.5"            |
                             +--deliver--> App Mobile
                                           (subscribed to "temp/sala1")

Escolhendo o protocolo certo

Referencia 
Cenario                          Protocolo recomendado
────────────────────────────     ──────────────────────
API REST padrao                  HTTP/1.1 ou HTTP/2
Streaming de dados (server)      SSE
Chat, gaming, real-time          WebSocket
Microservicos internos           gRPC
IoT, sensores, eventos           MQTT
Transferencia de arquivos        HTTP (multipart) ou FTP
Email                            SMTP + IMAP/POP3

No harness.os

O MCP (Model Context Protocol) suporta tres transportes, cada um mapeando para um protocolo diferente:

Diagrama 
Transporte MCP      Protocolo base     Quando usar
──────────────      ──────────────     ────────────────────────────
stdio               Pipes do SO        MCP local (mesmo computador)
                                       Mais rapido, sem overhead de rede.
                                       Usado por Claude CLI para MCP servers locais.

SSE                 HTTP + SSE         MCP remoto, read-heavy
                                       Servidor envia resultados via stream.
                                       Usado para MCP servers em Fly.io.

Streamable HTTP     HTTP bidirecional  MCP remoto, bidirecional
                                       Suporta requests em ambas as direcoes.
                                       Novo padrao MCP (2025).

Recomendacao para harness.os:

  Desenvolvimento local:  stdio (zero latencia de rede)
  Staging/producao:       Streamable HTTP (flexivel, bidirecional)
  Monitoramento:          SSE (dashboard recebendo eventos)
i
stdio nao e rede Quando MCP usa stdio, nao ha rede envolvida — a comunicacao acontece via pipes do sistema operacional (stdin/stdout). Isso elimina toda latencia de rede, mas exige que o MCP server rode na mesma maquina que o cliente.

Resumo

Exercicio pratico

Compare stdio vs. SSE vs. Streamable HTTP para MCP no harness.os.

  1. Para cada transporte, descreva: latencia esperada, overhead, quando usar
  2. Em que cenario de deploy do harness.os voce usaria cada um?
  3. Qual transporte e melhor para o orchestrator que coordena multiplos agentes?
  4. E para um dashboard de monitoramento que mostra eventos em tempo real?
  5. Implemente um servidor SSE em Python que simula eventos de sessao do harness.os

Verifique seu entendimento

Qual protocolo seria mais adequado para um dashboard que precisa receber atualizacoes do servidor em tempo real, sem enviar dados de volta?

  • HTTP polling (GET a cada segundo)
  • gRPC bidirectional streaming
  • Server-Sent Events (SSE)
  • MQTT