Outros Protocolos de Aplicação

1. Definição

Além dos protocolos clássicos (HTTP, DNS, SMTP, FTP, SSH, DHCP), a camada de aplicação abriga dezenas de protocolos especializados em domínios específicos: Internet das Coisas (IoT), mensageria, cache, RPC, comunicação em tempo real, distribuição de arquivos e redes descentralizadas. Este capítulo faz um panorama técnico dos principais protocolos que não foram tratados em capítulos próprios, com foco em porta, RFC, casos de uso e características arquitetônicas.

Visão Geral por Categoria

Categoria	Protocolos Principais
Mensageria / Filas	AMQP, MQTT, STOMP
IoT / REST constraint	CoAP, MQTT, LwM2M
Cache / KV store	Redis, Memcached
RPC / Binário	gRPC, Thrift, Cap'n Proto
Tempo real / Web	WebSocket, WebRTC, Server-Sent Events
Mensageria pessoa-a-pessoa	IRC, XMPP, SIP
Distribuição P2P	BitTorrent, IPFS
Banco de dados	PostgreSQL (5432), MySQL (3306), MongoDB (27017)

2. MQTT — Message Queuing Telemetry Transport

Definido na RFC 9431 (2023, versão 5.0; originalmente IBM 1999), o MQTT é um protocolo de pub/sub leve, projetado para redes com baixa largura de banda e dispositivos com recursos limitados (IoT). Usa TCP na porta 1883 (sem criptografia) ou 8883 (MQTTS, com TLS). Também suporta WebSocket na 9001.

Características

• Modelo: publish/subscribe com broker central.
• Tópicos hierárquicos: casa/sala/temperatura, industria/linha1/sensor/3.
• QoS (Quality of Service):
• 0: at most once (fire-and-forget, não confiável).
• 1: at least once (pode duplicar).
• 2: exactly once (confiável, mais overhead).
• Retained messages: broker guarda última mensagem para novos assinantes.
• Last Will and Testament (LWT): mensagem publicada se cliente desconecta abruptamente.
• Tamanho mínimo de cabeçalho: 2 bytes — ideal para MQTT-SN sobre ZigBee/LoRa.

Casos de Uso

Sensores industriais, smart homes, telemetria veicular, monitoramento ambiental, aplicações mobile com restrição de bateria.

mosquitto_pub -h broker.exemplo.com -t casa/sala/temperatura -m "23.5" -q 1   # Publicar
mosquitto_sub -h broker.exemplo.com -t "casa/+/temperatura" -v               # Assinar

3. AMQP — Advanced Message Queuing Protocol

Definido na RFC 9431 (2023, AMQP 1.0; originalmente 2008), o AMQP é um protocolo de mensageria empresarial com filas, exchanges, bindings e roteamento sofisticado. Usa TCP na porta 5672 (sem TLS) ou 5671 (AMQPS, com TLS).

Características

• Modelo: filas (queues), exchanges (direct, fanout, topic, headers), bindings.
• Semântica rica: ack/nack, requeue, dead-letter, TTL, prioridades.
• Transações: suporte a transações distribuídas.
• Interoperável: RabbitMQ, ActiveMQ, Qpid, Azure Service Bus.

Casos de Uso

Filas de tarefas assíncronas, integração entre microservices, processamento de pedidos em e-commerce, pipelines ETL.

Comparativo MQTT vs AMQP

Critério	MQTT	AMQP
Overhead	Mínimo (2 bytes)	Maior
Caso típico	IoT, telemetria	Enterprise, microservices
Roteamento	Tópicos hierárquicos	Exchanges + bindings
QoS	0, 1, 2	ack/nack
Broker	Mosquitto, HiveMQ	RabbitMQ, ActiveMQ

4. CoAP — Constrained Application Protocol

Definido na RFC 7252 (2014), o CoAP é um protocolo RESTful para dispositivos constrained (IoT). Diferente do HTTP, usa UDP (não TCP) na porta 5683, com confirmação opcional. Tem modelo request/response como HTTP (GET, POST, PUT, DELETE) mas com cabeçalho binário de 4 bytes.

Características

• Transporte: UDP com DTLS (porta 5684) para segurança.
• Métodos: GET, POST, PUT, DELETE (como HTTP).
• Confiabilidade: mensagens Confirmable (CON) ou Non-confirmable (NON).
• Observação: cliente pode "assinar" recurso (Observe header) recebendo updates.
• Descoberta: /.well-known/core lista recursos disponíveis; proxies CoAP ↔ HTTP são comuns.

Casos de Uso

Sensores de baixa potência, redes mesh (Thread, 6LoWPAN), smart cities, iluminação inteligente.

5. Redis e Memcached — Cache e KV Store

Redis (porta 6379)

Definido por documentação proprietária (Salvatore Sanfilippo, 2009), o Redis é um data store em memória com estruturas ricas: strings, hashes, lists, sets, sorted sets, hyperloglog, bitmaps, streams. Suporta persistência opcional (RDB snapshots, AOF log), pub/sub, Lua scripting, cluster com sharding. Comandos típicos: SET/GET (strings), HSET (hashes), LPUSH/BRPOP (filas), PUBLISH (pub/sub), ZADD (sorted sets).

Usos: cache de sessão web, filas leves (Redis Lists), leaderboards (Sorted Sets), rate limiting, real-time analytics, pub/sub para notificações.

Memcached (porta 11211)

Definido em documento livre (Brad Fitzpatrick, 2003), o Memcached é um cache KV simples (apenas strings), sem persistência, sem estruturas complexas. Mais leve que Redis, mas menos flexível. Ainda usado em stack LAMP clássico para cache de sessão PHP.

Característica	Redis	Memcached
Estruturas	Strings, hashes, lists, sets, streams	Apenas strings
Persistência	RDB, AOF	Nenhuma
Cluster	Nativo (Redis Cluster)	Cliente faz sharding
Tamanho máx. valor	512 MB	1 MB (default)
Pub/Sub	Sim	Não
Evicção	LRU/LFU/random	LRU
Latência típica	0.1-1 ms	0.1-1 ms

6. gRPC — Google RPC

Definido pelo Google (2015, open source), o gRPC é um framework RPC moderno sobre HTTP/2 + Protocol Buffers (protobuf). Permite comunicação cliente-servidor tipada, com contratos definidos em arquivos .proto.

Características

• Transporte: HTTP/2 (multiplexado, header compression HPACK).
• Serialização: Protobuf (binário compacto, esquema versionado).
• Modelos: unary (request/response), server streaming, client streaming, bidi streaming.
• Multi-linguagem: geração automática de stubs em Go, Python, Java, C++, Rust.
• Service mesh: integração com Envoy, Istio, Linkerd.

Casos de Uso

Microservices internos (APIs privadas), gRPC-web (frontend), APIs de alta performance, streaming bidirecional. Comparado a REST+JSON: gRPC é 5-10x mais rápido (protobuf vs JSON), tipado, com streaming nativo. Desvantagem: menos legível para humanos, exige geração de código a partir de contratos .proto definindo serviços e mensagens (ex.: rpc SayHello (HelloRequest) returns (HelloReply), rpc Subscribe (stream Req) returns (stream Resp) para bidi streaming).

7. WebSocket (RFC 6455)

Definido na RFC 6455 (2011), o WebSocket é um protocolo que permite comunicação bidirecional full-duplex sobre uma única conexão TCP, com overhead mínimo. Usa a porta 80/443 (mesma do HTTP, sobre HTTP Upgrade).

Características

• Handshake: começa como HTTP normal com header Upgrade: websocket.
• Cabeçalho: 2-14 bytes por frame (vs 200+ do HTTP).
• Frames: text (UTF-8), binary, ping/pong, close.
• Subprotocolos: Sec-WebSocket-Protocol (ex.: chat, graphql-ws).

Casos de Uso

Chat em tempo real, jogos multiplayer web, dashboards ao vivo, colaboração (Google Docs), notificações push, trading platforms. Exemplo client-side:

const ws = new WebSocket("wss://servidor/ws");
ws.onmessage = (e) => console.log("Recebido:", e.data);
ws.send(JSON.stringify({ type: "ping" }));

8. WebRTC

Definido em conjunto W3C + IETF (2011+), o WebRTC é um framework para comunicação em tempo real (áudio, vídeo, dados) peer-to-peer no navegador, sem plugins. Combina ICE, STUN, TURN, DTLS-SRTP e SCTP. Usa UDP preferencialmente (SRTP para mídia, SCTP para dados), com sinalização fora do WebRTC (via WebSocket, SIP) para troca de SDP. NAT traversal via STUN (descobrir IP público) e TURN (relay se P2P falhar). Codecs típicos: VP8/VP9/H.264 (vídeo), Opus (áudio); DataChannel oferece canal de dados arbitrário P2P de baixa latência.

Casos: videoconferência (Google Meet, Discord), chamadas VoIP web, streaming de jogos (Stadia), P2P file sharing entre browsers.

9. IRC e XMPP — Mensageria Pessoa-a-Pessoa

IRC (porta 6667)

Internet Relay Chat, definido na RFC 1459 (1993), é um protocolo de chat em tempo real baseado em servidores federados e canais (#canal). Ainda usado por comunidades open source (Libera.Chat, OFTC), apesar de ter perdido espaço para Slack/Discord.

XMPP (porta 5222)

Extensible Messaging and Presence Protocol, definido na RFC 6120 (2011), é um protocolo de mensageria instantânea federada baseado em XML. Suporta presença (online/offline), mensagens, MUC (Multi-User Chat), VoIP (Jingle). Usado por WhatsApp internalmente (com modificações) e por servidores como ejabberd, Prosody. Comparado ao IRC, o XMPP tem presença rica, formato XML extensível (XEPs, 300+ extensões) e caso típico em IM corporativo e VoIP, enquanto IRC é texto simples para comunidades técnicas. Ambos são federados.

10. BitTorrent e IPFS — Distribuição P2P

BitTorrent

Definido em BEEP/RFC não oficiais (Bram Cohen, 2001), o BitTorrent é um protocolo P2P de distribuição de arquivos. Arquivos são divididos em pedaços (256KB-1MB), e peers trocam pedaços entre si, aliviando carga do servidor original. Usa tracker (HTTP/UDP) ou DHT (Kademlia, trackerless). Magnet links (magnet:?xt=urn:btih:...) identificam torrent por hash. uTP (BEP 29) é transporte UDP confiável, melhor para P2P.

IPFS

InterPlanetary File System (Juan Benet, 2015) é um sistema de arquivos distribuído baseado em conteúdo (content-addressable). Cada arquivo recebe um CID (Content Identifier) derivado do hash do conteúdo, permitindo deduplicação e imutabilidade. Usa Bitswap para troca de blocos entre peers, DNSLink para integração com DNS (_dnslink.dominio.com TXT) e gateways HTTP→IPFS (https://ipfs.io/ipfs/<CID>).

11. Tabela Resumo de Portas e RFCs

Protocolo	Porta	RFC	Transporte
MQTT	1883 / 8883	9431	TCP
AMQP	5672 / 5671	9431	TCP
CoAP	5683 / 5684	7252	UDP
Redis	6379	(proprietário)	TCP
Memcached	11211	(proprietário)	TCP
gRPC	80/443 (HTTP/2)	(Google spec)	TCP
WebSocket	80/443	6455	TCP
WebRTC	49152-65535	W3C+IETF	UDP (pref.)
IRC	6667 / 6697	1459	TCP
XMPP	5222 / 5269	6120	TCP
BitTorrent	6881-6889	BEP 3	TCP+UDP
IPFS	4001 (p2p), 5001 (API)	(spec)	TCP

12. Boas Práticas por Categoria

• IoT: TLS obrigatório (MQTTS, CoAPS); autenticação por certificado; tópicos com ACL.
• Mensageria: ack manual; dead-letter queue; monitoramento de lag.
• Cache: TTL sempre definido; limitar memória; replicação para HA.
• RPC: versionamento de schema (protobuf); interceptors para tracing.
• Tempo real: heartbeat/keepalive; reconexão com backoff; auth por token.
• P2P: verificação de integridade (hashes); limites de banda.

13. Conclusão

A camada de aplicação da internet contemporânea é muito mais rica que o conjunto HTTP/DNS/SMTP clássico. Protocolos especializados como MQTT e CoAP dominam o IoT; AMQP e Redis sustentam microservices e filas; gRPC substitui REST em APIs internas de alta performance; WebSocket e WebRTC habilitam comunicação em tempo real no browser; BitTorrent e IPFS distribuem conteúdo de forma descentralizada. Conhecer esse ecossistema é essencial para arquitetos e engenheiros de redes modernos, pois a escolha do protocolo de aplicação impacta diretamente performance, segurança, custo e escalabilidade da solução.