La pérdida de paquetes ocurre cuando uno o más paquetes de datos que viajan a través de una red informática no llegan a su destino. La pérdida de paquetes se debe a errores en la transmisión de datos, generalmente a través de redes inalámbricas , [1] [2] o la congestión de la red . [3] La pérdida de paquetes se mide como un porcentaje de paquetes perdidos con respecto a los paquetes enviados.
El Protocolo de control de transmisión (TCP) detecta la pérdida de paquetes y realiza retransmisiones para garantizar una mensajería confiable . La pérdida de paquetes en una conexión TCP también se usa para evitar la congestión y, por lo tanto, produce un rendimiento reducido intencionalmente para la conexión.
En aplicaciones en tiempo real como transmisión de medios o juegos en línea , la pérdida de paquetes puede afectar la calidad de la experiencia del usuario (QoE).
Causas
El Protocolo de Internet (IP) está diseñado de acuerdo con el principio de extremo a extremo como un servicio de entrega de mejor esfuerzo , con la intención de mantener lo más simple posible la implementación de los enrutadores lógicos . Si la red ofreciera garantías de entrega confiables por sí sola, eso requeriría una infraestructura de almacenamiento y reenvío , donde cada enrutador dedicara una cantidad significativa de espacio de almacenamiento a los paquetes mientras esperaba para verificar que el siguiente nodo los recibiera correctamente. Una red confiable no podría mantener sus garantías de entrega en caso de falla del enrutador. La confiabilidad tampoco es necesaria para todas las aplicaciones. Por ejemplo, con los medios de transmisión en vivo , es más importante entregar los paquetes recientes rápidamente que asegurarse de que los paquetes obsoletos se entreguen eventualmente. Una aplicación o un usuario también pueden decidir reintentar una operación que está tardando mucho tiempo, en cuyo caso se agregará otro conjunto de paquetes a la carga de entregar el conjunto original. Una red de este tipo también podría necesitar un protocolo de comando y control para la gestión de la congestión, lo que agrega aún más complejidad.
Para evitar todos estos problemas, el Protocolo de Internet permite que los enrutadores simplemente descarten paquetes si el enrutador o un segmento de red está demasiado ocupado para entregar los datos de manera oportuna. Esto no es ideal para una transmisión de datos rápida y eficiente, y no se espera que suceda en una red no congestionada. [4] La caída de paquetes actúa como una señal implícita de que la red está congestionada y puede hacer que los remitentes reduzcan la cantidad de ancho de banda consumido o intenten encontrar otra ruta. Por ejemplo, al utilizar la pérdida de paquetes percibida como retroalimentación para descubrir la congestión, el Protocolo de control de transmisión (TCP) está diseñado para que la pérdida excesiva de paquetes haga que el remitente acelere y deje de inundar el punto de cuello de botella con datos. [5]
Los paquetes también pueden descartarse si la suma de verificación del encabezado IPv4 o la secuencia de verificación de la trama de Ethernet indica que el paquete se ha dañado. La pérdida de paquetes también puede deberse a un ataque de caída de paquetes .
Redes inalámbricas
Las redes inalámbricas son susceptibles a una serie de factores que pueden dañar o perder paquetes en tránsito, como la interferencia de radiofrecuencia (RFI), [6] señales de radio que son demasiado débiles debido a la distancia o el desvanecimiento de múltiples rutas , hardware de red defectuoso o controladores de red defectuosos.
El Wi-Fi es inherentemente poco confiable e incluso cuando dos receptores Wi-Fi idénticos se colocan muy cerca el uno del otro, no muestran patrones similares de pérdida de paquetes, como cabría esperar. [7]
Las redes celulares pueden experimentar pérdida de paquetes causada por "alta tasa de errores de bits (BER), características de canal inestables y movilidad del usuario". [8] El comportamiento de estrangulamiento intencional de TCP evita que las redes inalámbricas funcionen cerca de sus tasas de transferencia potenciales teóricas porque el TCP sin modificar trata todos los paquetes descartados como si fueran causados por congestión de la red y, por lo tanto, puede estrangular las redes inalámbricas incluso cuando no están realmente congestionadas. [8]
Congestión en la red
La congestión de la red es una causa de pérdida de paquetes que puede afectar a todo tipo de redes. Cuando el contenido llega durante un período prolongado a un enrutador o segmento de red dado a una velocidad mayor de la que es posible enviar, no hay otra opción que descartar paquetes. [3] Si un solo enrutador o enlace limita la capacidad de la ruta de viaje completa o del viaje de la red en general, se conoce como cuello de botella . En algunos casos, los paquetes se eliminan intencionalmente mediante rutinas de enrutamiento, [9] o mediante una técnica de disuasión de red con fines de gestión operativa. [10]
Efectos
La pérdida de paquetes reduce directamente el rendimiento de un remitente determinado, ya que algunos datos enviados nunca se reciben y no se pueden contar como rendimiento. La pérdida de paquetes reduce indirectamente el rendimiento, ya que algunos protocolos de la capa de transporte interpretan la pérdida como una indicación de congestión y ajustan su velocidad de transmisión para evitar el colapso congestivo.
Cuando se necesita una entrega confiable, la pérdida de paquetes aumenta la latencia debido al tiempo adicional necesario para la retransmisión. [a] Suponiendo que no hay retransmisión, los paquetes que experimentan los peores retrasos pueden descartarse preferentemente (dependiendo de la disciplina de cola utilizada), lo que da como resultado una latencia general más baja.
Medición
La pérdida de paquetes se puede medir como la tasa de pérdida de tramas definida como el porcentaje de tramas que deberían haber sido reenviadas por una red pero no lo fueron. [11]
Pérdida de paquetes aceptable
La pérdida de paquetes está estrechamente relacionada con consideraciones de calidad de servicio . La cantidad de paquetes perdidos que es aceptable depende del tipo de datos que se envían. Por ejemplo, para el tráfico de voz sobre IP , un comentarista calculó que "[m] emitir uno o dos paquetes de vez en cuando no afectará la calidad de la conversación. Las pérdidas entre el 5% y el 10% del flujo total de paquetes afectarán la calidad significativamente ". [12] Otro describió la pérdida de paquetes de menos del 1% como "buena" para la transmisión de audio o video, y entre el 1-2,5% como "aceptable". [13]
Diagnóstico
La pérdida de paquetes se detecta mediante protocolos fiables como TCP. Los protocolos confiables reaccionan automáticamente a la pérdida de paquetes, por lo que cuando una persona, como un administrador de red, necesita detectar y diagnosticar la pérdida de paquetes, generalmente usa información de estado de equipos de red o herramientas diseñadas específicamente.
El Protocolo de mensajes de control de Internet proporciona una funcionalidad de eco , donde se transmite un paquete especial que siempre produce una respuesta. Herramientas como ping , traceroute y MTR utilizan este protocolo para proporcionar una representación visual de la ruta que toman los paquetes y para medir la pérdida de paquetes en cada salto . [B]
Muchos enrutadores tienen páginas de estado o registros, donde el propietario puede encontrar el número o porcentaje de paquetes descartados durante un período en particular.
Recuperación de paquetes para una entrega confiable
Según el principio de extremo a extremo , el Protocolo de Internet deja la responsabilidad de la recuperación de paquetes a través de la retransmisión de paquetes descartados a los puntos finales: las computadoras que envían y reciben los datos. Están en la mejor posición para decidir si la retransmisión es necesaria porque la aplicación que envía los datos debe saber si es mejor retransmitir un mensaje en su totalidad o en parte, si ha pasado o no la necesidad de enviar el mensaje y cómo controlar la cantidad. de ancho de banda consumido para dar cuenta de cualquier congestión.
Los protocolos de transporte de red, como TCP, proporcionan a los puntos finales una forma sencilla de garantizar la entrega fiable de paquetes, de modo que las aplicaciones individuales no necesiten implementar la lógica para ello. En caso de pérdida de paquetes, el receptor solicita la retransmisión o el remitente reenvía automáticamente cualquier segmento que no haya sido reconocido. [15] Aunque TCP puede recuperarse de la pérdida de paquetes, la retransmisión de los paquetes perdidos reduce el rendimiento de la conexión, ya que los receptores esperan retransmisiones y consumen ancho de banda adicional. En ciertas variantes de TCP, si se pierde un paquete transmitido, se volverá a enviar junto con todos los paquetes que ya se habían enviado después de él.
Los protocolos como el Protocolo de datagramas de usuario (UDP) no proporcionan recuperación para los paquetes perdidos. Se espera que las aplicaciones que usan UDP implementen sus propios mecanismos para manejar la pérdida de paquetes, si es necesario.
Impacto de la disciplina de las colas
Hay muchas disciplinas de puesta en cola que se utilizan para determinar qué paquetes descartar. La mayoría de los equipos de red básicos utilizarán la cola FIFO para los paquetes que esperan pasar por el cuello de botella y descartarán el paquete si la cola está llena en el momento en que se recibe el paquete. Este tipo de caída de paquetes se denomina caída de cola . Otros mecanismos de cola completa incluyen caída temprana aleatoria o caída temprana aleatoria ponderada . Descartar paquetes no es deseable ya que el paquete se pierde o debe retransmitirse y esto puede afectar el rendimiento en tiempo real; sin embargo, aumentar el tamaño del búfer puede provocar un bloqueo de búfer que tiene su propio impacto en la latencia y la fluctuación durante la congestión.
En los casos en que la calidad del servicio es la limitación de velocidad de una conexión, por ejemplo, usando un cubo agujereado algoritmo, los paquetes pueden ser dejados intencionalmente con el fin de frenar servicios específicos para garantizar el ancho de banda disponible para otros servicios marcados con una mayor importancia. Por esta razón, la pérdida de paquetes no es necesariamente una indicación de una mala confiabilidad de la conexión o signos de un cuello de botella en el ancho de banda.
Ver también
- Poco deslizamiento
- Colisión (telecomunicaciones)
- Goodput
- Ocultamiento de pérdida de paquetes
- Conformación del tráfico
Notas
- ^ Durante la congestión típica de la red, no se descartan todos los paquetes de una secuencia. Esto significa que los paquetes no descartados llegarán con baja latencia en comparación con los paquetes retransmitidos, que llegan con alta latencia. Los paquetes retransmitidos no solo tienen que viajar parte del camino dos veces, sino que el remitente no se dará cuenta de que el paquete se ha descartado hasta que no reciba el acuse de recibo en el orden esperado o no reciba el acuse de recibo durante un tiempo suficiente para que asume que el paquete se ha descartado en lugar de simplemente retrasado.
- ^ En algunos casos, estas herramientas pueden indicar caídas para paquetes que terminan en una pequeña cantidad de saltos, pero no para aquellos que llegan al destino. Por ejemplo, los enrutadores pueden dar una prioridad baja al eco de los paquetes ICMP y descartarlos preferentemente a favor de gastar recursos en datos genuinos; esto generalmente se considera un artefacto de la prueba y puede ignorarse en favor de los resultados de un extremo a otro. [14]
Referencias
- ^ Salyers, David C .; Striegel, Aaron; Poellabauer, Christian. "Fiabilidad inalámbrica: repensar la pérdida de paquetes 802.11" (PDF) . Archivado desde el original (PDF) el 12 de julio de 2019 . Consultado el 19 de febrero de 2018 .
- ^ Tian, Ye; Xu, Kai; Ansari, Nirwan (marzo de 2005). "TCP en entornos inalámbricos: problemas y soluciones" (PDF) . Comunicaciones por radio IEEE . 43 (3): S27 – S32. doi : 10.1109 / MCOM.2005.1404595 . S2CID 735922 . Archivado desde el original (PDF) el 9 de agosto de 2017 . Consultado el 19 de febrero de 2018 .
- ↑ a b Kurose, JF y Ross, KW (2010). Redes de computadoras: un enfoque de arriba hacia abajo . Nueva York: Addison-Wesley. pag. 36.
- ^ Kurose, JF; Ross, KW (2010). Redes de computadoras: un enfoque de arriba hacia abajo . Nueva York: Addison-Wesley. págs. 42 –43.
La fracción de paquetes perdidos aumenta a medida que aumenta la intensidad del tráfico. Por lo tanto, el rendimiento en un nodo a menudo se mide no solo en términos de retraso, sino también en términos de la probabilidad de pérdida de paquetes ... un paquete perdido puede retransmitirse de un extremo a otro para garantizar que todos los datos se transfieran eventualmente. de origen a destino.
- ^ Kurose, JF y Ross, KW (2008). Redes de computadoras: un enfoque de arriba hacia abajo . Nueva York: Addison-Wesley. pag. 282-283.
- ^ David C. Salyers, Aaron Striegel, Christian Poellabauer, Wireless Reliability: Rethinking 802.11 Packet Loss (PDF) , archivado desde el original (PDF) el 2019-07-12 , consultado el 2019-05-12CS1 maint: varios nombres: lista de autores ( enlace )
- ^ David C. Salyers, Aaron Striegel, Christian Poellabauer, Wireless Reliability: Rethinking 802.11 Packet Loss (PDF) , archivado desde el original (PDF) el 2019-07-12 , consultado el 2019-03-09CS1 maint: varios nombres: lista de autores ( enlace )
- ^ a b Ye Tian; Kai Xu; Nirwan Ansari (marzo de 2005). "TCP en entornos inalámbricos: problemas y soluciones" (PDF) . Comunicaciones por radio IEEE . IEEE . Archivado desde el original (PDF) el 9 de agosto de 2017 . Consultado el 19 de febrero de 2018 .
- ^ Perkins, CE (2001). Redes ad hoc . Boston: Addison-Wesley. pag. 147.
- ^ "Control de aplicaciones mediante la gestión de las características de la red" Vahab Pournaghshband, Leonard Kleinrock, Peter Reiher y Alexander Afanasyev ICC 2012
- ^ RFC 1242
- ^ Mansfield, KC y Antonakos, JL (2010). Redes informáticas desde LAN a WAN: hardware, software y seguridad . Boston: Tecnología del curso, Aprendizaje Cengage. pag. 501.
- ^ "Copia archivada" . Archivado desde el original el 10 de octubre de 2013 . Consultado el 16 de mayo de 2013 .CS1 maint: copia archivada como título ( enlace )
- ^ "Pérdida o latencia de paquetes en saltos intermedios" . Consultado el 25 de febrero de 2007 .
- ^ Kurose, JF y Ross, KW (2010). Redes de computadoras: un enfoque de arriba hacia abajo . Nueva York: Addison-Wesley. pag. 242.
enlaces externos
- Prueba de pérdida de paquetes