Por que a internet trava quando alguém baixa um arquivo

A cena é conhecida em qualquer escritório: alguém começa a baixar um arquivo grande, ou o backup automático dispara, e de repente o sistema de gestão trava, a chamada de vídeo pica e o site simples demora dez segundos para abrir. Você abre um teste de velocidade e ele mostra os mesmos 300 Mbps de sempre.

Esse fenômeno tem nome, tem causa conhecida há mais de uma década e tem solução — que raramente é a que as pessoas tentam primeiro. Chama-se bufferbloat, algo como "inchaço de buffer".

O que está acontecendo de verdade

Todo equipamento de rede tem uma fila. Quando chegam mais pacotes do que ele consegue transmitir naquele instante, os que sobram esperam em memória até a vez deles. Isso é normal e necessário: sem fila nenhuma, qualquer rajada de tráfego viraria perda de pacote.

O problema começou quando a memória ficou barata. Fabricantes passaram a colocar filas enormes nos equipamentos, com a intenção de nunca descartar nada. Parece bom, mas cria um efeito perverso.

Imagine uma fila de banco com espaço para mil pessoas. Ninguém é mandado embora — ótimo. Mas se você chega quando já tem novecentas pessoas na frente, vai esperar horas. Era melhor ter sido avisado na porta que estava cheio, e ter voltado depois.

É exatamente isso que acontece com os seus pacotes. Quando o download satura o link, a fila do roteador enche de pacotes daquele download. O próximo pacote — aquele minúsculo que o seu ERP mandou para salvar um pedido — entra no fim de uma fila de centenas. Ele não é perdido: ele é atrasado. E como o sistema de gestão precisa de dezenas de idas e voltas, cada uma pagando esse atraso, a tela que abria em meio segundo passa a demorar quinze.

Por que o TCP piora o quadro

Existe um detalhe que transforma o incômodo em desastre. O TCP, protocolo que carrega a maior parte do tráfego, descobre a velocidade da rede por tentativa e erro: ele acelera até algo dar errado, e o sinal de "algo deu errado" tradicionalmente é a perda de um pacote.

Quando a fila é gigante, nada se perde por muito tempo — os pacotes só ficam esperando. O TCP interpreta a ausência de perda como "ainda dá para acelerar" e manda mais. A fila cresce ainda mais. A latência sobe ainda mais. O mecanismo que deveria evitar o congestionamento acaba alimentando ele.

O resultado é uma conexão que, no papel, entrega toda a velocidade contratada, mas que na prática fica inutilizável para qualquer coisa interativa enquanto houver uma transferência grande rolando.

O gráfico mostra uma medição real. A mesma conexão, no mesmo minuto: parada, responde em 28 milissegundos; com o link ocupado, em 1,1 segundo. Trinta e nove vezes pior. Nenhum teste de velocidade convencional mostraria isso, porque todos medem com o link livre — que é justamente o momento em que o problema não existe.

Por que o teste de velocidade esconde o problema

Testes de velocidade tradicionais fazem duas medições separadas: primeiro o ping, com a rede parada, depois a velocidade, saturando o link. As duas nunca acontecem ao mesmo tempo. É como medir a temperatura do forno antes de ligá-lo.

Para enxergar bufferbloat é preciso medir a latência durante a saturação. É exatamente isso que a extensão Lento Quem? faz: enquanto o teste de download roda, ela continua enviando sondas pequenas e medindo quanto tempo cada uma leva. A diferença entre a latência ociosa e a latência sob carga é o tamanho do seu problema de fila.

Como interpretar o número

Aumento da latência sob carga	Situação	O que você sente
até 40 ms	Excelente	Nada. Pode baixar à vontade que ninguém reclama.
40 a 120 ms	Bom	Chamada de vídeo pode dar uma engasgada ocasional.
120 a 400 ms	Ruim	Sistema web fica visivelmente lento durante downloads.
acima de 400 ms	Grave	Vídeo trava, jogos ficam injogáveis, sistema parece fora do ar.

Vale reforçar: esse número não tem relação com a sua velocidade contratada. Já vi link de 500 Mbps com dois segundos de inchaço e link de 60 Mbps impecável. O que separa um do outro é o gerenciamento de fila do equipamento, não a largura do cano.

A solução: controle de fila

A correção se chama, genericamente, SQM (Smart Queue Management). A ideia é contraintuitiva: em vez de guardar todos os pacotes, o equipamento passa a descartar alguns de propósito, cedo, antes de a fila crescer. Esse descarte é o sinal que faz o TCP desacelerar na hora certa — e a fila nunca chega a inchar.

Algoritmos modernos como fq_codel e cake fazem isso bem, e ainda separam o tráfego por fluxo, de modo que o download pesado não atropela as mensagens pequenas do sistema de gestão.

Onde procurar no seu roteador

O nome muda conforme o fabricante. Procure por:

• SQM ou Smart Queue Management — em roteadores com OpenWrt, é a opção ideal;
• QoS (Quality of Service) — presente em boa parte dos roteadores domésticos;
• Adaptive QoS ou Bandwidth Control — nomes comuns em ASUS e TP-Link;
• Controle de banda ou Priorização de tráfego — nas traduções em português.

O passo que quase todo mundo erra

Ao ativar o SQM, o roteador pede que você informe a velocidade do link. E aqui está a pegadinha: você precisa declarar um valor ligeiramente abaixo do que contratou — algo entre 85% e 95%.

Parece jogar velocidade fora, mas é o contrário. O controle de fila só funciona se a fila estiver no seu equipamento, onde o algoritmo manda. Se você declarar a velocidade cheia, quem enche primeiro é o buffer do equipamento do provedor, que você não controla — e o problema volta. Sacrificar 10% da velocidade máxima para eliminar um segundo de latência é uma das melhores trocas disponíveis em redes.

Se o roteador não tiver a opção

Muito roteador entregue por provedor não oferece controle de fila decente. As alternativas, em ordem de esforço:

1. Colocar o equipamento do provedor em modo bridge e usar um roteador próprio com SQM;
2. Instalar OpenWrt em um roteador compatível, o que dá acesso ao cake completo;
3. Usar um roteador comercial que já traga QoS adaptativo funcional.

Antes de gastar, meça: se o inchaço estiver abaixo de 100 ms, o dinheiro rende mais em outro lugar.

Bufferbloat de subida: o mais esquecido

Boa parte das conexões brasileiras é assimétrica: 300 Mbps de descida e 30 ou 50 de subida. Como a subida é bem menor, ela satura muito mais fácil — e o bufferbloat de upload costuma ser pior que o de download.

O sintoma clássico: alguém envia um arquivo grande pelo WhatsApp Web ou sobe fotos para a nuvem, e a rede inteira fica lenta, inclusive para baixar. Parece contraditório, mas faz sentido: as confirmações que o seu computador precisa mandar para receber dados ficam presas na fila de subida entupida.

Por isso, ao configurar SQM, configure as duas direções. A de subida costuma dar o ganho mais perceptível no dia a dia.

Como o bufferbloat aparece em cada tipo de uso

O mesmo inchaço de fila produz sintomas diferentes conforme o que você está fazendo, e reconhecer o sintoma acelera muito o diagnóstico.

Em chamada de vídeo, o efeito é imediato e cruel. Voz e imagem precisam chegar em ritmo constante; um pacote atrasado meio segundo é tão inútil quanto um pacote perdido, porque o momento de reproduzi-lo já passou. Por isso a reunião "pica" exatamente quando alguém no escritório começa a enviar um anexo pesado. Quem está do outro lado escuta a voz cortada e conclui que a internet da empresa é ruim, quando na verdade ela está sobrando — mal organizada, mas sobrando.

Em sistema de gestão, o efeito é mais traiçoeiro porque não parece rede. A tela simplesmente demora, sem mensagem de erro, sem indicação de queda. Como o ERP faz dezenas de requisições pequenas para montar uma única tela, e cada uma delas fica esperando na fila entupida, o atraso se multiplica. Uma fila que adiciona 400 ms por requisição transforma trinta requisições em doze segundos de espera — e o usuário jura que o sistema travou.

Em jogos online, o sintoma é o mais conhecido: o famoso "lag" que aparece quando alguém em casa começa a baixar. O jogo depende de atualizações várias vezes por segundo, e qualquer fila destrói essa cadência.

Em navegação comum, o site demora a começar a aparecer mas depois carrega rápido. Isso acontece porque a primeira requisição — a que descobre o endereço e pede o HTML — pegou fila, enquanto o resto veio junto no mesmo fluxo já estabelecido.

Por que o problema persiste em 2026

Se o bufferbloat é conhecido desde 2010 e tem solução pronta, por que ainda encontramos ele em tanta rede? Três motivos se somam.

O primeiro é que memória ficou barata demais. Colocar um buffer grande custa centavos e, em testes de laboratório focados em vazão, buffer grande dá números melhores. O fabricante otimiza para o número que aparece na caixa, e o número que aparece na caixa é megabit por segundo, nunca latência sob carga.

O segundo é que o problema é invisível nas ferramentas que as pessoas usam. Nenhum teste de velocidade popular mede latência durante a saturação, então o usuário nunca vê o número que denuncia o problema. Ele só sente o sintoma e atribui a outra coisa.

O terceiro é que a correção exige configurar, e configurar exige saber que existe. O roteador sai de fábrica com controle de fila desligado ou mal calibrado, e ninguém mexe no que não sabe que está errado.

Um teste caseiro sem ferramenta nenhuma

Se você quiser confirmar a suspeita agora, sem instalar nada, faça o seguinte. Abra um terminal e deixe um ping contínuo rodando contra um endereço estável, como ping 1.1.1.1. Observe os tempos com a rede parada e anote a média.

Agora comece um download grande — uma imagem de sistema operacional, um backup, qualquer coisa que sature o link — e observe o ping enquanto isso. Se os tempos saltarem de 20 ms para centenas de milissegundos, você acabou de reproduzir o problema em trinta segundos. Repita com um upload pesado para testar a outra direção, que costuma ser pior.

Esse teste manual tem um limite: ele mede a latência até um alvo específico e não separa o que é fila do que é rota. Ainda assim, para confirmar a existência do problema, resolve.

Como confirmar que resolveu

Depois de ativar o controle de fila, meça de novo com o link ocupado. Um resultado saudável mantém a latência sob carga próxima da ociosa — variação de algumas dezenas de milissegundos, não centenas.

Faça o teste em condição real: peça para alguém baixar um arquivo grande, ou inicie um upload pesado, e meça durante. Se a latência agora sobe de 20 ms para 45 ms em vez de 900 ms, você acabou de resolver, de graça, um problema que muita gente tenta resolver trocando de plano.

Bufferbloat na rede móvel e no trabalho remoto

Quem trabalha de casa ou usa 4G encontra o problema com uma cara um pouco diferente. Redes móveis costumam ter buffers ainda maiores que roteadores domésticos, porque foram projetadas para lidar com variações bruscas de sinal sem descartar dados. O resultado é que a latência sob carga em 4G pode passar de dois segundos com facilidade.

Nesse cenário você não controla o equipamento, então a mitigação é outra: evitar transferências pesadas enquanto usa algo interativo. Pausar a sincronização da nuvem antes de uma reunião importante resolve mais que qualquer configuração.

Em casa, o agravante é a concentração. Uma residência com streaming em duas TVs, backup automático de celular e videochamada acontecendo ao mesmo tempo satura um link de 100 Mbps com facilidade — e sem controle de fila, tudo degrada junto em vez de dividir de forma justa.

Por que isso importa mais do que parece

Bufferbloat é provavelmente a causa mais subestimada de "internet ruim" em escritório pequeno. Ele produz exatamente o sintoma que confunde todo mundo: a rede parece ótima quando você testa e péssima quando você usa.

É também o motivo de tantas trocas de plano frustradas. A empresa sai de 200 para 500 Mbps, o problema continua, e a conclusão equivocada vira "então é o sistema". Enquanto isso, a fila do roteador continua inchando do mesmo jeito — só que mais rápido.

Se a sua lentidão tem hora para aparecer e coincide com alguém transferindo arquivo, meça a latência sob carga antes de qualquer outra coisa. E se o número for alto, você achou o culpado — e ele não é o sistema de gestão nem o seu provedor: é um parâmetro de configuração esperando ser corrigido.