Redes na faculdade: teoria vs. o que eu já tinha configurado na vida real
Quando a matéria de redes chegou, eu já tinha configurado VLANs, VPN e roteamento em produção. A teoria formalizou o que eu fazia — e revelou onde eu estava errado.
Quando chegou a matéria de Redes de Computadores, eu entrei na aula com confiança.
Afinal, tinha configurado VLANs, mantido VPN site-to-site, resolvido problema de DHCP conflict que travou um andar inteiro. Rede não era abstração para mim — era o ambiente onde eu trabalhei por três anos.
A matéria confirmou parte do que eu sabia. E revelou onde eu estava operando com modelo mental incompleto.
O modelo OSI formaliza o que a prática torna opaco.
Eu sabia que TCP era confiável e UDP não. Sabia que IP fazia roteamento e Ethernet fazia o transporte no segmento local. Mas minha compreensão era operacional — "use TCP para isso, UDP para aquilo" — sem o modelo que explicava por que.
A aula sobre a camada de transporte foi reveladora: o handshake de três vias não é formalidade — é o mecanismo que estabelece números de sequência iniciais em ambos os lados, criando o canal ordenado e confiável. Remove o handshake e você não tem mais como garantir entrega em ordem. O design é consequência da função.
Eu tinha operado com TCP por anos sem ter essa clareza sobre por que o handshake existia.
Onde eu estava errado: subnetting.
Eu sabia o suficiente de subnetting para configurar redes pequenas. Mas quando o professor colocou um exercício de VLSM — Variable Length Subnet Masking, onde você divide blocos de endereços de forma eficiente para redes de tamanhos diferentes — eu tive dificuldade.
Minha prática de trabalho era: pegar a rede padrão que o fornecedor ou o sysadmin anterior tinha definido e manter. Nunca precisei planejar esquema de endereçamento do zero. Nunca precisei calcular quantos endereços host uma rede /26 comporta de cabeça.
Teoria me forçou a entender o que eu tinha apenas operado.
A matéria também formalizou conceitos que eu conhecia intuitivamente:
Broadcast storm. Eu sabia que rede plana sem segmentação era problema. Não sabia que o nome técnico era broadcast storm — quando frames de broadcast se multiplicam exponencialmente porque não há fronteira de domínio de broadcast. O termo me deu vocabulário para explicar por que VLANs existem, não só como usar.
ARP e o gap entre IP e Ethernet. ARP resolve endereço IP para endereço MAC — a ponte entre camada 3 e camada 2. Eu tinha visto ARP tables em diagnósticos, mas nunca tinha pensado formalmente sobre o que o protocolo estava fazendo e por que era necessário.
TTL e loops de roteamento. Time to Live no pacote IP não é sobre tempo real — é contagem de hops, decrementada a cada roteador. Protege contra loop de roteamento onde pacote circula indefinidamente. Eu sabia que TTL existed. Aprendi por que existia.
O que a prática deu que a teoria não deu: diagnóstico sob pressão.
O professor de redes ensinava como as coisas funcionam quando estão funcionando. O trabalho me ensinou como investigar quando não estão — com usuário esperando, clock correndo, nenhuma documentação.
Quando a aula teórica saiu do modelo de protocolo e foi para troubleshooting, eu me saí bem porque tinha o contexto de como problema real se manifesta. Mas o conhecimento de protocolo que a aula me dava era o que transformava instinto de diagnóstico em diagnóstico sistemático.
A aula de Redes foi onde o encontro entre teoria e prática foi mais concreto para mim.
Não porque eu sabia tudo — pelo contrário, foi onde aprendi mais. Mas porque eu tinha referência prática para ancorar o modelo teórico, e o modelo teórico preenchia os gaps que a prática havia deixado.
Essa semana: qual conceito de rede você usa no código sem ter entendido o protocolo por baixo?