O que acontece se você não usar TCP nem UDP?

• A infraestrutura de rede é composta por switches, bridges, roteadores, load balancers, firewalls etc.
• O sistema operacional controla a comunicação de rede, classificando pacotes, colocando-os em filas e aplicando regras de firewall.
• Então, o que aconteceria se usássemos um protocolo da camada de transporte inexistente?
• O SO permitiria? Os pacotes seriam realmente entregues? O firewall bloquearia?
• Foi feito um experimento direto para verificar isso.

Visão geral dos protocolos da internet

• A internet funciona com várias camadas de protocolos transmitindo dados
• Quando uma aplicação envia uma requisição, o SO a transmite encapsulando-a com cabeçalhos de várias camadas de rede
• Camada de transporte (Transport Layer): é onde ficam protocolos como TCP (6) e UDP (17)
• O que aconteceria se alterássemos o campo Protocol do cabeçalho IP para inserir um número não usado?

Experimento #1: teste direto no meu PC

Método do experimento

1. Definição do HDP (protocolo falso): criação de um novo protocolo de camada de transporte totalmente diferente dos existentes
2. Implementação de servidor e cliente: desenvolvimento de programas para enviar e receber pacotes
3. Teste em loopback: observação de como o SO processa os pacotes internamente

Execução

$ sudo cargo run --bin server  # executa o servidor  
$ fortune | cowsay | sudo cargo run --bin client 127.0.0.1  # executa o cliente  

Resultado

• O SO processou normalmente os pacotes HDP, que foram recebidos de volta pela interface de loopback
• Foram feitos testes adicionais alterando o número do protocolo IP
  • 1 (ICMP), 2 (IGMP), 6 (TCP) → não detectado no servidor
  • 50, 51 (protocolos relacionados ao IPSec) → o próprio envio foi bloqueado no cliente
  • 256 (fora do intervalo de números de protocolo IP) → erro na etapa da chamada socket()

Análise da causa

• Em alguns casos, o SO bloqueia determinados números de protocolo por estarem reservados pelo sistema
• No Darwin (macOS baseado em BSD), ao definir protocol=0 na chamada socket(), alguns pacotes são filtrados automaticamente
• Protocolos relacionados ao IPSec provavelmente são bloqueados por motivos de segurança
• Como o número de protocolo IPv4 tem 8 bits, só são válidos os valores de 0 a 255

Experimento #2: envio de pacotes pela internet

Plano do experimento

1. Configuração de uma VPS da DigitalOcean: montagem do ambiente de teste em um servidor em nuvem em Frankfurt, Alemanha
2. Envio de pacotes HDP: transmissão dos pacotes do meu PC (na Arábia Saudita) para o servidor da DigitalOcean
3. Análise da reação dos equipamentos de rede: verificar se os pacotes chegam e se o firewall os bloqueia

Resultado esperado

• Os pacotes HDP poderiam ser entregues normalmente, ou algum ISP ou o firewall da DigitalOcean poderia bloqueá-los

Resultado real

• Apenas o primeiro pacote foi entregue, e os seguintes foram bloqueados
• Resultado verificado com tcpdump:
  • Os pacotes saíram normalmente do meu PC
  • No servidor da DigitalOcean, apenas o primeiro pacote foi detectado
  • Os pacotes seguintes foram bloqueados em algum ponto (NAT, firewall, ISP etc.)

Análise da causa

• A DigitalOcean não oferece suporte a protocolos IP não padronizados
• É bastante provável que a principal causa seja a política de firewall do provedor de nuvem
• Não está claro por que apenas o primeiro pacote chegou

Novo teste na AWS

• O experimento foi repetido na AWS usando duas instâncias
• Dentro do mesmo datacenter, os pacotes HDP foram enviados e recebidos normalmente
• Porém, ao transmitir pela internet, ocorreu o mesmo problema da DigitalOcean: apenas o primeiro pacote chegava

Principais problemas

• NAT (Network Address Translation): como funciona com base em portas TCP/UDP, não há como lidar com um novo protocolo como o HDP
• Firewall/filtragem de rede: a maioria dos ISPs e provedores de nuvem bloqueia protocolos IP não aprovados
• Problemas de otimização em equipamentos de rede: alguns dispositivos podem simplesmente descartar pacotes não padronizados

Conclusão: usar TCP e UDP é a melhor opção

• As implementações da stack de rede variam entre os sistemas operacionais
  • O comportamento de socket() no Linux, macOS e Windows é diferente em cada um
• Firewalls e dispositivos NAT bloqueiam protocolos não padronizados
  • Mesmo que funcione em uma rede privada, na internet isso é quase impossível
• Não há ganho de desempenho
  • Já existem alternativas comprovadas, como o QUIC implementado sobre UDP
• Use TCP/UDP
  • Ao usar protocolos padrão, NAT baseado em portas, firewall e roteamento passam a ser suportados automaticamente

Material adicional

• Especificação do protocolo UDP
• Lista de números de protocolo IP
• Diferenças de raw sockets entre plataformas

[junhochoi]

Acho que ler https://www.saturnsoft.net/network/2019/03/21/quic-http3-1/ também pode ajudar.

[secret3056]

Lembro que, antigamente, quando jogava multiplayer de StarCraft via Hamachi, existia o IPX, e me recordo de ter ficado bem curioso sobre o que exatamente era aquilo naquela época.

[secret3056]

Pensando bem, o NAT acabaria bloqueando tudo... Se o IPv6 se consolidar completamente e o NAT desaparecer (embora isso pareça improvável), talvez também seja possível se comunicar usando um protocolo criado por você mesmo.

[tujuc]

Oh, boa tentativa...
A ideia de abalar as bases da rede foi boa, mas todos os equipamentos de rede deste mundo são especializados em TCP/UDP, então...

Quando você não sabe que equipamento de rede é algo feito em escala... até parece possível... mas, quando descobre, percebe que, a menos que você faça muito sucesso e consiga fazer todo mundo usar o seu protocolo, não dá para fazer isso...

[GN⁺]

Comentários no Hacker News

• Existe o SCTP, um protocolo antigo superior ao TCP, mas que não foi adotado
  • Isso aconteceu porque o hardware de rede bloqueou todo o resto além de TCP e UDP
• Como alguém que implementou vários protocolos de transporte, o maior obstáculo para colocar camadas sobre o IP não são os roteadores WAN, e sim os dispositivos NAT de consumo
  • No caso de um certo roteador da Netgear, o tráfego sobrevivia até o fim, mas sofria uma corrupção específica em que os 4 primeiros bytes viravam 0
  • A suspeita é que isso tenha sido tratado como TCP/UDP, mas sem seguir o caminho real de tradução
• Se você não usar TCP ou UDP, a comunicação provavelmente será difícil
  • A internet adotou TCP e UDP como padrão
  • Há muitos dispositivos que não conseguem lidar com outros protocolos
  • Substituir todo o hardware da internet levaria ainda mais tempo do que abandonar o IPv4
  • Só uma grande vantagem de um novo protocolo faria empresas e governos gastarem muito para implementar suporte
• O fim do artigo pareceu um cliffhanger
  • Fiquei curioso sobre por que só um único pacote do protocolo customizado passou e o resto foi descartado
• Eu achava que pacotes TCP/UDP eram enviados pela pilha de rede do sistema operacional apenas para processos que escutam uma porta específica
  • Isso pode ser um recurso de segurança, e processos sem permissão não podem escutar certas portas
  • Eu não esperaria que outro processo pudesse capturar todo o tráfego
  • Eu não sabia se era possível capturar tráfego de vários protocolos da camada de transporte
  • Talvez essa chamada de sistema exija privilégios elevados
• Fico imaginando como teria sido se os protocolos de internet e os equipamentos de roteamento fossem projetados do zero hoje em dia
  • Pacotes muito maiores e um protocolo básico no estilo UDP teriam substituído o HTTP
  • Um protocolo simples de streaming teria substituído o TCP e dado suporte à reprodução de vídeo
  • Esses dois protocolos teriam lidado com a maior parte do tráfego de forma mais eficiente
• É a hipótese do "e se reinventássemos a roda?"
• É preciso usar packet sockets
  • Redes IP deveriam encaminhar tudo, mas o NAT é o principal problema
  • Seria interessante tentar isso com IPv6
• Teríamos usado outros protocolos, de antes de TCP/UDP/IP dominar tudo
• Todo mundo teria usado UUCP
  • Ele fazia um trabalho parecido antes de TCP/UDP