Ir al contenido
M4NET-20260902-e1978708
Informe .txt JSON
PT-BRPortuguês do Brasil Español de América Latina
IPv4 verificando…
IPv6 verificando…

Transporte

Direcciones

MTU de la ruta OK

Paquete más grande que atraviesa la ruta sin fragmentarse. Inferido del MSS que su equipo anunció en el handshake TCP.

1500 · usted
maloaceptableideal
12801500
Referencias: 1492 PPPoE · 1420 WireGuard · 1500 Ethernet limpia
MTU del cliente
1500
MSS anunciado
1460
MSS efectivo
1448
MTU del servidor
1500
Su equipo
1460
Ruta
1500
Nuestro servidor
1448
El límite vino de nuestro servidor: la MTU de su lado puede ser mayor.

Medición limitada por el servidor: la MTU de su lado es de al menos 1500 bytes, y puede ser mayor.

Opciones TCP negociadas

Lo que ambos lados acordaron durante el handshake.

TimestampsSACKWindow scalingECN
Escala de ventana · cliente2^7
Escala de ventana · servidor2^7
RWIN máximo del cliente8388480 B

Rendimiento

Latencia, pérdida y ventana medidas por el kernel.

Latencia (RTT)153.39 ms
Variación (jitter)±32.40 ms
Retransmisiones0
Ventana de congestión10
MSS de recepción536 (no medido)
Path MTU (kernel)1500

Latencia bajo carga (bufferbloat) No medido

Por qué una internet rápida aún parece lenta: el bufferbloat es el retraso extra que aparece cuando los datos quedan en una cola de espera porque la conexión está ocupada. Si algún equipo del camino encola paquetes en un búfer demasiado grande, la latencia se dispara bajo carga — y la videollamada se corta en una internet que el test de velocidad jura que está excelente.

  1. Mide la latencia con la red en reposo — es su línea de base, el “ping” de siempre.
  2. Llena la cola a propósito — descarga datos en cuatro flujos a la vez, para ocupar la conexión.
  3. Mide de nuevo, durante la carga — la diferencia entre ambas es el bufferbloat.

Consume como máximo 12 MB de su plan de datos, en hasta 6 segundos. En red móvil eso es cerca del 1,2% de un plan de 1 GB. La prueba solo se ejecuta cuando usted hace clic — nunca sola — y el botón se convierte en “Detener” mientras corre.

El tope de 12 MB es nuestro, no de su enlace: por encima de unos 60 Mb/s la carga aún termina antes de que la cola se llene, y en ese caso el sitio avisa que el número medido es un piso — no el valor real. Preferimos medir de menos y decirlo, a gastar su plan de datos para medir de más.

Cómo clasificamos — y qué no prueba este número

Esta clasificación es nuestra. Bufferbloat no tiene una RFC que lo defina como métrica, ni un rango oficial de nota — lo que existe son las normas que combaten la cola, listadas abajo. Nuestro criterio: hasta 30 ms de aumento es bueno, porque CoDel fue diseñado para mantener la cola en 5 ms (RFC 8289 §4.5) y damos margen para el Wi-Fi y para el reloj del navegador; de 30 a 150 ms, atención; de 150 a 600 ms, malo, porque en ese rango la conversación pierde el ritmo; por encima de 600 ms, muy malo. El wiki del proyecto Bufferbloat trata por encima de ~50 ms como latencia alta. bufferbloat.net ↗

Reservas, en el orden en que suelen morder: (1) medimos el camino hasta NUESTRO servidor, no internet entera — otro destino puede tener otra cola; (2) una sola medición, en una red que otras personas de la casa están usando, se equivoca: repita con la casa tranquila antes de concluir; (3) un Wi-Fi malo aparece aquí exactamente igual que el bufferbloat del proveedor, y no es lo mismo — pruebe también con cable antes de culpar al enlace.

Bufferbloat no es una RFC — es un problema. Estas son las normas que responden a él:

Recomendación del IETF: los equipos de red deberían hacer gestión activa de cola RFC 7567 §4 ↗
CoDel: de donde viene el objetivo de 5 ms de cola que usamos como referencia RFC 8289 §4.5 ↗
FQ-CoDel: el planificador de cola nacido del esfuerzo contra el bufferbloat RFC 8290 §1 ↗
PIE: lleva “bufferbloat” en el propio título y describe el mecanismo RFC 8033 §1 ↗

Qué hacer

Excelente — MTU 1500 bytes
MTU del cliente: como mínimo 1500 bytes (MSS anunciado de como mínimo 1460) — la medición se detuvo en el límite del servidor. MSS efectivo en uso (snd_mss): 1448 bytes. MTU del servidor: 1500 bytes. Eficiencia de payload…
Medición limitada por el servidor
El MSS efectivo (1448) lo determinó la MTU del servidor (1500), no la del cliente. La MTU del cliente es de como mínimo 1500 bytes — puede ser mayor. Para medir el valor exacto sería necesario capturar el paquete SYN.
Timestamps activos (RFC 7323)
Cuestan 12 bytes por segmento (0.8% del payload) y explican la diferencia entre el MSS anunciado (1460) y el efectivo (1448) — la reducción es de su propia máquina, no de la ruta. A cambio dan medición precisa de RTT y…