Protocolo Tcp Ip

O que realmente acontece quando você abre uma página

Você clica em um link. O navegador faz uma requisição. O servidor responde. Entre esses dois eventos, dezenas de pacotes são gerados, endereçados, enviados, recebidos e descartados. O protocolo tcp ip é o conjunto de regras que governa tudo isso. Não é mágica. É engenharia antiga com décadas de refino.

A divisão entre TCP e IP

Muita gente começa achando que TCP e IP são a mesma coisa porque sempre vão juntos. Não são. IP é o sistema de endereçamento e roteamento. Ele pega um pacote e tenta entregá-lo no endereço certo. Não garante que o pacote chegue. Não garante a ordem. Não verifica se os dados estão intactos. É um serviço best-effort. Se um pacote se perde no caminho, IP simplesmente não faz nada a respeito. TCP é quem entra depois. Ele estabelece uma conexão, numerador os segmentos, solicita retransmissões quando algo falta, controla a velocidade de envio para não sobrecarregar a rede e garante que os dados cheguem na ordem correta. Sem TCP, você teria que implementar toda essa lógica manualmente em cada aplicação. Por isso HTTP, FTP, SSH e a maioria dos protocolos de camada superior usam TCP.

O handshake de três vias na prática

O handshake SYN-SYN-ACK-ACK não é apenas um ritual teórico. Você pode vê-lo acontecendo em tempo real com um sniffador de rede. Abriu um terminal, rodou tcpdump ou Wireshark, e fez uma conexão simples. Vai ver exatamente isso: cliente envia SYN, servidor responde SYN-ACK, cliente confirma com ACK. Leva cerca de 30 a 80 milissegundos em conexões locais. Em conexões internacionais pode passar de 200ms só nessa etapa. Um detalhe que pouca gente menciona é que o handshake acontece toda vez que uma nova conexão TCP é aberta. Isso significa que cada requisição HTTP/1.1 sem keep-alive adiciona pelo menos um round-trip extra antes de qualquer dado útil ser transferido. HTTP/1.1 resolve parcialmente isso mantendo conexões abertas. HTTP/2 multiplexa sobre uma única conexão TCP. Ainda assim, o custo inicial do handshake existe e some apenas quando você entende que connection pooling não é luxo, é necessidade.

Janelas de transmissão e o gargalo invisível

O TCP usa um mecanismo chamado windowing para controlar quantos dados podem estar em trânsito sem precisar de um ACK para cada byte. A janela começa pequena e cresce conforme o reconhecimento de que a rede está respondendo. Esse crescimento é governado por algoritmos de congestionamento como Reno, Cubic e BBR. O problema prático é que muitos ambientes empresariais têm firewalls e balanceadores de carga que inspectam e eventualmente modificam pacotes TCP. Quando um dispositivo intermediário corta conexões inativas por segurança, ele interrompe o estado da janela. A conexão cai silenciosamente do ponto de vista da aplicação se ela não tiver timeouts adequados configurados. Eu passei duas semanas investigando timeouts aleatórios em um sistema que enviava relatórios a cada três minutos. Nada nos logs indicava erro de rede. Descobri que o firewall do datacenter central tinha timeout de 180 segundos para conexões TCP inativas. O relatório levava mais de três minutos para gerar às vezes. A solução foi simples: aumentar o timeout no firewall ou mudar a frequência de keep-alive no cliente para menos de 120 segundos.

Subnetting e endereçamento IP

Por que CIDR incomoda quem não está acostumado

Endereçamento clássico com classes A, B e C é ensinado em todo material introdutório. CIDR substituiu isso e é mais eficiente, mas exige que você domine operadores bitwise. Um /24 significa 256 endereços. Um /25 divide isso ao meio. Um /28 dá apenas 16 endereços. A matemática é simples, mas a confusão aparece quando você precisa calcular rapidamente quantas sub-redes consegue extrair de um bloco /20 ou quantos hosts cabem em um /27 com os bits de rede e broadcast reservados. O erro mais comum que eu vejo acontecer em projetos reais é o cálculo incorreto do endereço de broadcast de uma sub-rede. Alguém subneta uma faixa /24 em pedaços menores e acaba sobrepondo intervalos porque confundiu onde termina uma sub-rede e onde começa a próxima. Isso gera conflitos de IP que aparecem como problemas intermitentes de conectividade. A ferramenta mais simples para evitar isso é desenhar uma tabela com o início e o fim de cada bloco antes de aplicar qualquer configuração.

DHCP versus IP estático: a escolha que ninguém discute direito

IP estático parece mais seguro para servidores porque não depende de um serviço externo. DHCP é mais prático para grandes parques de dispositivos porque automatiza a distribuição. A verdade é que ambos funcionam bem desde que bem configurados. O risco do DHCP está nos scopes mal dimensionados e na falta de reservations para servidores que precisam de endereço fixo. Se um servidor de bancos de dados receber um IP diferente após uma renovação de lease, tudo que depende daquele endereço quebra sem aviso prévio. Eu configurei um ambiente de desenvolvimento com vinte containers Docker rodando em máquinas virtuais. Cada container pedia um IP via DHCP. Após um restart do host, três containers receberam IPs diferentes. Dois serviços de dependência interna pararam de funcionar porque estavam referenciando os endereços antigos. Resolvi com reservations no servidor DHCP vinculas às MAC addresses dos containers. Depois migrei para endereçamento estático dentro de uma sub-rede dedicada para não depender mais do DHCP.

Debugging de problemas TCP/IP

O que olhar quando a conexão falha

Quando algo não conecta, a lista de possibilidades é enorme. Firewall bloqueando a porta. Roteamento incorreto. DNS não resolvendo. Serviço ouvindo no endereço errado. Interface de rede caída. NAT mal configurado. O processo de eliminação é chato mas necessário. As ferramentas básicas são ping para testar reachableness, traceroute para mapear o caminho, netstat ou ss para verificar portas ativas e listen, curl com flags de verbose para testar a aplicação em si, e tcpdump para capturar o que realmente está trafegando na interface. A maioria dos problemas se resolve entre as três primeiras ferramentas. tcpdump é para quando você já eliminou tudo o mais óbvio.

Tempo de reconexão e a dor dos retransmits

Uma falha de rede causa retransmissões TCP. O protocolo espera um tempo crescente antes de desistir. Se a latência for alta ou o Loss severo, o tempo de reconexão pode passar de trinta segundos. Aplicações web modernas lidam com isso usando timeouts curtos e retry com backoff exponencial. Infraestruturas legadas muitas vezes ignoram esse comportamento e simplesmente travam até o timeout padrão do SO expirar. Num projeto de migração de infraestrutura para a nuvem, notei que requisições que antes levavam 200ms para responder passaram a demorar até oito segundos em momentos de congestão. A causa não era o código. Era o caminho pela internet pública entre duas regiões do mesmo provedor de nuvem. O TCP reduzia agressivamente a janela de transmissão devido a perdas moderadas. A solução envolveu configurar um circuito dedicado ou VPN entre as regiões para eliminar a variabilidade da internet pública. O custo aumentou, mas a latência ficou estável em 45ms.

MTU e o problema dos pacotes fragmentados

A maioria das redes opera com MTU de 1500 bytes. VPNs, tunéis e alguns links point-to-point reduzem esse valor. Se um pacote maior que o MTU efetivo do caminho é enviado, ele pode ser descartado silenciosamente se o bit DF (Don't Fragment) estiver definido. TCP normalmente ajusta o MTU dinamicamente, mas esse ajuste falha se pacotes ICMP de tamanho necessário não chegarem ao remetente. Firewalls que bloqueiam ICMP Type 3 Code 13 (Fragmentation Needed) quebram silenciosamente conexões TCP com payloads grandes. Eu identifiquei esse comportamento quando um serviço de upload de arquivos grandes funcionava normalmente para arquivos abaixo de 10MB e falhava consistentemente acima disso. O diagnóstico veio do comparison entre conexões dentro da LAN, que usavam MTU normal, e conexões saindo pela VPN com MTU reduzido para 1400. A correção foi ajustar o TCP MSS no gateway da VPN para 1360 e liberar o tráfego ICMP necessário. A partir daí, o problema sumiu.

Considerações finais sobre estabilidade de rede

Protocolo tcp ip é estável quando bem compreendido e problemático quando negligenciado. A maior parte dos incidentes não vem de falhas no protocolo em si. Vem de configurações incorretas, timeouts mal ajustados, firewalls bloqueando tráfego esperado e ferramentas de monitoramento que não capturam o que importa. Manter documentação atualizada de endereçamento, políticas de firewall, reservas DHCP e faixas de monitoramento evita a maioria dos problemas antes que eles aconteçam. Se você está começando agora, pratique com tcpdump e entenda o que cada packet significa. Configure uma VM, faça uma conexão simples, capture e analise. A teoria fica clara quando você vê os bytes no fio.