Ir para o conteúdo
M4NET-20261010-047dc971
Laudo .txt JSON
PT-BRPortuguês do Brasil Español de América Latina
IPv4 verificando…
IPv6 verificando…

Transporte

Endereços

MTU do caminho Problema

Maior pacote que atravessa o caminho sem ser fragmentado. Inferido do MSS que o seu equipamento anunciou no handshake TCP.

1500 · você
ruimaceitávelideal
12801500
Referências: 1492 PPPoE · 1420 WireGuard · 1500 Ethernet limpo
MTU do cliente
1500
MSS anunciado
1460
MSS efetivo
1448
MTU do servidor
1500
Seu equipamento
1460
Caminho
1500
Nosso servidor
1448
O limite veio do nosso servidor: a MTU do seu lado pode ser maior.

Medição limitada pelo servidor: a MTU do seu lado é de no mínimo 1500 bytes, podendo ser maior.

Opções TCP negociadas

O que os dois lados combinaram durante o handshake.

TimestampsSACKWindow scalingECN
Escala da janela · cliente2^7
Escala da janela · servidor2^7
RWIN máximo do cliente8388480 B

Desempenho

Latência, perda e janela medidas pelo kernel.

Latência (RTT)153.27 ms
Variação (jitter)±34.14 ms
Retransmissões1
Janela de congestionamento10
MSS de recepção536 (não medido)
Path MTU (kernel)1500

Latência sob carga (bufferbloat) Não medido

Por que internet rápida ainda parece lenta: bufferbloat é o atraso extra que aparece quando os dados ficam numa fila de espera porque a conexão está ocupada. Se algum equipamento do caminho enfileira pacotes em buffer grande demais, a latência dispara sob carga — e a chamada de vídeo pica numa internet que o teste de velocidade jura estar ótima.

  1. Mede a latência com a rede parada — é a sua linha de base, o “ping” de sempre.
  2. Enche a fila de propósito — baixa dados em quatro fluxos ao mesmo tempo, para ocupar a conexão.
  3. Mede de novo, durante a carga — a diferença entre as duas é o bufferbloat.

Consome no máximo 12 MB da sua franquia, em até 6 segundos. Em rede móvel isso é cerca de 1,2% de um plano de 1 GB. O teste só roda quando você clica — nunca sozinho — e o botão vira “Parar” enquanto corre.

O teto de 12 MB é nosso, não do seu link: acima de uns 60 Mb/s a carga ainda acaba antes de a fila encher, e nesse caso o site avisa que o número medido é um piso — não o valor real. Preferimos medir de menos e dizer, a gastar a sua franquia para medir de mais.

Como classificamos — e o que este número não prova

Esta classificação é nossa. Bufferbloat não tem RFC que o defina como métrica, nem faixa oficial de nota — o que existe são as normas que combatem a fila, listadas abaixo. Nosso critério: até 30 ms de aumento é bom, porque o CoDel foi projetado para segurar a fila em 5 ms (RFC 8289 §4.5) e damos margem para o Wi-Fi e para o relógio do navegador; de 30 a 150 ms, atenção; de 150 a 600 ms, ruim, porque nessa faixa a conversa perde o ritmo; acima de 600 ms, muito ruim. O wiki do projeto Bufferbloat trata acima de ~50 ms como latência alta. bufferbloat.net ↗

Ressalvas, na ordem em que costumam morder: (1) medimos o caminho até o NOSSO servidor, não a internet inteira — outro destino pode ter outra fila; (2) uma medição só, numa rede que outras pessoas da casa estão usando, erra: repita com a casa quieta antes de concluir; (3) Wi-Fi ruim aparece aqui exatamente igual a bufferbloat do provedor, e não é a mesma coisa — teste também com cabo antes de culpar o link.

Bufferbloat não é uma RFC — é um problema. Estas são as normas que respondem a ele:

Recomendação do IETF: equipamento de rede deveria fazer gestão ativa de fila RFC 7567 §4 ↗
CoDel: de onde vem o alvo de 5 ms de fila que usamos como referência RFC 8289 §4.5 ↗
FQ-CoDel: o escalonador de fila nascido do esforço contra o bufferbloat RFC 8290 §1 ↗
PIE: traz “bufferbloat” no próprio título e descreve o mecanismo RFC 8033 §1 ↗

O que fazer

Excelente — MTU 1500 bytes
MTU do cliente: no mínimo 1500 bytes (MSS anunciado de no mínimo 1460) — a medição parou no limite do servidor. MSS efetivo em uso (snd_mss): 1448 bytes. MTU do servidor: 1500 bytes. Eficiência de payload: 100% do que…
Medição limitada pelo servidor
O MSS efetivo (1448) foi determinado pela MTU do servidor (1500), não pela do cliente. A MTU do cliente é de no mínimo 1500 bytes — pode ser maior. Para medir o valor exato seria necessário capturar o pacote SYN.
Timestamps ativos (RFC 7323)
Custam 12 bytes por segmento (0.8% do payload) e explicam a diferença entre o MSS anunciado (1460) e o efetivo (1448) — a redução é da sua própria máquina, não do caminho. Em troca dão medição precisa de RTT e…
1 retransmissões nesta sessão
Foram enviados 10 segmentos, dos quais 1 precisaram ser retransmitidos. Retransmissão numa sessão curta como esta sugere perda no caminho ou buraco negro de PMTU.