Tipos de Comunicação

A comunicação em redes de computadores pode ocorrer segundo três modelos fundamentais de distribuição de pacotes: Unicast, Multicast e Broadcast. Cada modelo define quantos receptores são atingidos por uma única transmissão da origem e impacta diretamente a eficiência, a escala e o desenho de switches e roteadores. A escolha correta do modelo é uma das decisões arquiteturais mais importantes em qualquer projeto de rede.

Este arquivo apresenta a visão consolidada dos três modelos, suas diferenças, casos de uso, impacto nos dispositivos de rede e tendências modernas como Anycast, que embora não seja estritamente um quarto modelo, é frequentemente tratado como tal em discussões arquiteturais.

1. Os Três Modelos Clássicos

A. Unicast (1-para-1)

Comunicação entre uma origem e um único receptor identificado por um endereço específico. É o modelo dominante na internet moderna e a base de protocolos como HTTP, SSH, SMTP e DNS em modo consulta.

• Endereço IPv4: qualquer endereço individual.
• Endereço IPv6: qualquer endereço unicast (global, link-local, ULA).
• MAC destino: endereço físico único do receptor.

B. Multicast (1-para-grupo)

Comunicação entre uma origem e um grupo de receptores que manifestaram interesse. A rede replica o pacote apenas nos pontos de bifurcação da árvore de distribuição, atingindo exclusivamente os hosts membros do grupo.

• Endereço IPv4: 224.0.0.0/4 (Classe D).
• Endereço IPv6: ff00::/8.
• MAC destino: 01:00:5E:xx:xx:xx (IPv4) ou 33:33:xx:xx:xx:xx (IPv6).

C. Broadcast (1-para-todos)

Comunicação entre uma origem e todos os hosts de um segmento de rede. O pacote é entregue a todos os dispositivos da LAN, independentemente de interesse. Não existe em IPv6 - foi completamente substituído por multicast.

• Endereço IPv4: 255.255.255.255 (limited broadcast) ou o endereço de broadcast da sub-rede (ex: 192.168.1.255/24 - directed broadcast).
• MAC destino: FF:FF:FF:FF:FF:FF.
• Comportamento em switch: flooding para todas as portas da VLAN.

2. Tabela Comparativa Completa

3. Contexto Histórico

A evolução dos modelos de comunicação reflete a própria evolução das redes. Na ARPANET original (1969), o modelo dominante era unicast ponto-a-ponto, com mensagens endereçadas a hosts específicos.

Com a popularização das LANs na década de 1980 (Ethernet 10BASE5 e 10BASE2), o broadcast tornou-se o modelo padrão de fato, pois o meio físico compartilhado (coaxial) entregava naturalmente os sinais a todos os hosts conectados. Protocolos clássicos como ARP (1982), DHCP e NetBIOS foram desenhados com base no broadcast para descoberta de serviços.

O multicast IP foi formalizado pela RFC 1112 (1989) por Steve Deering, inicialmente para suportar áudio/vídeo em conferências MBONE (Multicast Backbone, 1992). Embora nunca tenha sido amplamente adotado na internet pública, tornou-se essencial em redes gerenciadas de provedores, datacenters e ambientes corporativos.

Com o IPv6 (RFC 1883, posteriormente RFC 8200), o broadcast foi completamente eliminado. A justificativa é dupla: broadcasts são ineficientes (interrompem todos os hosts) e comprometem a escala em redes grandes. Em seu lugar, IPv6 utiliza multicast bem definido para funções de descoberta:

• ff02::1 - all-nodes (substitui o broadcast para funções amplas).
• ff02::2 - all-routers.
• ff02::1:ff - solicited-node multicast, usado por NDP no lugar do ARP broadcast.

4. Casos de Uso por Modelo

A. Quando usar Unicast

• Comunicação interativa cliente-servidor (web, SSH, RDP).
• Transferência de arquivos (FTP, SFTP, HTTP downloads).
• Consultas DNS individuais.
• Streaming sob demanda personalizado (Netflix, Spotify).
• Troca de mensagens entre dois pontos específicos.

B. Quando usar Multicast

• Distribuição de vídeo ao vivo para múltiplos espectadores simultâneos (IPTV).
• Cotações de mercado financeiro em tempo real.
• Replicação de firmware para milhares de dispositivos.
• Protocolos de roteamento que precisam atingir múltiplos roteadores (OSPF, RIPv2, EIGRP).
• Descoberta de serviços em redes IPv6 (NDP, mDNS).

C. Quando usar Broadcast (apenas IPv4)

• ARP (resolução IP → MAC em redes locais).
• DHCPDISCOVER (cliente busca servidor DHCP).
• NetBIOS name resolution (legado, ambientes Windows antigos).
• Wake-on-LAN (magic packet para despertar hosts adormecidos).

5. Impacto em Switches e Roteadores

Switches L2

Switches Ethernet tradicionais tratam o tráfego de forma diferente conforme o tipo de endereço MAC:

Para evitar inundações de multicast, switches modernos implementam IGMP snooping, que inspeciona mensagens IGMP entre hosts e roteadores, aprendendo quais portas têm membros de cada grupo e encaminhando o tráfego multicast apenas onde necessário. Sem snooping, multicast é tratado como broadcast, anulando sua vantagem.

Roteadores L3

Roteadores são, por padrão, barreiras para broadcast - eles não encaminham broadcasts entre sub-redes (exceto em casos especiais como helper-address para DHCP). Para multicast, roteadores precisam ter PIM habilitado para construir árvores de distribuição entre sub-redes.

6. Anycast - O Quarto Modelo (Distribuição Geográfica)

Embora não seja um tipo estrito de comunicação IP (anycast usa endereços unicast na camada de rede), o Anycast (RFC 4786) é frequentemente tratado como um quarto modelo de distribuição por sua semântica de entrega: um pacote enviado a um endereço anycast é roteado para o nó topologicamente mais próximo que anuncia aquele prefixo.

A. Aplicações Reais de Anycast

• DNS Root Servers: os 13 root servers lógicos (A-M) são, na verdade, mais de 1.500 instâncias físicas distribuídas mundialmente via anycast. O usuário é roteado para a instância mais próxima.
• DNS público do Google (8.8.8.8): anunciado por milhares de POPs (Points of Presence) globalmente.
• Cloudflare (1.1.1.1): rede de mais de 270 cidades usando anycast.
• CDNs modernas: Akamai, Fastly, CloudFront utilizam anycast para rotear usuários ao POP mais próximo.

B. Vantagens do Anycast

• Latência reduzida: o usuário atinge o nó mais próximo geograficamente.
• Alta disponibilidade: se um nó cai, o BGP converte e o tráfego vai para o próximo.
• Proteção contra DDoS: ataques são diluídos entre múltiplos datacenters.
• Balanceamento geográfico natural: sem necessidade de DNS dinâmico.

7. Tendências Modernas

A. Substituição de Broadcast por Multicast em IPv6

Em ambientes IPv6, todas as funções que antes dependiam de broadcast foram redesenhadas para usar multicast com escopo bem definido:

• ARP → NDP (Neighbor Discovery) usando solicited-node multicast.
• DHCPDISCOVER → DHCPv6 Solicit usando ff02::1:2 (All_DHCP_Relay_Agents_and_Servers).
• NetBIOS → mDNS usando ff02::fb.

B. Unicast como Substituto de Multicast na Internet Pública

A maioria das aplicações de streaming ao vivo na internet pública (Netflix, YouTube, Twitch) optou por unicast via CDN, ao invés de multicast inter-domain. Razões:

• Simplicidade operacional: unicast é suportado por qualquer firewall, NAT e ISP.
• Personalização: ABR (Adaptive Bitrate) permite ajustar qualidade por usuário.
• Modelo de negócio: CDN controlado permite monetização e analytics.

Multicast mantém-se relevante apenas em redes gerenciadas internas (provedores IPTV, datacenters, ambientes corporativos).

C. Anycast em Microserviços e Service Mesh

Em arquiteturas cloud-native, service meshes como Istio e Linkerd utilizam conceitos anycast-like via DNS e Envoy para rotear tráfego entre instâncias de microserviços, com failover automático e balanceamento baseado em latência.

8. Boas Práticas de Projeto

• Segmentar broadcasts: usar VLANs para isolar domínios de broadcast; evitar redes /24 maiores que 500 hosts em ambientes críticos.
• Habilitar IGMP snooping em todos os switches L2 com tráfego multicast, evitando inundações desnecessárias.
• Filtrar directed broadcasts em bordas de rede (no ip directed-broadcast em Cisco IOS).
• Planejar endereçamento multicast com faixas 239.0.0.0/8 para uso interno, seguindo estrutura hierárquica.
• Em redes IPv6-only: abandonar completamente mentalidade broadcast; usar multicast com escopo link-local (ff02::) ou site-local (ff05::).
• Para serviços globais: avaliar anycast via BGP com múltiplos POPs ao invés de um único datacenter centralizado.
• QoS para multicast: em ambientes de IPTV/VoIP, marcar tráfego multicast com DSCP CS4 ou EF para garantir prioridade.
• Monitoramento: usar NetFlow/IPFIX para identificar padrões anômalos de broadcast storm ou multicast flooding.

9. Conclusão

A escolha entre Unicast, Multicast, Broadcast e Anycast é uma decisão arquitetural que impacta diretamente a eficiência, escala e resiliência de uma rede. Compreender as características de cada modelo, suas limitações e os cenários onde cada um é ideal é fundamental para qualquer engenheiro de redes moderno, especialmente em um contexto de transição gradual para IPv6 e arquiteturas distribuídas baseadas em CDN e anycast.