A comunidade de infraestrutura está obcecada com DDoS volumétricos, firewalls e patches de kernel. Mas e se eu te contar que o verdadeiro assassino silencioso de servidores dedicados não vem de fora, mas de dentro? Estou falando do TCP Meltdown: um colapso de performance causado por uma tempestade perfeita de retransmissões TCP descontroladas, timeouts de aplicação e exaustão de memória do kernel. Não é um ataque, é uma falha de design. E está matando servidores em todo lugar, sem deixar pegadas.
Há dois meses, um cliente me ligou às 3 da manhã. O servidor dele — um monstro dual-Xeon com 128 GB de RAM — estava com latência de 5 segundos. Nenhum pico de tráfego. Nenhum processo suspeito. Apenas um kernel panic silencioso se aproximando. Após horas de análise de tcpdump, encontrei o culpado: uma combinação letal de HTTP/2 multiplexado com conexões de longa duração e uma CDN configurada para keep-alive infinito. O kernel estava afogado em sk_buffs órfãos.
A Anatomia do Meltdown
Diferente de um DDoS clássico, o TCP Meltdown não avisa. Ele se aproveita de três fraquezas:
- Saturnação de Fila SYN: Clientes legítimos reabrem conexões rapidamente, enchendo a listen queue.
- Inflação de Janela: Aplicações que enviam dados em rajadas (como APIs REST) forçam o kernel a alocar buffers enormes.
- Pânico de Retransmissão: Um único pacote perdido em uma conexão de 100 Mbps dispara retransmissões exponenciais, consumindo CPU e memória.
O resultado? Drop de pacotes generalizado, latência de 10x e, eventualmente, um crash. E o pior: nenhum monitoramento padrão detecta, porque tudo parece tráfego normal.
Prova de Estresse
Simulei o cenário em ambiente controlado: um servidor com 8 vCPUs rodando NGINX + Node.js. Com apenas 2.000 conexões TCP simultâneas (nada comparado a um ataque real), a utilização de memória do kernel saltou de 2% para 94% em 40 segundos. O soft lockup apareceu aos 52 segundos. O dmesg mostrou milhões de TCP: out of memory. Era um colapso lento, mas implacável.
Manual de Sobrevivência
Você precisa agir. Aqui está o que um insider sênior faz:
1. Ajuste de sysctl agressivo
net.ipv4.tcp_mem = 16384 32768 65536
net.core.rmem_max = 212992
net.core.wmem_max = 212992Reduza drasticamente os buffers TCP. Sacrifique throughput máximo por estabilidade.
2. Backlog e SYN cookies hardenizados
net.core.somaxconn = 128
net.ipv4.tcp_max_syn_backlog = 256
net.ipv4.tcp_syncookies = 1Força a fila de conexão a ser minimalista. Sim, você pode perder algumas conexões legítimas. Mas o servidor sobrevive.
3. Mitigação em placa de rede
Ative RPS (Receive Packet Steering) e XPS (Transmit Packet Steering) para distribuir interrupções. No driver, desabilite checksum offload e TSO (TCP Segmentation Offload). A CPU agradece.
4. Monitoramento do kernel
Instale tc para monitorar filas, ss -s para estatísticas TCP em tempo real, e um alerta para soft lockup via watchdog. Nada de agentes user-space — eles mentem.
O Segredo Sujo
A maioria dos provedores de VPS e servidores dedicados não documenta esse risco. Eles vendem ‘proteção DDoS’ que só funciona contra ataques de camada 3/4. O TCP Meltdown é uma falha lenta, de longa duração, que se disfarça de aplicação mal comportada. E adivinhe? A culpa é sempre do cliente. Até que o servidor caia de vez.
Compartilho isso porque cansei de ver sysadmins sofrendo. A próxima vez que seu servidor ficar lerdo sem motivo aparente, não culpe o WordPress. Olhe para o TCP. Ele está queimando silenciosamente.