¿Por qué la pérdida de paquetes ralentiza un enlace de servidor doméstico que de otro modo sería rápido?

La pérdida de paquetes ralentiza un enlace de servidor doméstico que de otro modo sería rápido porque la velocidad del enlace mide qué tan rápido la interfaz puede transmitir bits, mientras que el rendimiento útil depende de cuántos datos de la aplicación llegan correctamente y cómo reacciona el protocolo de transporte cuando los paquetes desaparecen.

Los transportes confiables repiten los datos faltantes y usualmente reducen su tasa de envío porque la pérdida puede señalar congestión. Por lo tanto, una interfaz 1GbE o 10GbE puede permanecer completamente negociada mientras una copia de archivo, respaldo remoto, sesión web o transmisión de medios entrega solo una fracción de su rendimiento útil esperado.

¿Por qué puede mantenerse alta la velocidad del enlace mientras cae el rendimiento útil?

El ancho de banda es la capacidad nominal del camino, mientras que el buen rendimiento (goodput) cuenta solo la carga útil útil de la aplicación entregada con éxito. En un experimento controlado de calidad de camino, el rendimiento útil puede colapsar antes de que cambie la velocidad del enlace porque incluso una pequeña tasa de pérdida interrumpió repetidamente el flujo de transporte.

Los bytes retransmitidos, datos duplicados, encabezados y huecos de recuperación consumen tiempo sin avanzar el archivo completado o la respuesta de la aplicación. Los contadores de interfaz pueden mostrar aún tráfico sustancial incluso cuando el receptor recibe datos útiles lentamente.

Una prueba de velocidad también puede ocultar el problema usando varios flujos paralelos, un servidor cercano o un intervalo de prueba corto. Una transferencia única y prolongada a un punto final distante está más expuesta a pérdidas repetidas y recuperación de ida y vuelta.

¿Qué trabajo repite el transporte confiable después de una pérdida?

TCP y los flujos confiables de QUIC rastrean qué datos llegaron al receptor. Cuando se detecta un hueco, los datos perdidos deben transmitirse de nuevo, consumiendo ancho de banda adicional y retrasando la finalización.

El emisor puede detectar la pérdida mediante acuses de recibo duplicados, acuses de recibo selectivos, un temporizador de pérdida QUIC o un tiempo de espera de retransmisión. La detección rápida limita la pausa, mientras que un tiempo de espera puede añadir un retraso mucho mayor antes de que el emisor reintente.

La retransmisión no solo reemplaza un paquete perdido de forma aislada. El paquete original ya ha utilizado la capacidad del enlace, el reemplazo la usa nuevamente, y los paquetes cercanos también pueden ser retransmitidos cuando el emisor no puede identificar la pérdida con precisión.

¿Por qué TCP reduce su tasa de envío después de la pérdida de paquetes?

El TCP clásico trata la pérdida como evidencia de que puede estar entrando demasiada información en la ruta. el control de congestión basado en pérdidas reduce la tasa de envío para que el emisor deje de alimentar un posible cuello de botella a la tasa anterior.

La ventana de congestión controla cuántos datos no reconocidos pueden permanecer en vuelo. Reducir esa ventana puede disminuir el rendimiento mucho más que el porcentaje de paquetes realmente perdidos, porque el emisor debe luego aumentar la ventana nuevamente en rondas posteriores de reconocimiento.

Diferentes algoritmos reaccionan de manera distinta: Reno, CUBIC, variantes de BBR e implementaciones de QUIC no usan señales o reducciones idénticas. El límite general sigue siendo que un enlace físico rápido no puede entregar su capacidad cuando el transporte limita deliberadamente los datos en vuelo.

¿Cómo amplifica el tiempo de ida y vuelta la recuperación de pérdidas?

Un emisor se entera de la entrega a través de retroalimentación que viaja al receptor y regresa. un RTT más alto extiende cada ciclo de recuperación porque cada ajuste de ventana y confirmación de retransmisión consume otra parte del RTT.

En una ruta local corta de Ethernet, una retransmisión rápida puede completarse lo suficientemente rápido como para ser apenas visible. La misma pérdida en una VPN, respaldo remoto, montaje en la nube o conexión de larga distancia puede detener el progreso durante decenas o cientos de milisegundos.

El alto ancho de banda hace que la penalización sea más sorprendente porque más datos podrían haber estado en tránsito durante cada ida y vuelta. La pérdida vacía o reduce ese canal, y una ruta más larga necesita más tiempo para rellenarlo.

¿Por qué puede un paquete faltante retrasar datos que ya llegaron?

TCP presenta un flujo de bytes ordenado a la aplicación. un segmento faltante puede bloquear datos posteriores incluso cuando los paquetes posteriores ya han llegado al receptor.

Esos bytes posteriores pueden esperar en un búfer de recepción hasta que se repare la brecha. Para HTTP/2, varias solicitudes lógicas comparten una conexión TCP, por lo que una pérdida a nivel de transporte puede retrasar streams de respuesta independientes que se transmiten detrás de los bytes faltantes.

QUIC evita el bloqueo de línea de transporte entre streams porque los streams pueden recuperarse de forma independiente, pero la pérdida aún consume capacidad de retransmisión y presupuesto de control de congestión. Eliminar un mecanismo de bloqueo no hace que los paquetes perdidos sean gratuitos.

¿Por qué fallan de manera diferente las transferencias de archivos, los streams y las aplicaciones UDP?

TCP y UDP muestran la pérdida de forma diferente. Una transferencia de archivos espera bytes exactos, mientras que una llamada en vivo puede preferir un cuadro dañado o saltado antes que esperar datos que ya llegan demasiado tarde para reproducirse.

La pérdida TCP aparece como menor rendimiento, almacenamiento en búfer o retraso en la carga de páginas y archivos. La pérdida UDP puede manifestarse como interrupciones de audio, artefactos en bloques, fluctuaciones en el control, telemetría perdida o reintentos a nivel de aplicación, según el diseño de corrección de errores y recuperación hacia adelante.

El tráfico local e internet puede compartir un cuello de botella. Por eso la pérdida de paquetes debe interpretarse según la ruta y la carga de trabajo: una copia limpia en LAN no prueba que la ruta remota esté limpia, y una interfaz rápida no garantiza una entrega confiable de la aplicación.

Preguntas frecuentes

¿Puede una pérdida de paquetes del 1% realmente causar una caída mucho mayor en el rendimiento?

Sí, en algunas condiciones, especialmente para un flujo TCP con RTT significativo. El impacto exacto depende del algoritmo de control de congestión, patrón de pérdida, RTT, tamaño de ventana, flujos paralelos y características de recuperación.

¿Significa siempre la pérdida de paquetes que la red está congestionada?

No. La congestión es común, pero la pérdida también puede provenir de interferencias Wi-Fi, cables dañados, ópticas defectuosas, hosts sobrecargados, tarjetas de red defectuosas, problemas de MTU o límites de software y controladores.

¿Por qué una prueba de velocidad paralela puede parecer normal?

Múltiples flujos se recuperan de forma independiente y pueden llenar colectivamente el enlace incluso cuando cada flujo funciona mal. Una sola conexión de aplicación puede no recibir el mismo beneficio.

¿Evita UDP el costo de rendimiento de la pérdida de paquetes?

UDP evita la retransmisión incorporada y la entrega ordenada, pero la aplicación pierde datos o debe añadir su propio mecanismo de recuperación, ocultación, redundancia o reintento.

Conclusión final

La pérdida de paquetes convierte un enlace rápido en una ruta de aplicación lenta al desperdiciar capacidad de transmisión, forzar la recuperación confiable, reducir las ventanas de congestión y retrasar la entrega ordenada. La interfaz física puede mantenerse a velocidad completa mientras que los datos útiles llegan lentamente. El RTT, el protocolo de transporte, el patrón de pérdida y la carga de trabajo determinan si el resultado parece un bajo rendimiento, almacenamiento en búfer, latencia prolongada o pérdida de medios en tiempo real.