Você contrata uma conexão de Internet de 500 Mbps, 600 Mbps ou até 1 Gbps. Faz um teste de velocidade e o resultado parece perfeito. O computador está conectado por cabo Gigabit ou por uma boa rede Wi-Fi, o ping está dentro do esperado e aparentemente não existe nenhum problema com a operadora.
Mesmo assim, alguma coisa não fecha.
Um download específico fica muito abaixo da velocidade esperada. Uma transferência entre computadores não consegue aproveitar toda a capacidade da rede. Um arquivo hospedado em um servidor distante demora muito mais para chegar do que deveria. Em determinadas aplicações, a conexão parece rápida nos primeiros segundos e depois simplesmente não consegue aumentar a taxa de transferência.
É natural começar procurando problemas no roteador, Wi-Fi, cabo de rede, DNS ou até na própria operadora.
Porém, existe outro componente que quase nunca recebe atenção: a maneira como o Windows controla as conexões TCP.
Dentro da pilha de rede do Windows existe um mecanismo chamado TCP Receive Window Auto-Tuning, ou simplesmente TCP Auto-Tuning. Ele permite que o sistema ajuste dinamicamente a janela de recepção TCP conforme as características da conexão.
Esse mecanismo se torna especialmente importante quando temos ao mesmo tempo muita largura de banda e alguma latência.
E aqui aparece um conceito fundamental:
ter muita largura de banda disponível não significa automaticamente conseguir utilizá-la em uma única conexão TCP.
Para entender por quê, precisamos abandonar por alguns minutos a ideia de que velocidade de Internet depende apenas de Mbps e olhar para o funcionamento do TCP.
O Speedtest pode estar rápido enquanto outra transferência continua lenta?
Sim.
Esse é justamente um dos pontos que tornam esse tipo de problema difícil de diagnosticar.
Um teste de velocidade e um download real não necessariamente utilizam a rede exatamente da mesma maneira. Aplicativos podem abrir várias conexões simultaneamente, servidores diferentes apresentam capacidades diferentes e cada caminho pela Internet possui características próprias.
Por isso, um resultado próximo da velocidade contratada em um teste não prova que toda transferência TCP individual conseguirá atingir a mesma velocidade.
Imagine, por exemplo:
- conexão de Internet de 1 Gbps;
- computador conectado corretamente por Gigabit Ethernet;
- SSD rápido;
- baixa utilização de CPU;
- teste de velocidade próximo de 900 Mbps;
- download de determinado servidor muito abaixo disso.
Existem várias explicações possíveis.
O servidor remoto pode limitar a velocidade. O caminho até ele pode apresentar congestionamento. Pode existir perda de pacotes. O armazenamento do servidor ou do computador pode virar o gargalo.
Mas também pode existir uma limitação relacionada à própria sessão TCP.
Antes de modificar qualquer configuração do Windows, portanto, precisamos entender o que está acontecendo.
Primeiro: o que é TCP?
TCP significa Transmission Control Protocol.
Grande parte das comunicações tradicionais da Internet utiliza ou historicamente utilizou TCP porque o protocolo oferece uma característica essencial: entrega confiável dos dados.
Quando você transfere informações utilizando TCP, os dados não são simplesmente enviados sem controle.
O protocolo trabalha com mecanismos como:
- confirmação de recebimento;
- ordenação dos segmentos;
- retransmissão quando necessário;
- controle de fluxo;
- controle de congestionamento.
Em uma explicação simplificada, um computador envia dados e o outro confirma o recebimento.
Isso permite detectar segmentos perdidos e reorganizar informações que eventualmente chegaram fora da ordem.
Essa confiabilidade possui enorme importância, mas cria uma consequência:
o TCP precisa controlar quanto dado pode permanecer em trânsito antes de receber confirmações e como deve reagir às condições da rede.
É aqui que começamos a chegar à janela TCP.
O que é a TCP Receive Window?
Imagine uma estrada.
Você possui uma rodovia capaz de transportar enorme quantidade de veículos. Entretanto, existe uma regra dizendo que somente um pequeno número deles pode entrar na estrada antes que alguém confirme a chegada dos anteriores.
Mesmo que a estrada tenha capacidade muito maior, essa regra limita o fluxo.
Algo parecido pode acontecer com TCP.
O dispositivo que recebe os dados informa quanto consegue receber antes que o transmissor precise considerar o espaço disponível na janela.
Esse mecanismo faz parte do controle de fluxo TCP.
A TCP Receive Window, ou janela de recepção TCP, representa a quantidade de dados que o receptor pode aceitar dentro desse processo de comunicação.
Quando a janela disponível fica pequena demais em relação à capacidade e à latência da conexão, o TCP pode deixar de utilizar toda a largura de banda disponível.
É justamente por isso que precisamos falar de outro elemento frequentemente ignorado nos testes de Internet:
Latência não é a mesma coisa que velocidade
Uma conexão pode possuir:
1 Gbps de largura de banda
e ao mesmo tempo:
50 ms de latência até determinado servidor.
Uma característica não elimina a outra.
A largura de banda representa a quantidade de dados que potencialmente pode atravessar a conexão em determinado período.
Já a latência representa o tempo necessário para os dados percorrerem o caminho.
Quando trabalhamos com TCP, as duas coisas acabam relacionadas.
Quanto maior a distância lógica ou geográfica entre os computadores, maior pode se tornar o impacto da latência sobre determinadas transferências.
É por isso que uma transferência dentro da sua própria rede pode se comportar de maneira completamente diferente de outra realizada contra um servidor localizado em outro continente.
Um exemplo simples
Considere dois servidores.
O primeiro está muito próximo e apresenta latência de 3 ms.
O segundo está distante e apresenta latência de 100 ms.
Mesmo que os dois servidores possuam capacidade suficiente para entregar 1 Gbps, uma sessão TCP precisa administrar uma quantidade muito maior de dados em trânsito para aproveitar plenamente a largura de banda no segundo cenário.
Isso nos leva a um conceito muito importante em redes.
O que é Bandwidth-Delay Product?
O Bandwidth-Delay Product, normalmente abreviado como BDP, relaciona largura de banda e atraso.
Podemos imaginar o BDP como a quantidade de dados que precisa estar “em voo” para que determinada conexão consiga manter o canal ocupado.
Em termos simplificados:
BDP = largura de banda × tempo de ida e volta
Vamos imaginar uma conexão de 1 Gbps com aproximadamente 100 ms de RTT.
1 Gbps equivale a aproximadamente 125 MB por segundo.
Se o RTT for 0,1 segundo:
125 MB/s × 0,1 s = aproximadamente 12,5 MB.
Isso significa que pode ser necessário manter uma quantidade significativa de dados em trânsito para aproveitar completamente aquela capacidade.
Agora imagine tentar fazer isso utilizando uma janela TCP muito pequena.
A largura de banda está disponível.
O link está disponível.
O servidor pode ser rápido.
Mas a sessão simplesmente não mantém dados suficientes em trânsito para preencher o caminho.
É como possuir uma enorme tubulação e liberar a água em pequenas porções.
A Microsoft demonstra exatamente a importância dessa relação em sua documentação de ajuste de rede. O tamanho da janela de recepção e a latência influenciam diretamente o throughput máximo possível de uma conexão TCP.
Por que existia uma limitação maior antigamente?
As primeiras implementações TCP trabalhavam com janelas relativamente pequenas para os padrões atuais.
Isso não representava grande problema quando as redes possuíam velocidades muito inferiores às atuais.
Uma conexão doméstica de centenas de megabits ou Gigabit seria algo extraordinário décadas atrás.
Conforme as redes ficaram mais rápidas, porém, tornou-se necessário permitir janelas muito maiores.
É aí que entra o recurso conhecido como TCP Window Scaling.
Ele permite ampliar efetivamente o tamanho da janela TCP para além da limitação original do campo de janela.
Em sistemas modernos, esse mecanismo trabalha em conjunto com outros recursos da pilha TCP para aproveitar redes muito mais rápidas.
No Windows, uma das peças importantes desse processo é justamente o TCP Receive Window Auto-Tuning.
O que é TCP Auto-Tuning no Windows?
O TCP Auto-Tuning permite que o Windows ajuste dinamicamente a janela de recepção TCP de acordo com as características da comunicação.
Em vez de utilizar permanentemente uma janela fixa pequena, o sistema pode aumentar a janela quando identifica que aquela conexão se beneficia disso.
Isso ajuda especialmente em cenários que combinam:
alta largura de banda + maior latência.
O Windows analisa as características da comunicação e pode aumentar a janela de recepção para melhorar o throughput.
Em condições normais, isso acontece automaticamente.
O usuário não precisa calcular manualmente o tamanho ideal da janela TCP para cada servidor acessado.
O próprio sistema operacional administra essa parte.
É justamente por isso que modificar essa configuração sem diagnóstico pode produzir o efeito contrário ao desejado.
O TCP Auto-Tuning deveria ficar habilitado?
Na configuração normal de sistemas modernos, sim.
A documentação da Microsoft estabelece Normal como o nível padrão do TCP Receive Window Auto-Tuning e recomenda verificar essa configuração durante diagnósticos de throughput.
O Windows oferece cinco níveis:
Disabled
Desativa o dimensionamento automático da janela.
A janela fica muito mais limitada, algo que pode prejudicar transferências em determinados cenários de alta largura de banda e maior latência.
Highly Restricted
Permite crescimento da janela, mas de maneira bastante conservadora.
Restricted
Também restringe o crescimento, porém menos agressivamente que o nível anterior.
Normal
É o comportamento padrão e adequado para praticamente todos os cenários normais.
Experimental
Permite crescimento mais agressivo e foi criado para situações extremas.
O nome já fornece uma pista importante:
Experimental não significa “mais rápido”.
Colocar uma configuração no valor máximo disponível não significa automaticamente melhorar o desempenho.
Como verificar o TCP Auto-Tuning do Windows
Agora chegamos à parte prática.
Antes de alterar qualquer coisa, precisamos descobrir a configuração atual.
Abra o Prompt de Comando como administrador.
Execute:
netsh interface tcp show global
Dependendo da versão e do idioma do Windows, aparecerão vários parâmetros relacionados à pilha TCP.
Procure pela informação correspondente ao:
Receive Window Auto-Tuning Level
Em uma configuração padrão, normalmente encontraremos:
normal
Isso indica que o Windows pode ajustar dinamicamente a janela de recepção.
Também podemos verificar pelo PowerShell
Abra o PowerShell e execute:
Get-NetTCPSetting | Select SettingName,AutoTuningLevelLocal
O comando mostra os perfis TCP existentes e os respectivos níveis locais de Auto-Tuning.
O PowerShell também permite uma análise muito mais detalhada:
Get-NetTCPSetting
Esse comando pode apresentar propriedades relacionadas a:
- Auto-Tuning;
- congestion provider;
- ECN;
- timestamps;
- retransmissões;
- parâmetros de congestionamento;
- configurações específicas dos perfis TCP.
Essa abordagem é muito melhor do que simplesmente executar comandos encontrados em fóruns tentando “acelerar a Internet”.
Um alerta sobre os famosos comandos para acelerar a Internet
Existem centenas de tutoriais na Internet com títulos semelhantes a:
“5 comandos CMD para aumentar sua Internet”
“Como liberar 100% da velocidade da Internet”
“Comando secreto para diminuir o ping”
“Como dobrar a velocidade da Internet pelo CMD”
Muitos desses tutoriais apresentam uma sequência de comandos netsh sem explicar exatamente o que cada configuração faz.
Alguns chegam a recomendar:
netsh interface tcp set global autotuninglevel=disabled
como uma suposta otimização universal.
Isso merece bastante cuidado.
Desabilitar o Auto-Tuning pode, em determinados ambientes, reduzir o desempenho em vez de aumentá-lo.
Se a janela de recepção não crescer suficientemente em uma conexão de grande largura de banda e maior latência, uma única sessão TCP pode deixar de aproveitar toda a capacidade disponível.
Portanto, não existe justificativa técnica para desligar recursos aleatoriamente apenas porque um vídeo ou tutorial afirma que aquilo “otimiza a Internet”.
Primeiro diagnosticamos.
Depois modificamos.
E sempre alteramos uma variável por vez.
Por que alguém encontraria o Auto-Tuning desabilitado?
Existem algumas possibilidades.
O computador pode ter recebido anteriormente algum procedimento de “otimização”.
Um programa de tuning pode ter modificado configurações da pilha TCP.
Um script antigo pode ter aplicado alterações.
Uma política administrativa pode controlar determinadas configurações.
Ou alguém pode ter seguido um tutorial antigo criado para resolver incompatibilidades específicas.
Esse último caso merece atenção.
Historicamente existiram equipamentos de rede que apresentavam problemas com TCP Window Scaling.
Firewalls, roteadores e dispositivos intermediários antigos podiam lidar incorretamente com determinados recursos TCP.
Nesses ambientes, reduzir ou desativar temporariamente determinados recursos podia funcionar como teste ou contorno.
Isso não transforma a solução específica em recomendação universal para computadores modernos.
Como restaurar o Auto-Tuning para Normal
Se o diagnóstico mostrar que o Auto-Tuning está desabilitado ou restringido indevidamente, a Microsoft documenta a configuração:
netsh int tcp set global autotuninglevel=normal
Depois, podemos conferir novamente:
netsh int tcp show global
Também existe a possibilidade de gerenciamento pelo PowerShell.
Por exemplo:
Get-NetTCPSetting | Format-List SettingName,AutoTuningLevel*
A Microsoft também documenta o uso de Set-NetTCPSetting para modificar o nível de Auto-Tuning.
Entretanto, existe uma regra importante:
não altere a configuração apenas porque o download está lento.
Precisamos primeiro eliminar os outros gargalos.
Auto-Tuning não é solução para toda Internet lenta
Esse talvez seja o ponto mais importante deste artigo.
Encontrar uma configuração TCP interessante não significa transformar todo problema de velocidade em problema de TCP.
A própria Microsoft recomenda verificar problemas subjacentes da rede, perda de pacotes, configurações da interface, CPU e armazenamento durante diagnósticos de throughput.
Na prática, precisamos investigar uma cadeia inteira:
Internet → modem/ONT → roteador → Wi-Fi/Ethernet → computador → pilha TCP → aplicação → servidor remoto.
Qualquer elemento dessa sequência pode limitar a transferência.
1. Verifique a velocidade negociada da placa de rede
Imagine contratar 600 Mbps de Internet e conectar o computador por uma interface negociada a 100 Mbps.
Nenhum ajuste TCP fará aquela conexão física ultrapassar o limite do enlace.
No Windows, verifique a velocidade de link do adaptador.
Em Ethernet Gigabit, normalmente esperamos uma negociação de:
1,0 Gbps
quando computador, cabo e porta do roteador suportam Gigabit Ethernet.
Caso apareçam 100 Mbps, investigue:
- cabo;
- conectores;
- porta do roteador;
- placa de rede;
- configuração do adaptador.
Antes de mexer no TCP.
2. Faça testes por cabo quando possível
Wi-Fi adiciona inúmeras variáveis.
Interferência, distância, obstáculos, largura do canal, quantidade de dispositivos, potência do sinal, padrões 802.11 e concorrência pelo meio podem alterar significativamente o throughput.
Se queremos diagnosticar a pilha TCP, precisamos reduzir variáveis.
Um teste utilizando Ethernet ajuda bastante.
Se por cabo o problema desaparece, o Auto-Tuning provavelmente não deve ser nossa primeira suspeita.
Devemos investigar o Wi-Fi.
3. Verifique perda de pacotes
TCP reage à perda.
Quando segmentos não chegam corretamente, o protocolo precisa retransmitir dados e pode reduzir a taxa de envio conforme seus mecanismos de controle de congestionamento.
Isso significa que uma conexão pode apresentar:
boa velocidade nominal
mas desempenho TCP ruim devido a perdas.
Um simples ping não prova sozinho a qualidade completa de uma conexão, mas pode fornecer pistas iniciais.
Também precisamos observar estabilidade, jitter e comportamento sob carga.
Uma pequena perda persistente pode afetar bastante determinadas transferências TCP, especialmente quando existe maior latência.
4. Compare servidores diferentes
Nunca diagnostique velocidade utilizando apenas um download.
O servidor remoto pode ser o gargalo.
Faça comparações.
Se vários serviços rápidos conseguem utilizar a conexão corretamente, mas somente determinado servidor permanece lento, precisamos considerar seriamente uma limitação no destino ou no caminho até ele.
TCP Auto-Tuning não aumenta a capacidade de um servidor remoto.
5. Observe CPU e armazenamento
Imagine receber dados a centenas de megabytes por segundo.
Esses dados precisam ser processados e, em muitos casos, gravados.
Um armazenamento lento, uma CPU sobrecarregada ou outro gargalo interno pode limitar a transferência.
O Gerenciador de Tarefas já fornece uma primeira visão interessante.
Observe simultaneamente:
Rede
CPU
Disco
Se a rede cai enquanto o disco permanece constantemente saturado, talvez estejamos investigando o componente errado.
6. Compare uma transferência local
Existe outro teste extremamente útil.
Faça uma transferência dentro da própria rede entre dois computadores capazes de Gigabit Ethernet.
Se a LAN apresenta throughput muito baixo, mesmo com baixa latência, podemos ter problemas em:
- adaptador;
- driver;
- cabo;
- switch;
- roteador;
- armazenamento;
- protocolo utilizado;
- antivírus;
- sistema operacional.
Isso ajuda a separar um problema da Internet de um problema do próprio computador.
O verdadeiro diagnóstico começa pela comparação
Em redes, números isolados dizem muito pouco.
“Meu download está a 80 Mbps.”
Isso é ruim?
Depende.
Em uma conexão de 100 Mbps, pode ser normal.
Em uma conexão de 1 Gbps, pode indicar gargalo.
Em um servidor que limita cada usuário a 80 Mbps, pode ser exatamente o esperado.
Em Wi-Fi distante do roteador, pode ser até um resultado razoável.
Por isso, precisamos construir uma linha de base.
Compare:
- Speedtest;
- transferência local;
- download de servidor rápido;
- download do servidor problemático;
- teste por cabo;
- teste por Wi-Fi;
- latência;
- perda;
- uso de CPU;
- uso de disco.
Somente depois dessas comparações podemos começar a enxergar o padrão.
E quando o padrão mostra que conexões de maior latência apresentam desempenho TCP anormalmente baixo, enquanto a infraestrutura possui capacidade suficiente, a configuração da pilha TCP passa a merecer atenção.
TCP Auto-Tuning mostra como velocidade de Internet é mais complexa do que parece
O TCP Receive Window Auto-Tuning é um excelente exemplo de algo que funciona silenciosamente durante anos sem que o usuário saiba que existe.
Quando tudo está configurado corretamente, ninguém precisa pensar nele.
O Windows negocia e dimensiona a janela conforme necessário, os algoritmos de congestionamento fazem seu trabalho e as aplicações utilizam a rede normalmente.
O problema começa quando uma configuração inadequada limita esse processo.
Nesse momento surge uma situação curiosa:
o cabo está correto;
o roteador está correto;
a placa é Gigabit;
o Speedtest está rápido;
mas uma transferência TCP continua muito abaixo do esperado.
É justamente nesses casos que um diagnóstico mais profundo diferencia “Internet lenta” de throughput TCP limitado.
E essa diferença muda completamente a maneira de procurar o problema.
Diagnóstico avançado do TCP Auto-Tuning no Windows
Na primeira parte entendemos uma diferença fundamental: ter largura de banda disponível não garante que uma única conexão TCP consiga utilizá-la por completo.
Também vimos que latência, janela de recepção, capacidade do link e comportamento do servidor participam do resultado final.
Agora precisamos transformar esses conceitos em diagnóstico.
O primeiro passo não consiste em modificar configurações.
Consiste em descobrir como o Windows está trabalhando atualmente.
Comece pelo netsh interface tcp show global
Abra o Prompt de Comando como administrador e execute:
netsh interface tcp show global
O Windows exibirá diferentes parâmetros da pilha TCP.
Dependendo da versão e do idioma do sistema, os nomes apresentados podem variar, mas normalmente encontraremos informações relacionadas a:
- Receive-Side Scaling;
- Receive Window Auto-Tuning;
- congestion control;
- ECN;
- timestamps;
- Receive Segment Coalescing;
- outros recursos da pilha TCP.
O erro mais comum consiste em olhar para essa tela procurando simplesmente alguma coisa marcada como disabled.
Disabled não significa necessariamente problema.
Cada recurso possui uma função.
Alguns precisam permanecer habilitados em determinado cenário. Outros podem ficar desabilitados por padrão. Alguns dependem do perfil TCP, do adaptador, do driver e da versão do Windows.
Portanto, precisamos interpretar os parâmetros em vez de transformar todos os valores em enabled.
Receive Window Auto-Tuning Level
Esse é o parâmetro central do nosso artigo.
Em uma configuração normal, podemos encontrar algo equivalente a:
Receive Window Auto-Tuning Level : normal
Isso indica que o Windows possui liberdade para ajustar dinamicamente a janela de recepção TCP.
Quando encontramos:
disabled
a situação merece investigação.
Não significa automaticamente que descobrimos a causa do problema.
Significa que precisamos descobrir por que essa configuração está diferente do padrão esperado.
O computador recebeu algum script de otimização?
Alguém modificou o TCP anteriormente?
Existe uma política administrativa?
Algum software realizou alterações?
A máquina foi migrada de uma instalação antiga do Windows?
Essas perguntas importam porque corrigir uma configuração sem descobrir sua origem pode fazer o problema retornar.
Por que desabilitar o Auto-Tuning pode limitar uma conexão?
Vamos voltar ao exemplo do Bandwidth-Delay Product.
Imagine uma conexão capaz de 1 Gbps com um servidor relativamente distante.
Para manter esse caminho cheio, precisamos ter uma quantidade considerável de dados em trânsito.
Se a janela de recepção fica pequena demais, o transmissor encontra um limite relacionado ao quanto o receptor informa conseguir aceitar.
O resultado pode ser uma transferência que não cresce como deveria.
Agora compare isso com uma rede local.
Dentro da LAN podemos ter:
1 Gbps de largura de banda;
menos de 1 ms de latência.
Nesse cenário, uma janela relativamente pequena representa um problema muito menor porque as confirmações retornam rapidamente.
É por isso que algumas limitações TCP ficam muito mais evidentes quando acessamos servidores distantes.
O computador pode funcionar aparentemente bem na rede local e apresentar desempenho ruim em uma transferência pela Internet.
Receive Window não é Congestion Window
Aqui existe uma confusão muito comum.
TCP possui diferentes mecanismos limitando quanto dado pode permanecer em trânsito.
Dois conceitos importantes são:
Receive Window — rwnd
e
Congestion Window — cwnd
Eles não representam a mesma coisa.
Receive Window
A Receive Window está relacionada ao receptor.
Ela comunica ao transmissor quanto espaço o receptor possui para continuar recebendo dados.
Esse mecanismo faz parte do controle de fluxo.
O objetivo consiste em impedir que o transmissor envie dados mais rapidamente do que o receptor consegue administrar.
Congestion Window
A Congestion Window está relacionada ao controle de congestionamento.
Ela ajuda a determinar quanto dado pode ser colocado na rede sem provocar ou agravar congestionamento.
Enquanto a Receive Window considera a capacidade do receptor, a Congestion Window responde às condições percebidas da rede.
Na prática, a quantidade de dados que pode permanecer em trânsito acaba limitada pelo menor dos limites relevantes.
Portanto, aumentar indiscriminadamente a Receive Window não significa eliminar todas as limitações.
Se o controle de congestionamento reduzir a janela devido às condições da rede, simplesmente possuir uma grande Receive Window não fará a transferência atingir 1 Gbps.
Esse é outro motivo pelo qual não existe um comando universal para “liberar toda a Internet”.
O papel do controle de congestionamento
Imagine uma rede apresentando sinais de congestionamento.
Se o TCP simplesmente continuasse aumentando agressivamente a quantidade de dados transmitidos, a situação poderia piorar.
Por isso existem algoritmos de controle de congestionamento.
Eles ajustam o comportamento do TCP conforme as condições observadas.
Em versões modernas do Windows, você pode encontrar referências ao CUBIC, algoritmo de controle de congestionamento amplamente utilizado em sistemas atuais.
O CUBIC busca utilizar a largura de banda disponível de maneira eficiente, especialmente em redes rápidas e com maior Bandwidth-Delay Product.
Mas precisamos separar novamente os conceitos.
Auto-Tuning da Receive Window não é o algoritmo de controle de congestionamento.
Os dois mecanismos participam da mesma história, mas possuem responsabilidades diferentes.
Essa distinção é essencial durante o diagnóstico.
Como consultar as configurações TCP pelo PowerShell
O netsh continua extremamente útil para uma visualização rápida.
Entretanto, o PowerShell fornece informações adicionais.
Execute:
Get-NetTCPSetting
Você poderá encontrar diferentes perfis TCP.
Entre eles podem aparecer nomes como:
Internet
InternetCustom
Datacenter
DatacenterCustom
Compat
A presença desses perfis não significa que todos estejam sendo utilizados simultaneamente da mesma maneira.
Eles representam conjuntos de configurações que o Windows pode aplicar em diferentes contextos.
Para visualizar algumas propriedades de forma mais organizada:
Get-NetTCPSetting | Select-Object SettingName, AutoTuningLevelLocal, ScalingHeuristics, CongestionProvider
Dependendo da versão do Windows, algumas propriedades ou valores apresentados podem variar.
O objetivo não consiste em decorar todos os campos.
Queremos identificar configurações anormais e comparar o computador problemático com uma referência conhecida.
Uma técnica excelente: compare com outro computador
Essa estratégia economiza muito tempo em suporte técnico.
Imagine:
Computador A
Windows 11 atualizado;
mesmo roteador;
mesmo cabo;
mesma Internet;
download normal.
Computador B
Windows 11;
mesmo roteador;
mesmo servidor;
download extremamente lento.
Nesse cenário, temos uma oportunidade excelente.
Podemos comparar:
netsh interface tcp show global
nos dois computadores.
Também podemos comparar:
Get-NetTCPSetting
Isso não significa copiar cegamente todas as configurações do computador A para o B.
Mas diferenças importantes podem revelar pistas.
Se o computador A apresenta Auto-Tuning normal e o computador B apresenta disabled, encontramos algo que merece investigação.
Se ambos apresentam configurações semelhantes, provavelmente precisamos continuar procurando.
Diagnóstico funciona por eliminação.
Receive-Side Scaling: RSS
Outro recurso que pode aparecer no diagnóstico é o Receive-Side Scaling, conhecido como RSS.
Em computadores modernos, uma interface de rede pode receber uma enorme quantidade de pacotes por segundo.
Processar todo esse tráfego utilizando apenas um único processador lógico pode criar um gargalo.
RSS permite distribuir o processamento de rede recebido entre diferentes processadores.
Isso pode melhorar a escalabilidade em cenários de alto throughput.
Podemos verificar informações relacionadas ao RSS utilizando PowerShell.
Por exemplo:
Get-NetAdapterRss
Esse comando permite observar o suporte e a configuração do recurso nos adaptadores compatíveis.
Também podemos verificar:
Get-NetAdapter
para identificar corretamente o adaptador antes de aprofundar o diagnóstico.
RSS aumenta a velocidade da Internet?
Não devemos pensar dessa maneira.
RSS não transforma uma conexão de 500 Mbps em 1 Gbps.
Ele ajuda o computador a processar eficientemente o tráfego quando a carga de rede poderia criar um gargalo de CPU.
Em um computador moderno navegando normalmente na Internet, talvez você nunca perceba diferença.
Em transferências muito rápidas, servidores, máquinas com alta carga ou determinados adaptadores, o impacto pode ficar mais evidente.
A pergunta correta não é:
“RSS deixa a Internet mais rápida?”
A pergunta correta é:
“o processamento de pacotes está limitando o throughput que a interface poderia entregar?”
Essa mudança de pergunta representa exatamente o tipo de raciocínio necessário para diagnosticar redes corretamente.
Como perceber um possível gargalo de CPU relacionado à rede
Abra o Gerenciador de Tarefas durante uma transferência pesada.
Não observe apenas o uso total da CPU.
Um processador com oito ou dezesseis threads pode mostrar utilização total relativamente baixa enquanto um único processador lógico trabalha próximo do limite.
Por isso, dependendo do caso, vale visualizar os processadores lógicos separadamente.
Se durante uma transferência rápida um núcleo fica constantemente saturado enquanto o restante permanece com utilização baixa, podemos ter uma pista.
Isso não prova que RSS seja o culpado.
Pode existir:
- driver problemático;
- software de segurança;
- filtro de rede;
- VPN;
- processamento da aplicação;
- interrupções;
- outro componente consumindo aquele núcleo.
Mais uma vez, precisamos correlacionar informações.
O que é Receive Segment Coalescing?
Outro nome que aparece em discussões sobre desempenho TCP é Receive Segment Coalescing, ou RSC.
O objetivo geral do RSC consiste em reduzir o custo de processamento de determinados pacotes recebidos.
Em vez de entregar uma grande quantidade de pequenos segmentos individualmente para processamento nas camadas superiores, o sistema pode combinar segmentos de maneira apropriada.
Isso reduz overhead.
Em conexões de alta velocidade, reduzir trabalho por pacote pode melhorar a eficiência do sistema.
No PowerShell, podemos consultar informações com:
Get-NetAdapterRsc
Dependendo do adaptador e do driver, encontraremos suporte e estado para IPv4 e IPv6.
Novamente:
RSC não deve ser habilitado ou desabilitado aleatoriamente.
Existem situações específicas envolvendo virtualização, drivers, filtros ou troubleshooting nas quais um técnico pode testar alterações.
Mas isso precisa acontecer como experimento controlado, não como “otimização padrão”.
Offloads: por que a placa de rede faz parte do processamento?
Placas de rede modernas não servem apenas para transportar bits.
Muitas conseguem realizar parte do processamento que, de outra forma, ficaria sob responsabilidade direta da CPU.
Esses recursos recebem genericamente o nome de offloads.
Dependendo do hardware e do driver, podemos encontrar recursos relacionados a:
- checksum;
- segmentação;
- coalescência;
- RSS;
- VLAN;
- buffers;
- moderação de interrupções.
O objetivo costuma ser aumentar eficiência.
Entretanto, drivers problemáticos também podem provocar comportamentos inesperados.
Por isso, quando uma única máquina apresenta desempenho muito diferente de outras na mesma rede, o driver da placa merece atenção.
Driver de rede não é detalhe
Existe uma prática comum depois de instalar o Windows:
se a Internet funciona, ninguém mexe no driver.
Para uso básico, isso muitas vezes funciona.
O Windows Update consegue fornecer drivers adequados para enorme quantidade de dispositivos.
Mas durante um diagnóstico avançado de desempenho, precisamos pelo menos identificar:
- fabricante da placa;
- modelo;
- versão do driver;
- data do driver;
- configurações avançadas disponíveis.
Abra o Gerenciador de Dispositivos.
Entre em:
Adaptadores de rede → adaptador utilizado → Propriedades
Verifique a guia de driver.
Depois observe as propriedades avançadas.
Dependendo do fabricante, podem aparecer opções como:
- Speed & Duplex;
- Receive Buffers;
- Transmit Buffers;
- Interrupt Moderation;
- Large Send Offload;
- Receive Side Scaling;
- Energy Efficient Ethernet;
- Flow Control.
Não modifique tudo.
Primeiro registre a configuração original.
O perigo de alterar dez configurações ao mesmo tempo
Imagine que você desabilite:
RSS;
RSC;
Large Send Offload;
Interrupt Moderation;
Energy Efficient Ethernet;
Flow Control;
IPv6;
Auto-Tuning.
Depois reinicia o computador.
O download melhora.
Qual alteração resolveu?
Você não sabe.
Talvez nenhuma delas tenha resolvido diretamente.
A reinicialização pode ter encerrado um processo problemático.
Um driver pode ter sido recarregado.
A rota pode ter mudado.
O servidor pode simplesmente estar menos congestionado.
Esse tipo de procedimento produz uma falsa sensação de diagnóstico.
O método correto consiste em:
medir → alterar uma variável → repetir o mesmo teste → comparar → documentar.
Crie um teste reproduzível
Se queremos descobrir se uma alteração TCP realmente mudou o desempenho, precisamos utilizar condições comparáveis.
Não adianta testar um servidor pela manhã e outro servidor à noite.
Escolha um cenário reproduzível.
Por exemplo:
- computador conectado por Ethernet;
- mesmo cabo;
- mesma porta do roteador;
- mesmo servidor;
- mesma aplicação;
- mesmo arquivo;
- nenhum download concorrente;
- registrar velocidade média;
- repetir o teste algumas vezes.
Agora temos uma referência.
Suponha:
Teste 1: 92 Mbps
Teste 2: 95 Mbps
Teste 3: 91 Mbps
Média aproximada:
93 Mbps.
Depois realizamos uma única alteração tecnicamente justificada e repetimos.
Teste 1: 430 Mbps
Teste 2: 447 Mbps
Teste 3: 438 Mbps
Agora existe uma diferença grande e consistente.
Isso merece investigação.
Se o resultado mudar de 93 para 97 Mbps, talvez estejamos simplesmente observando variação normal.
Latência muda completamente o teste
Existe ainda outro detalhe importante.
Uma limitação de janela TCP pode ficar pouco evidente contra um servidor próximo e muito evidente contra um servidor distante.
Portanto, durante um diagnóstico específico de janela TCP, comparar destinos com diferentes RTTs pode ser útil.
Imagine:
Servidor A: 5 ms
Servidor B: 40 ms
Servidor C: 100 ms
Se o throughput cai de maneira anormal conforme o RTT aumenta, apesar de os servidores possuírem capacidade suficiente, temos uma pista interessante.
Mas atenção:
servidores diferentes também possuem capacidades, rotas e políticas diferentes.
Portanto, essa comparação sozinha não prova nada.
Precisamos juntar várias evidências.
RTT: o número que precisamos observar
RTT significa Round-Trip Time.
É o tempo aproximado necessário para um pacote chegar ao destino e a resposta retornar.
O ping fornece uma maneira simples de estimar esse tempo quando o destino responde a ICMP.
Por exemplo:
ping servidor
Podemos encontrar algo como:
tempo=4ms
ou:
tempo=80ms
Esses valores ajudam a entender a distância lógica da comunicação.
Mas existe uma ressalva importante:
ping baixo não garante throughput alto.
E ping alto não significa necessariamente conexão ruim.
Um servidor fisicamente distante pode naturalmente apresentar RTT maior.
A questão consiste em saber se o comportamento observado faz sentido para aquele caminho.
Perda de pacotes pode destruir throughput TCP
Agora imagine que o RTT esteja aceitável, mas alguns segmentos se percam.
TCP precisa reagir.
Dependendo das circunstâncias, isso pode envolver retransmissão e redução da taxa de envio.
Em conexões rápidas e de maior latência, perdas podem causar impacto significativo.
Por isso, uma transferência TCP lenta pode ser consequência de:
perda
e não de:
janela pequena.
Essa distinção é fundamental.
Se alterarmos o Auto-Tuning enquanto existe perda física ou congestionamento, estamos tentando resolver o sintoma no lugar errado.
Onde procurar perda?
Comece separando os segmentos da rede.
Primeiro teste o gateway local.
Depois um destino externo estável.
Compare cabo e Wi-Fi.
Se existe perda até o próprio roteador quando usamos Wi-Fi, não faz sentido começar investigando o servidor remoto.
Se o gateway permanece perfeito, mas determinados caminhos externos apresentam problemas, ampliamos a investigação.
Também precisamos lembrar que ICMP pode receber tratamento diferente em algumas redes.
Portanto, ping serve como ferramenta de diagnóstico, não como prova absoluta.
O antivírus também participa da pilha de rede
Softwares de segurança modernos podem instalar filtros de rede.
Firewalls, antivírus, VPNs e soluções corporativas podem inspecionar ou modificar o caminho dos dados dentro do sistema.
Isso significa que dois computadores aparentemente idênticos podem apresentar throughput diferente simplesmente porque um possui software adicional atuando sobre o tráfego.
Alguns exemplos de componentes que merecem investigação:
- VPN;
- firewall de terceiros;
- antivírus;
- filtro web;
- software de controle parental;
- agente corporativo;
- software de captura;
- virtualização.
Não significa que devemos desinstalar a segurança do computador como primeiro teste.
Significa apenas que precisamos conhecer a cadeia completa.
VPN muda completamente o cenário
Se uma VPN estiver ativa, o tráfego pode seguir outro caminho.
Além disso, entram em cena:
- criptografia;
- encapsulamento;
- servidor VPN;
- capacidade do provedor;
- protocolo utilizado;
- MTU;
- processamento da CPU.
Se a velocidade fica baixa somente com VPN ativada, investigar imediatamente o TCP Auto-Tuning global do Windows provavelmente não representa o melhor ponto de partida.
Teste primeiro sem a VPN, quando isso puder ser feito de forma segura e autorizada.
MTU também pode confundir o diagnóstico
MTU significa Maximum Transmission Unit.
Ela determina o tamanho máximo de pacote que determinada interface consegue transportar sem fragmentação naquele enlace.
Problemas de MTU podem provocar sintomas curiosos.
Alguns sites funcionam.
Outros apresentam lentidão.
VPN funciona parcialmente.
Determinadas conexões travam.
Downloads começam e param.
Entretanto, não devemos cair em outra armadilha:
mudar MTU aleatoriamente também não representa diagnóstico.
Primeiro precisamos ter evidências de que o tamanho dos pacotes participa do problema.
IPv4 e IPv6 também precisam entrar na comparação
Hoje muitos computadores utilizam simultaneamente IPv4 e IPv6.
Uma aplicação pode preferir IPv6 quando existe conectividade disponível.
Isso significa que dois testes aparentemente iguais podem utilizar caminhos diferentes.
Durante um diagnóstico avançado, vale identificar qual protocolo está realmente transportando a comunicação problemática.
Mais uma vez, isso não significa desativar IPv6.
Desabilitar IPv6 como “otimização” pode simplesmente mascarar um problema que deveria ser corrigido.
Como saber se realmente vale investigar Auto-Tuning?
O cenário começa a ficar interessante quando encontramos uma combinação semelhante a esta:
- link físico correto;
- Ethernet ou Wi-Fi funcionando adequadamente;
- servidor comprovadamente rápido;
- armazenamento sem saturação;
- CPU sem gargalo evidente;
- ausência de perda significativa;
- outro computador na mesma rede apresenta desempenho normal;
- computador problemático apresenta throughput TCP muito inferior;
- configuração TCP mostra Auto-Tuning desabilitado ou anormalmente restrito;
- problema aparece principalmente em conexões com maior RTT.
Agora temos um conjunto coerente de evidências.
Não apenas um comando encontrado na Internet.
E se o Auto-Tuning já estiver em Normal?
Então não existe motivo para “colocar mais”.
Não devemos mudar para experimental simplesmente porque parece uma opção superior.
normal não significa desempenho reduzido.
É o comportamento padrão criado para atender a uma enorme variedade de redes.
Se o Auto-Tuning já está normal e o throughput continua ruim, continue o diagnóstico.
Investigue:
- perda;
- servidor;
- Wi-Fi;
- cabo;
- driver;
- CPU;
- disco;
- VPN;
- antivírus;
- filtros;
- adaptador;
- rota;
- MTU;
- aplicação.
Essa lista parece grande porque Internet lenta não é um diagnóstico.
É apenas um sintoma.
O melhor comando é aquele que confirma uma hipótese
Esse princípio vale para praticamente todo suporte técnico.
Não execute um comando porque ele aparece em uma lista de “comandos úteis”.
Pergunte:
o que estou tentando provar?
Se queremos saber o estado do Auto-Tuning:
netsh interface tcp show global
Se queremos analisar perfis TCP:
Get-NetTCPSetting
Se queremos observar RSS:
Get-NetAdapterRss
Se queremos consultar RSC:
Get-NetAdapterRsc
Se queremos conhecer o adaptador:
Get-NetAdapter
Cada ferramenta responde uma pergunta diferente.
É assim que construímos um diagnóstico.
O TCP Auto-Tuning não é um botão de turbo
Depois de entender Receive Window, Congestion Window, RSS, RSC, offloads e RTT, fica mais fácil perceber por que tantos tutoriais de “otimização de Internet” falham.
Eles tentam transformar um sistema dinâmico e complexo em uma sequência fixa de comandos.
Mas redes não funcionam assim.
Um computador pode precisar de diagnóstico porque o Auto-Tuning foi desabilitado.
Outro pode apresentar perda de pacotes.
Outro pode estar negociando Ethernet a 100 Mbps.
Outro possui driver problemático.
Outro sofre com uma VPN lenta.
Outro tenta baixar de um servidor que simplesmente limita cada conexão.
O sintoma é o mesmo:
“Internet lenta.”
As causas são completamente diferentes.
Por isso, antes de alterar qualquer configuração avançada do TCP, precisamos medir e comparar.
Essa metodologia não produz um “comando mágico”.
Produz algo muito mais útil:
uma explicação técnica para o problema.
Como diagnosticar TCP Auto-Tuning na prática
Até aqui já entendemos a teoria.
Agora vamos transformar tudo isso em um procedimento real de diagnóstico.
O cenário será este:
o computador apresenta boa velocidade no Speedtest, mas determinados downloads ou transferências TCP continuam muito abaixo do esperado.
A pior abordagem seria começar executando comandos aleatórios.
A melhor abordagem consiste em seguir uma sequência lógica.
Etapa 1 — Confirme a velocidade física da conexão
Antes de investigar TCP, descubra quanto a interface de rede realmente negociou.
No Windows, abra:
Configurações → Rede e Internet → Ethernet
ou consulte o adaptador pelo PowerShell:
Get-NetAdapter
Observe o campo relacionado à velocidade do link.
Se o computador utiliza Ethernet Gigabit, o esperado normalmente será algo como:
1 Gbps
Se aparecer:
100 Mbps
já encontramos um gargalo importante.
Nesse caso, investigue primeiro:
- cabo de rede;
- conector;
- porta do roteador;
- switch;
- placa de rede;
- configuração Speed & Duplex.
Não existe ajuste de TCP capaz de fazer uma interface negociada a 100 Mbps entregar 900 Mbps.
Etapa 2 — Compare cabo e Wi-Fi
Se o computador estiver conectado por Wi-Fi, sempre que possível faça também um teste temporário por cabo.
Isso ajuda a separar:
problema de rede sem fio
de
problema de TCP ou do próprio Windows.
Se por cabo o desempenho sobe imediatamente, concentre o diagnóstico em:
- sinal;
- interferência;
- largura de canal;
- distância;
- congestionamento;
- padrão Wi-Fi;
- posicionamento do roteador;
- rede Mesh.
Se por cabo e Wi-Fi o comportamento permanece praticamente igual, a investigação pode continuar em outra camada.
Etapa 3 — Faça mais de um teste de velocidade
Evite concluir qualquer coisa com base em apenas um servidor.
Execute testes diferentes.
Compare:
- servidor automático;
- servidor próximo;
- servidor de outra operadora;
- download real;
- transferência em aplicação.
Um teste isolado pode ser influenciado por rota, congestionamento ou capacidade do destino.
O importante é observar o padrão.
Se todos os testes ficam ruins, o problema pode estar mais próximo.
Se apenas uma origem fica lenta, o servidor remoto merece atenção.
Etapa 4 — Teste um download de arquivo grande
O Speedtest é útil, mas um arquivo grande ajuda a visualizar o comportamento da transferência ao longo do tempo.
Observe se a velocidade:
- sobe e permanece estável;
- sobe e cai;
- oscila excessivamente;
- trava em um valor específico;
- cresce lentamente.
Esse comportamento pode fornecer pistas.
Por exemplo, uma transferência que permanece muito estável em um valor bastante abaixo da capacidade disponível pode indicar algum tipo de limitação.
Mas não tente adivinhar a causa apenas pelo formato do gráfico.
Use essa informação em conjunto com as próximas etapas.
Etapa 5 — Observe CPU, memória e disco
Abra o Gerenciador de Tarefas.
Durante a transferência, acompanhe:
- CPU;
- disco;
- memória;
- rede.
Se o disco chega continuamente a 100% e a rede cai, talvez o armazenamento esteja impedindo o computador de absorver os dados.
Se um núcleo da CPU fica constantemente saturado, investigue processamento de rede, aplicação, antivírus ou driver.
Se nenhum recurso local está próximo do limite, podemos continuar.
Etapa 6 — Teste o gateway local
Execute:
ping IP_DO_ROTEADOR -n 50
Por exemplo:
ping 192.168.1.1 -n 50
ou:
ping 192.168.0.1 -n 50
O objetivo consiste em verificar a comunicação entre o computador e o roteador.
Em uma conexão Ethernet saudável, normalmente esperamos:
- latência muito baixa;
- estabilidade;
- ausência de perda.
Se existir perda até o próprio roteador, não faz sentido começar investigando um servidor distante.
Precisamos corrigir primeiro a rede local.
Etapa 7 — Teste um destino externo
Depois faça:
ping 1.1.1.1 -n 50
ou outro destino confiável.
Compare:
gateway local
com
destino externo.
Se o gateway está perfeito, mas o destino externo apresenta perda ou instabilidade, o problema provavelmente está além da LAN.
Pode envolver:
- operadora;
- rota;
- congestionamento;
- conexão WAN;
- modem ou ONT.
Etapa 8 — Verifique o TCP Auto-Tuning
Agora sim chegamos ao ponto central.
Abra o Prompt de Comando como administrador e execute:
netsh interface tcp show global
Procure pelo campo relacionado ao:
Receive Window Auto-Tuning Level
Se estiver:
normal
o Auto-Tuning provavelmente está no comportamento padrão.
Se estiver:
disabled
ou em outro nível inesperado, registre a informação.
Não altere ainda.
Primeiro investigue o histórico.
Etapa 9 — Descubra se algum software mexeu na pilha TCP
Pergunte:
O computador já recebeu algum “otimizador”?
Alguém executou scripts de Internet?
Existem programas como:
- TCP optimizer;
- booster;
- game booster;
- registry cleaner;
- ferramenta de tuning;
- pacote de “melhoria de ping”?
Esse tipo de software pode alterar configurações sem deixar claro o que modificou.
Também verifique histórico de tutoriais ou comandos aplicados anteriormente.
Esse contexto é extremamente importante.
Etapa 10 — Compare com outro computador
Se possível, use outro computador na mesma rede.
Execute nele:
netsh interface tcp show global
e compare.
Também execute:
Get-NetTCPSetting
Se o segundo computador apresenta desempenho correto e valores diferentes no TCP Auto-Tuning, isso cria uma hipótese mais forte.
Novamente:
não copie tudo.
Compare.
Exemplo prático 1 — Auto-Tuning desabilitado
Imagine o seguinte cenário.
Internet contratada:
600 Mbps
Speedtest:
570 Mbps
Download de servidor distante:
70 Mbps
Outro computador na mesma rede:
420 Mbps
No computador lento:
Receive Window Auto-Tuning Level : disabled
No computador normal:
Receive Window Auto-Tuning Level : normal
Nesse ponto, temos uma diferença relevante.
Se todas as outras variáveis já foram verificadas, faz sentido testar a restauração do comportamento padrão.
Execute como administrador:
netsh int tcp set global autotuninglevel=normal
Depois confirme:
netsh int tcp show global
Reinicie o teste sob as mesmas condições.
Se a velocidade subir de maneira consistente, encontramos forte evidência de que a configuração anterior estava limitando o throughput.
Exemplo prático 2 — Auto-Tuning normal, mas download lento
Agora imagine:
Internet:
1 Gbps
Auto-Tuning:
normal
Speedtest:
930 Mbps
Download específico:
45 Mbps
Outro servidor:
780 Mbps
Nesse caso, mudar Auto-Tuning provavelmente não faz sentido.
O computador já consegue provar que entrega alto throughput.
O gargalo está mais provavelmente em:
- servidor remoto;
- rota até aquele servidor;
- limitação por sessão;
- horário;
- CDN;
- congestionamento intermediário.
Esse é um exemplo excelente de por que não devemos transformar TCP Auto-Tuning em culpado universal.
Exemplo prático 3 — Problema era Ethernet a 100 Mbps
Internet:
500 Mbps
Speedtest:
94 Mbps
Download:
92 Mbps
Velocidade do adaptador:
100 Mbps
Aqui não existe mistério.
A interface física está limitando a conexão.
Trocar cabo ou porta pode resolver.
Mexer no TCP Auto-Tuning apenas desviaria o diagnóstico.
Exemplo prático 4 — Wi-Fi era o gargalo
Internet:
700 Mbps
Wi-Fi:
110 Mbps
Cabo:
650 Mbps
Auto-Tuning:
normal
Neste caso, o problema está claramente relacionado ao Wi-Fi.
Talvez o computador esteja conectado em 2,4 GHz.
Talvez exista interferência.
Talvez o sinal esteja fraco.
Talvez a largura de canal esteja limitada.
Mais uma vez, TCP não é o primeiro suspeito.
Quando vale restaurar o Auto-Tuning para Normal
A restauração faz sentido quando:
- o valor está diferente do padrão;
- não existe justificativa conhecida para isso;
- o computador apresenta problema de throughput;
- outras causas básicas já foram eliminadas;
- existe evidência comparativa.
O comando é:
netsh int tcp set global autotuninglevel=normal
Depois confirme:
netsh int tcp show global
O ideal é repetir os testes sob as mesmas condições.
Quando NÃO mudar o Auto-Tuning
Não mude apenas porque:
- o Speedtest ficou abaixo do contratado uma vez;
- um download ficou lento;
- o ping aumentou;
- um vídeo no YouTube recomendou;
- alguém disse que
disabledreduz lag; - um fórum publicou uma lista de comandos.
Alterações sem hipótese clara dificultam o diagnóstico.
Experimental não significa melhor
Um dos erros mais comuns consiste em pensar:
experimental = desempenho máximo
Não funciona assim.
O modo Experimental existe para cenários específicos.
Ele não representa uma configuração universal para usuários domésticos.
O nível normal foi projetado justamente para adaptar o comportamento de maneira dinâmica em cenários convencionais.
Desabilitar IPv6 não é solução para Internet lenta
Outro conselho muito comum na Internet consiste em:
“Desative IPv6 para melhorar a velocidade.”
Isso também merece cuidado.
IPv6 faz parte da arquitetura moderna da Internet.
Se existe um problema específico de rota ou implementação, desativar IPv6 pode até alterar o comportamento temporariamente.
Mas isso não significa que IPv6 seja a causa genérica de Internet lenta.
O correto é identificar se a aplicação está usando IPv4 ou IPv6 e comparar.
Reset de rede: use somente quando fizer sentido
O Windows possui recursos para redefinir componentes de rede.
Também existem comandos como:
netsh winsock reset
e procedimentos de reset da pilha.
Essas ferramentas podem ser úteis em casos específicos de corrupção ou filtros problemáticos.
Mas não deveriam representar o primeiro passo de qualquer diagnóstico.
Um reset pode remover pistas importantes sobre o estado original do sistema.
Sempre registre antes:
- configurações;
- adaptadores;
- IP;
- DNS;
- VPN;
- filtros.
Antivírus e firewall podem reduzir throughput?
Podem.
Isso depende do software, do tipo de inspeção e da carga.
Um antivírus que examina tráfego web, arquivos baixados ou conexões criptografadas pode adicionar processamento.
Firewalls de terceiros também podem instalar filtros.
A melhor forma de investigar consiste em comparar comportamentos de forma controlada e segura.
Nunca desative proteção aleatoriamente em um computador conectado à Internet.
VPN e throughput TCP
VPNs adicionam outra camada.
A velocidade final pode depender de:
- servidor escolhido;
- capacidade do provedor;
- criptografia;
- CPU;
- protocolo;
- rota;
- MTU;
- congestionamento.
Se a conexão fica lenta somente com VPN, investigue a VPN primeiro.
Não modifique a pilha TCP global sem necessidade.
Como calcular uma limitação teórica por janela
Podemos usar uma fórmula simplificada:
Throughput máximo aproximado = janela / RTT
Imagine uma janela efetiva de:
64 KB
e RTT de:
100 ms
Temos aproximadamente:
64 KB / 0,1 s = 640 KB/s
Convertendo aproximadamente:
640 KB/s × 8 = 5,1 Mbps.
Isso mostra como uma janela pequena pode limitar drasticamente uma sessão TCP em uma conexão de maior latência.
Agora imagine uma janela muito maior.
Com Auto-Tuning funcionando corretamente, o Windows pode aumentar a janela conforme a necessidade.
É exatamente isso que ajuda a aproveitar conexões rápidas.
Bandwidth-Delay Product em um exemplo de 1 Gbps
Vamos novamente considerar:
1 Gbps
e
100 ms de RTT
1 Gbps equivale a aproximadamente:
125 MB/s
Multiplicando por:
0,1 segundo
temos:
12,5 MB
Ou seja, para manter o caminho completamente ocupado, podemos precisar de muitos megabytes de dados em trânsito.
Isso ajuda a entender por que mecanismos modernos de Window Scaling e Auto-Tuning se tornaram tão importantes.
Por que conexões antigas pareciam não precisar disso?
Porque as velocidades eram muito menores.
Em uma conexão de 1 Mbps, uma pequena janela conseguia acompanhar muitos cenários.
Em uma rede Gigabit, a diferença é enorme.
A evolução das velocidades tornou necessário ampliar a capacidade do TCP de manter dados em trânsito.
Um detalhe importante: múltiplas conexões mascaram problemas
Alguns testes de velocidade utilizam várias conexões simultâneas.
Isso pode fazer o resultado agregado parecer excelente mesmo quando uma única sessão TCP apresenta desempenho pior.
Por isso, um teste multi-thread e um download single-thread podem fornecer resultados muito diferentes.
Esse comportamento não significa necessariamente defeito.
Mas pode ajudar a revelar limitações.
Como montar uma tabela de diagnóstico
Uma forma profissional de trabalhar consiste em registrar resultados.
Exemplo:
| Teste | Resultado |
|---|---|
| Velocidade contratada | 600 Mbps |
| Ethernet negociada | 1 Gbps |
| Speedtest | 570 Mbps |
| Download servidor A | 82 Mbps |
| Download servidor B | 410 Mbps |
| Ping gateway | 1 ms |
| Ping externo | 22 ms |
| Perda local | 0% |
| Auto-Tuning | Normal |
| CPU | 35% |
| Disco | 40% |
Essa tabela já mostra algo importante.
Se outro servidor entrega 410 Mbps, dificilmente o Auto-Tuning global representa o principal gargalo.
Agora outro exemplo:
| Teste | Resultado |
| Velocidade contratada | 600 Mbps |
| Ethernet negociada | 1 Gbps |
| Speedtest | 550 Mbps |
| Download servidor A | 75 Mbps |
| Download servidor B | 90 Mbps |
| Ping gateway | 1 ms |
| Ping externo | 45 ms |
| Perda | 0% |
| Auto-Tuning | Disabled |
| CPU | 20% |
| Disco | 25% |
Aqui temos uma hipótese bem mais interessante.
O valor de alterar apenas uma variável por vez
Depois de registrar a linha de base, altere apenas uma coisa.
Exemplo:
Antes:
Auto-Tuning = disabled
Média:
86 Mbps
Depois:
Auto-Tuning = normal
Média:
380 Mbps
Essa diferença consistente possui valor diagnóstico.
Agora imagine modificar oito configurações ao mesmo tempo e a velocidade subir.
Você não saberá qual delas realmente fez diferença.
Checklist profissional de diagnóstico
Quando um cliente disser:
“Minha Internet é rápida, mas o download está lento.”
Siga esta sequência:
- confirme a velocidade contratada;
- confirme a velocidade negociada;
- teste por Ethernet;
- faça vários testes;
- compare servidores;
- monitore CPU e disco;
- teste gateway;
- teste destino externo;
- verifique perda;
- confira drivers;
- identifique VPN e filtros;
- consulte Auto-Tuning;
- compare com outro computador;
- altere apenas uma variável;
- repita os testes.
Esse método economiza tempo porque elimina suposições.
Erros comuns ao tentar acelerar a Internet
Erro 1 — Desligar Auto-Tuning
Fazer isso sem diagnóstico pode piorar throughput.
Erro 2 — Desativar IPv6
Pode apenas esconder o problema.
Erro 3 — Trocar MTU sem testar
MTU incorreta pode criar novos problemas.
Erro 4 — Mexer em Speed & Duplex manualmente
Forçar configurações sem necessidade pode causar incompatibilidade.
Normalmente a autonegociação funciona melhor em redes atuais.
Erro 5 — Instalar programas de “Internet Booster”
Muitos apenas aplicam mudanças genéricas no registro ou no TCP.
Erro 6 — Medir somente Speedtest
Speedtest não representa todos os cenários.
Erro 7 — Culpar a operadora imediatamente
O problema pode estar no computador.
Erro 8 — Culpar o Windows imediatamente
O servidor remoto também pode ser o gargalo.
O que o TCP Auto-Tuning realmente faz
Depois de toda essa análise, podemos resumir de maneira simples.
TCP Auto-Tuning não:
- aumenta o plano contratado;
- cria banda;
- reduz fisicamente a latência;
- transforma Wi-Fi ruim em Wi-Fi bom;
- corrige cabo defeituoso;
- acelera servidor lento.
Ele ajuda o Windows a dimensionar dinamicamente a janela de recepção para aproveitar melhor a conexão TCP.
É uma peça importante.
Mas continua sendo apenas uma peça.
FAQ — TCP Auto-Tuning no Windows
TCP Auto-Tuning deixa a Internet mais rápida?
Não no sentido de ultrapassar a velocidade contratada.
Ele ajuda o Windows a utilizar melhor a capacidade disponível em determinadas conexões TCP.
Vale a pena colocar Auto-Tuning em Experimental?
Para uso comum, não.
normal é a configuração padrão mais adequada para a maioria dos usuários.
Desabilitar Auto-Tuning diminui ping?
Normalmente não.
Ping depende de latência do caminho, congestionamento, processamento e vários outros fatores.
Posso usar netsh int tcp set global autotuninglevel=normal?
Sim, esse comando restaura o nível Normal.
Mas o ideal é primeiro verificar o estado atual e entender por que ele foi alterado.
TCP Auto-Tuning interfere no Wi-Fi?
O recurso atua no TCP, independentemente de a conexão utilizar Ethernet ou Wi-Fi.
Porém, um Wi-Fi ruim pode virar gargalo antes que o Auto-Tuning faça diferença.
Speedtest rápido prova que o TCP está perfeito?
Não necessariamente.
Testes podem utilizar múltiplas conexões e servidores específicos.
Uma transferência individual pode se comportar de maneira diferente.
RSC e RSS devem ficar habilitados?
Depende do adaptador, driver e cenário.
Normalmente eles fazem parte dos mecanismos modernos de eficiência de rede.
Não os modifique sem motivo técnico.
Devo atualizar o driver da placa de rede?
Se existe um problema de desempenho, vale verificar se existe driver apropriado e atualizado.
Principalmente quando apenas um computador da rede apresenta comportamento anormal.
Antivírus pode reduzir velocidade?
Pode, especialmente se realizar inspeção avançada.
Mas isso precisa ser comprovado por testes.
VPN pode limitar a velocidade?
Sim.
VPN depende de servidor, rota, protocolo, criptografia e processamento.
Auto-Tuning funciona no Windows 11?
Sim.
O Windows moderno utiliza recursos de ajuste dinâmico da janela TCP.
É possível voltar para a configuração original?
Normalmente sim.
Por isso é importante registrar os valores antes de qualquer modificação.
Conclusão
Quando a Internet parece rápida em alguns testes e lenta em outros, a resposta raramente aparece em um único número.
Precisamos analisar o caminho completo.
Cabo.
Wi-Fi.
Roteador.
Operadora.
Latência.
Perda.
Servidor.
CPU.
Disco.
Driver.
Aplicação.
TCP.
O TCP Receive Window Auto-Tuning entra justamente nessa última camada.
Ele permite que o Windows adapte a janela de recepção para aproveitar melhor conexões modernas, principalmente quando existe uma combinação de alta largura de banda e maior latência.
Quando funciona corretamente, o usuário praticamente nunca percebe sua existência.
Quando foi desabilitado ou alterado de maneira inadequada, pode contribuir para limitações de throughput.
O principal ensinamento, porém, não está em um comando.
Está na metodologia.
Não devemos procurar “o comando que acelera a Internet”.
Devemos procurar o gargalo real.
Essa diferença transforma tentativa e erro em diagnóstico técnico.
Precisa descobrir por que sua Internet está lenta?
A VMIA realiza diagnóstico de computadores, redes domésticas, Wi-Fi, roteadores, impressoras e problemas de desempenho do Windows.
Se o Speedtest parece normal, mas downloads, chamadas, transferências ou aplicações continuam lentos, podemos avaliar onde está o gargalo antes de modificar configurações desnecessárias.
Atendimento com agendamento, presencial ou por acesso remoto, conforme o tipo de problema.
VMIA — Manutenção e Configuração
WhatsApp: (11) 99779-7772
Site: https://vmia.site
Blog: https://vmia.com.br
Avaliações: https://avaliacao.vmia.com.br
Atendimento em São Paulo e suporte remoto para problemas compatíveis com acesso à distância.
Faça um comentário