Três órgãos, esse troço, se for realmente começar do zero, a dificuldade não está nem de longe em “escrever um encaminhador”, e sim em “aguentar uma pilha de trabalho sujo e pesado”.
Mais ou menos dá nessas montanhas:
-
Design de protocolo
Como fazer o handshake
Como fazer a autenticação
Precisa ou não de multiplexação
Como tratar UDP, TCP, DNS de forma unificada
No começo você faz do jeito mais simples; depois quase sempre acaba reescrevendo por causa de extensibilidade -
Pilha de rede multiplataforma
Windows / Linux / macOS / Android / iOS: o comportamento é todo diferente
TUN/TAP, proxy do sistema, rotas, formas de assumir o DNS — tudo é diferente
O realmente nojento é compatibilidade de plataforma, não aquelas poucas linhas de socket -
Desempenho
Quando o número de conexões sobe, os problemas aparecem
buffer, copy, contenção de lock, escalonamento de corrotinas, fragmentação de memória, custo de syscall
Uma conexão rodar bem não significa que aguenta a realidade -
Estabilidade
Reconexão após queda
Troca de rede
Suspender/retomar (sleep/wake)
NAT / IPv6 / MTU / fragmentação
Com muitos cenários anômalos, só de ler logs a pessoa ganha PTSD -
Criptografia e segurança
Troca de chaves
Proteção contra replay
Sigilo futuro (forward secrecy)
Restauração de sessão
Segurança na distribuição de configuração
Aqui o mais perigoso é “inventar criptografia”, isso é pedir pra aumentar a dificuldade pra si mesmo -
Estratégia de tráfego e encapsulamento
Como fatiar pacotes
Como esconder o header
Como evitar que a assinatura fique fixa demais
Essas coisas não acabam em “consegue comunicar”, e sim em “não explode a longo prazo” -
Tratamento de DNS
Resolver localmente ou remotamente
DoH / DoT / UDP puro
Poluição, cache, consistência, vazamento
Muita coisa de “conectou mas tá estranho” é culpa do DNS -
Roteamento e split-tunneling
Global, por regra, por domínio, por IP, por processo
GeoIP / GeoSite / regras customizadas
O sistema de regras vai crescendo até virar meio interpretador -
Observabilidade
Logs
tracing
Estado das conexões
Painel de estatísticas
Sem isso, você depura na base do misticismo e da fé -
Sistema de configuração
Hot reload
Compatibilidade de configuração
Migração de versão
Validação de schema
O usuário adora escrever configuração como lixo e depois xingar o core de instável -
Ecossistema de cliente
GUI
Assinaturas
Importar/exportar configuração
Integração com o sistema
Quando vira produto de verdade, o core nem sempre é a maior parte do código; o entorno é que é -
As armadilhas do próprio “programar com ajuda de AI”
AI é muito boa em escrever código de rede “que parece certo”
Mas em concorrência, condições de contorno e máquina de estados de protocolo, ela enterra minas com facilidade
Ela ajuda a montar a estrutura, completar boilerplate, escrever testes
Não substitui validar se o protocolo está correto
No fim costuma virar: AI gera código em 5 minutos, você passa 5 horas no Wireshark achando o culpado
Se for só fazer um núcleo simples, a dificuldade mais realista em engenharia na verdade é:
Definir primeiro o objetivo mínimo
Não começar já multiplataforma
Não começar já inventando protocolo
Não começar já fazendo motor de regras
Não começar já tentando “arquitetura universal de alta performance”
Senão vira fácil:
Primeira semana: vou fazer o núcleo de próxima geração
Segunda semana: primeiro vou fazer o forward de TCP funcionar
Terceira semana: por que o DNS explodiu de novo
Quarta semana: melhor eu ir mexer num projeto existente
Resumo ácido em uma frase:
Do zero, escrever “que roda” não é tão difícil; difícil é escrever algo “manutenível a longo prazo, multiplataforma, estável, extensível, e com performance que não seja uma porcaria”.
Se você quer avaliar “com AI auxiliando, quão difícil é sair do zero até um MVP usável”, posso continuar nesse recorte e decompor em:
Protótipo de 2 semanas
1 mês pra uso próprio
3 meses pra não virar prisão de manutenção
Essas versões.