Herramientas populares

Tema

Test de Pérdida de Paquetes

Haga una prueba de pérdida de paquetes con paquetes UDP reales, tal como los envían los juegos y las llamadas, y vea si los pierde en la subida o en la descarga. Una sola ejecución es también un test de latencia, un test de jitter y un test de bufferbloat.

Cada paquete se cronometra a través del centro de datos de Cloudflare más cercano · pérdida separada en subida y descarga · no se guarda nada
Perfil

3000 paquetes UDP de ida y vuelta a través del centro de datos de Cloudflare más cercano · 1 min · no se guarda nada

Cada paquete, según llegóEjemplo: 1 min en una línea de fibra

  • A tiempo 2995
  • Tarde 0
  • Perdido 4
  • Fuera de orden 1
  • Duplicado 0
PaquetesRáfagasSubidaSub.DescargaDesc.Retraso ms4 perdidosninguno–
Cada columna es un segundo: sus paquetes, de arriba abajo. Señale un segundo, o enfoque la franja y use las flechas del teclado.

¿Cómo funciona esta prueba de pérdida de paquetes?

Su navegador envía un flujo constante de pequeños paquetes UDP hasta el centro de datos de Cloudflare más cercano y directamente de vuelta a sí mismo, y cuenta cada uno que no regresa.

Los paquetes viajan por un canal de datos WebRTC configurado para no reenviar nunca un mensaje perdido, así que un paquete que se pierde se queda perdido: pérdida de paquetes real, no un retraso escondido por un reintento. Los retransmite el servicio TURN de Cloudflare, que es anycast: su navegador llega a la ubicación de Cloudflare más cercana, y el relay se establece ahí. Los dos extremos del flujo están en su navegador, con un mismo reloj, así que el retraso de cada paquete es exacto a la décima de milisegundo.

Un paquete de ese bucle cruza su conexión dos veces, de subida y de bajada, así que por sí solo no puede indicar dónde se perdió. Por eso a su lado se ejecuta una breve llamada de voz: su navegador envía un flujo de audio silencioso al servidor de llamadas de Cloudflare (Realtime SFU) y lo recibe de vuelta. Cloudflare informa qué paquetes nunca recibió, que es su pérdida de subida; lo que falta después es su pérdida de descarga.

Bajo carga, la línea se llena con descargas y luego con subidas desde los servidores del test de velocidad de Cloudflare mientras los paquetes siguen fluyendo, así que verá cómo cambian la pérdida, el jitter y la latencia cuando la línea está ocupada.

Su navegadorRelay (TURN)Cloudflare, el más cercanoServidor de llamadas (SFU)Cloudflare, el más cercanoEl bucle: paquetes de ida y vuelta¿perdido en la subida o en la descarga?el bucle no puede saberlo; cronometra cada paquete con un mismo relojLa llamada de prueba: Opus, 50 paquetes por segundo↑ subida↓ descargaCloudflare cuenta lo que recibió ↑su navegador cuenta lo que volvió ↓
  • Bucle: el retraso y el destino de cada paquete
  • Llamada: en qué dirección se perdió
  • Un paquete perdido
Ambos funcionan al mismo tiempo durante todo el test.
Resultado de una prueba de pérdida de paquetes: cada paquete, ráfagas al descargar, pérdida por sentido, jitter y bufferbloatResultado de una prueba de pérdida de paquetes: cada paquete, ráfagas al descargar, pérdida por sentido, jitter y bufferbloatEl veredictoLa pérdida, las ráfagas y el aumento del retraso bajo carga, evaluados frente a los objetivos de Microsoft Teams o la puntuación de juegos de Cloudflare.Cada paqueteCada columna es un segundo y cada marca, un paquete: a tiempo, tarde, perdido o fuera de orden, con las ráfagas señaladas entre corchetes.Subida o descargaLa llamada de prueba separa la pérdida: lo que Cloudflare nunca recibió de usted y lo que se perdió en el camino de vuelta hacia usted.Puntuaciones y calificaciónLas puntuaciones de Cloudflare para streaming, juegos y videollamadas, y la calificación de bufferbloat de Waveform, de A+ a F.
Un test de 1 minuto en una línea con bufferbloat: sin pérdida en reposo, breves ráfagas de pérdida y un retraso creciente mientras descarga. Seleccione un número para ver qué muestra cada parte.

¿Qué es la pérdida de paquetes?

La pérdida de paquetes es la proporción de paquetes de datos que salen de su dispositivo pero nunca llegan al otro extremo, o llegan demasiado tarde para usarse.

Los juegos y las llamadas de voz y video envían paquetes pequeños por UDP muchas veces por segundo y no esperan a que se reenvíen los perdidos: un paquete perdido es una imagen congelada, una palabra cortada en una llamada o un personaje que salta hacia atrás. Las descargas y las páginas web usan TCP, que reenvía lo que se perdió, así que ahí la pérdida solo se nota como una página más lenta. Por eso un test de velocidad normal no puede ver la pérdida de paquetes.

Este test cuenta cuatro cosas. Perdido: un paquete que no llegó después de 3 segundos, el tiempo de espera que, según la métrica de pérdida del IETF, se debe informar. Tarde: uno que llegó, pero muy por detrás de los demás. Fuera de orden: uno que llegó después de un paquete enviado más tarde (RFC 4737). Duplicado: uno que llegó dos veces y se cuenta una.

16 paquetes, uno cada 20 ms1 perdido · 1 tarde · 1 fuera de orden · 1 duplicado
EnviadosRecibidos tarde: 100 ms detrás de los demás11223344566778899101011111212131314141415151616
  • A tiempollegó con los demás
  • Tardellegó, pero muy por detrás de los demás: demasiado tarde para una llamada
  • Perdidono volvió en 3 segundos
  • Fuera de ordenllegó después de un paquete enviado más tarde
  • Duplicadollegó dos veces, se cuenta una
La franja del resultado usa los mismos colores, una celda por paquete.

¿Cuánta pérdida de paquetes es aceptable?

Para videollamadas, menos del 1 %: el objetivo de Microsoft para Teams es menos del 1 % de pérdida en cualquier intervalo de 15 segundos y menos del 10 % en cualquier intervalo de 200 milisegundos, y Zoom recomienda el 2 % o menos.

Cada veredicto de esta página sigue exactamente una regla publicada. Videollamadas: los objetivos de Microsoft Teams para el camino desde su dispositivo hasta el perímetro de la red (ida y vuelta por debajo de 100 ms, pérdida por debajo del 1 % en cada intervalo de 15 segundos, pérdida en ráfaga por debajo del 10 % en cada intervalo de 200 ms, jitter por debajo de 30 ms, reordenamiento por debajo del 0,05 %) y la recomendación de Zoom de 150 ms de latencia, 40 ms de jitter y 2 % de pérdida.

Juegos y streaming: las puntuaciones de calidad de red de Cloudflare, los mismos puntos que usa speed.cloudflare.com: menos del 1 % de pérdida obtiene todos los puntos; del 1 % al 5 %, la mitad; del 5 % al 25 %, ninguno, y más resta puntos. Para los juegos, los fabricantes no publican ningún límite de pérdida; incluso un 1 % en una ráfaga es un tirón visible a 64 o 128 actualizaciones por segundo.

Microsoft Teams menos del 1 % en cualquier intervalo de 15 s Zoom 2 % o menos 0 %0,5 %1 %2 %3 %4 %5 % Cloudflare AIM +10 puntos +5 del 5 % al 25 %: 0 · menos del 50 %: −10 · después, −20
  • Menos del 1 %: todos los puntos, dentro del objetivo de Teams
  • Del 1 % al 2 %: dentro del de Zoom
  • Más del 2 %: fuera de ambos
La regla de cada autoridad, tal como la aplican las comprobaciones del resultado. La cifra de Teams es por intervalo de 15 segundos, así que un mal momento breve la incumple aunque el promedio sea bajo.

¿Su pérdida de paquetes es aleatoria o en ráfagas?

El patrón importa tanto como el porcentaje: un 2 % de pérdida repartido apenas se nota en una llamada, mientras que un 2 % perdido en unas pocas ráfagas es una serie de cortes.

El test cuenta los episodios de pérdida, tandas de paquetes perdidos uno tras otro (RFC 6534), muestra el más largo y calcula el ratio de ráfaga de ITU-T G.107: 1 cuando las pérdidas caen al azar, más de 1 cuando se agrupan. Las ráfagas suelen venir de una cola llena en un router o un módem, que descarta varios paquetes del mismo flujo a la vez, o de un corte momentáneo del Wi-Fi.

Un test corto no puede demostrar que no haya pérdida. Si no se perdió ninguno de 750 paquetes, la tasa de pérdida sigue estando en algún punto por debajo del 0,4 %, así que la página muestra un rango, no un 0 % a secas. Haga el test de 3 minutos para detectar una pérdida que va y viene.

La misma pérdida de paquetes del 2 %, dos veces1 min · 3000 paquetes · 60 perdidos en cada caso

Aleatoriapérdidas sueltas, dispersas

Episodios de pérdida
60
Ráfaga más larga
1 · 20 ms
Ratio de ráfaga
0,98

En una llamada: algún chasquido leve de vez en cuando

En ráfagascinco tandas de 12

Episodios de pérdida
5
Ráfaga más larga
12 · 240 ms
Ratio de ráfaga
11,76

En una llamada: cinco cortes de 240 ms por minuto

Ratio de ráfaga (ITU-T G.107): la longitud media de las ráfagas dividida por la que daría una pérdida aleatoria con la misma tasa. 1 es aleatorio; cuanto más alto, más agrupada.

¿Qué es el jitter y cómo se mide en un test de jitter?

El jitter es cuánto cambia el retraso de un paquete al siguiente. Las llamadas y los juegos guardan paquetes en un búfer para suavizarlo, y ese búfer añade retraso.

Esta página mide el jitter con la fórmula de RFC 3550, la que informan las apps de llamadas WebRTC: el cambio de retraso entre paquetes a medida que llegan, suavizado sobre los últimos paquetes. Otras herramientas usan otras fórmulas: el test de velocidad de Cloudflare promedia la diferencia entre pings consecutivos; Waveform y Ookla, la desviación respecto de la media, así que sus cifras de jitter no se pueden comparar directamente. Las puntuaciones de Cloudflare en esta página usan la fórmula propia de Cloudflare, como corresponde.

Jitter entre llegadas según RFC 3550J = J + (|D| − J) / 16
EnviadoRecibidoCambio DJitter J 0 ms1820 ms21+340 ms19−260 ms26+780 ms18−8100 ms30+12120 ms19−11140 ms20+1160 ms22+22,31

Tiempos de tránsito en ms. Cada cambio mueve J un dieciseisavo del camino, así que un pico lo sube un poco y los paquetes estables lo vuelven a bajar.

El test de velocidad de Cloudflare promedia el cambio entre pings consecutivos; Waveform y Ookla, la dispersión alrededor de la media: la misma línea da tres cifras de jitter distintas.

¿Qué es el bufferbloat? La latencia bajo carga

El bufferbloat es el retraso extra que añade su conexión cuando está ocupada: su router o su módem pone demasiados datos en cola, así que cada paquete espera su turno detrás de una descarga o una subida.

El test bajo carga mide la latencia en reposo, luego al descargar y luego al subir, y califica el aumento en la escala de Waveform: A+ con menos de 5 ms añadidos, A con menos de 30, B con menos de 60, C con menos de 200, D con menos de 400 y F con 400 ms o más, a partir de la latencia media y de la peor de las dos direcciones.

La solución es la gestión inteligente de colas (SQM) en su router: CAKE o FQ-CoDel, con la velocidad configurada un poco por debajo de lo que entrega su línea, alrededor del 90 % de la velocidad medida según la guía de OpenWrt. Luego haga el test de nuevo: la calificación debería subir a A o A+.

El paquete de una llamada detrás de una subidauna línea de ejemplo
Cola de subida del router su llamada espera 175 msluego la cola se llenay descarta los siguientes una copia de seguridad o un video que se sube, paquete tras paquete
En reposo21 ms
Al descargar63 ms
Al subir196 ms
C+175 ms bajo carga: calificación C en la escala de WaveformWaveform
  1. A+<5
  2. A<30
  3. B<60
  4. C<200
  5. D<400
  6. F400+
El retraso añadido es la latencia media con carga menos la media en reposo, la peor entre descarga y subida, tal como lo califica Waveform.

¿Qué causa la pérdida de paquetes y cómo se soluciona?

La mayor parte de la pérdida de paquetes viene del Wi-Fi, de una línea ocupada (bufferbloat), de un cable o un puerto defectuoso o de la red de su proveedor; el patrón del test le indica cuál.

Una pérdida solo al descargar o al subir apunta al bufferbloat: active SQM. Una pérdida aleatoria en reposo por Wi-Fi apunta a interferencias o a la distancia: haga el test de nuevo con cable. Una pérdida también por cable puede deberse a un cable dañado, un puerto en mal estado o un firmware viejo del router. Si la prueba de la llamada sitúa la pérdida en el lado de descarga, con cable y con SQM activado, el problema suele estar más allá de su router: envíe a su proveedor el enlace para compartir y el CSV del test.

Elija el patrón que ve

Pérdida solo al descargar o al subir

Causa probable

Bufferbloat: la cola del router o del módem se desborda

Solución

Active SQM (CAKE o FQ-CoDel) a alrededor del 90 % de su velocidad

Pérdidas sueltas aleatorias, solo por Wi-Fi

Causa probable

Interferencias, distancia o una señal débil

Solución

Acérquese, cambie a 5 GHz o use un cable

Pérdida también por cable, incluso en reposo

Causa probable

Un cable o un puerto defectuoso, un firmware antiguo

Solución

Cambie el cable y el puerto, actualice el router

Pérdida en el lado de descarga, con cable y SQM activado

Causa probable

La red de su proveedor

Solución

Envíe a su proveedor el enlace para compartir y el CSV

Test de pérdida de paquetes vs. test de ping vs. test de velocidad

Un test de velocidad mide cuántos datos mueve su línea; un test de ping, cuánto tarda una ida y vuelta, y un test de pérdida de paquetes, con qué fiabilidad llegan los paquetes pequeños: tres preguntas distintas.

Use un test de ping para ver su latencia a lugares de todo el mundo, este test de pérdida de paquetes cuando las llamadas se cortan o los juegos dan tirones, y un test de velocidad cuando las descargas van lentas.

AspectoTest de pérdida de paquetesTest de pingTest de velocidad
MidePaquetes perdidos, tardíos y fuera de orden, jitter, latencia bajo cargaTiempo de ida y vuelta a un servidor o una regiónVelocidad de descarga y de subida
ProtocoloUDP (sin reenvíos)ICMP, TCP o HTTPSTCP (los reenvíos ocultan la pérdida)
Responde aPor qué se cortan las llamadas y los juegos dan tironesQué tan lejos se siente un servidorPor qué las descargas van lentas

Test de pérdida de paquetes: preguntas y respuestas

¿Cuál es una buena tasa de pérdida de paquetes para juegos?

Lo más cerca posible del 0 %. La puntuación de juegos de Cloudflare da todos los puntos por debajo del 1 % de pérdida y la mitad del 1 % al 5 %. Los fabricantes de juegos no publican un límite de pérdida, pero a 64 o 128 actualizaciones por segundo incluso una ráfaga corta significa un disparo que no cuenta o un personaje que salta hacia atrás, así que mire las ráfagas en la franja además del porcentaje.

¿Es malo un 1 % de pérdida de paquetes?

Para una videollamada está justo en el límite de Microsoft: el objetivo de Teams es menos del 1 % de pérdida en cualquier intervalo de 15 segundos. Zoom recomienda el 2 % o menos. En un juego, un 1 % se nota, más aún cuando llega en ráfagas. Para descargas y páginas web apenas importa, porque TCP reenvía los paquetes perdidos.

¿Por qué este test muestra pérdida de paquetes si mi test de velocidad está bien?

Un test de velocidad funciona sobre TCP, que reenvía cada paquete perdido, así que la pérdida solo hace la descarga un poco más lenta. Este test envía paquetes que nunca se reenvían, como un juego o una llamada, así que se cuenta cada paquete perdido. Una línea puede alcanzar su velocidad máxima y aun así perder paquetes en ráfagas, sobre todo cuando está ocupada.

¿Por qué solo pierdo paquetes mientras descargo?

Es el signo clásico del bufferbloat: su router o su módem guarda demasiados datos en su cola y, cuando la cola se desborda, descarta paquetes en ráfagas. El test bajo carga lo muestra como pérdida y como un aumento del retraso en la parte de descarga o de subida. La gestión inteligente de colas (CAKE o FQ-CoDel) en el router suele resolver ambas cosas.

¿La pérdida de paquetes está de mi lado o del de mi proveedor?

Sepárelo en tres pasos. La prueba de la llamada indica si los paquetes se pierden en la subida o en la descarga. Probar con cable en lugar de Wi-Fi le dice si el Wi-Fi es la causa. Probar con y sin carga le dice si es bufferbloat. Una pérdida que sigue en el lado de descarga con cable y en reposo suele ser de su proveedor.

¿Cómo puede un test en el navegador distinguir la pérdida de subida de la de descarga?

Los paquetes que suben y vuelven a bajar no pueden indicar dónde se perdieron, así que el test también hace una breve llamada de voz silenciosa al servidor de llamadas de Cloudflare. Cloudflare informa a su navegador cuántos de sus paquetes recibió, que es su pérdida de subida; lo que falta en el camino de vuelta es su pérdida de descarga.

¿Cuánto debe durar una prueba de pérdida de paquetes?

Haga el test de 15 segundos para una comprobación rápida y el de 3 minutos cuando el problema va y viene. Cero pérdidas en una ejecución corta no demuestra que no las haya: con 750 paquetes y ninguno perdido, la pérdida sigue estando en algún punto por debajo del 0,4 %, y la página muestra ese rango en lugar de 0 %.

¿Una VPN afecta al test de pérdida de paquetes?

Sí. Con una VPN activada, los paquetes pasan primero por el servidor de la VPN, así que el resultado muestra el camino a través de la VPN, no su línea por sí sola. Desactive la VPN para probar su conexión y luego actívela para ver lo que añade.

¿Cuántos datos usa el test?

El flujo de paquetes en sí es pequeño: un test de 1 minuto mueve como mucho unos pocos megabytes, incluso a 128 paquetes por segundo. Las partes bajo carga descargan y suben tan rápido como lo permite su línea, durante hasta un tercio del test cada una, con un máximo de 250 MB de bajada y 100 MB de subida, así que en una conexión medida o móvil deje desactivada la opción bajo carga.

¿Se guarda algo?

No. El test se ejecuta entre su navegador y el centro de datos de Cloudflare más cercano, que retransmite los paquetes cifrados sin leerlos. Las ejecuciones anteriores se quedan solo en este navegador. Un enlace para compartir lleva el resultado, nunca su dirección IP, y está firmado: si alguien cambia el enlace después de crearlo, aparece como editado.

Herramientas relacionadas