TCP/IP na prática: o que os pacotes fazem enquanto a página carrega
Aprendi TCP/IP não em livro mas no Wireshark, olhando para o tráfego real de uma rede com problema. O que isso muda em como você escreve código.
Wireshark aberto, captura rodando, e eu olhando para um rio de pacotes sem entender o que estava vendo.
O problema: uma aplicação interna tinha latência intermitente. Às vezes carregava rápido, às vezes demorava 8-10 segundos sem razão aparente. Servidor respondendo, rede "funcionando", mas a experiência do usuário era ruim.
Meu supervisor chegou, olhou a captura por dois minutos, e apontou para um padrão que eu não tinha visto: retransmissão TCP. O cliente enviava pacote, não recebia confirmação no tempo esperado, reenviava. Isso acontecia várias vezes antes de a conexão se estabilizar.
Problema estava num switch com buffer cheio em horários de pico — descartando pacotes, forçando retransmissão, multiplicando a latência.
Mas o que ficou não foi a solução. Foi entender o que eu estava vendo.
TCP é protocolo de entrega confiável. Isso significa: cada pacote precisa ser confirmado pelo destinatário. Se a confirmação não chega dentro de um tempo, o remetente reenvia.
Quando você abre uma página, está acontecendo isso:
Primeiro, handshake TCP de 3 vias: SYN do cliente, SYN-ACK do servidor, ACK do cliente. Três viagens antes de um byte de dado ser transferido. Em conexão com latência de 200ms, só o handshake custa 600ms.
Depois, dados fluem em segmentos. Cada segmento confirmado pelo destinatário. Janela de congestionamento controla quantos segmentos podem estar "em voo" sem confirmação — começa pequena, cresce com o tempo (slow start).
Retransmissão acontece quando confirmação não chega. O tempo de espera antes de retransmitir (RTO) começa alto e pode chegar a segundos.
O que isso muda em como você escreve código:
Latência de rede não é zero. Código que faz dez requisições sequenciais para construir uma página assume latência zero. Em rede real, cada requisição tem round-trip time. Dez requisições com 50ms de RTT cada = 500ms só de rede, sem contar processamento.
Conexão TCP tem custo de setup. Abrir nova conexão TCP para cada requisição desperdiça o handshake. Connection pooling, keep-alive, HTTP/2 multiplexing existem para reutilizar conexões já estabelecidas.
Packet loss afeta performance de formas não-lineares. 1% de perda de pacotes com retransmissão pode dobrar ou triplicar a latência percebida. Código que não trata retry com backoff exponencial vai amplificar o problema.
Tamanho do payload importa. Janela de congestionamento começa pequena. Resposta grande demora mais para transmitir do que resposta pequena não só pelo tamanho — mas porque o TCP precisa de tempo para "aprender" que pode enviar mais rápido.
Não é necessário saber TCP/IP no nível de implementar um stack. Mas entender o modelo — que cada requisição tem custo de round-trip, que conexão tem custo de setup, que perda de pacote tem custo não-linear — isso muda as decisões que você toma ao escrever código que vai em produção.
Essa semana: qual é a requisição de rede no sistema que você opera que você nunca mediu o round-trip time real em produção?