Articulo de referencia

Flujo de bytes fiable

Un flujo de bytes fiable es un paradigma de servicio común en las redes informáticas ; se refiere a un flujo de bytes en el que los bytes que emergen del canal de comunicación e...

Un flujo de bytes fiable es un paradigma de servicio común en las redes informáticas ; se refiere a un flujo de bytes en el que los bytes que emergen del canal de comunicación en el receptor son exactamente los mismos, y en el mismo orden, que cuando el remitente los insertó en el canal.

El ejemplo clásico de un protocolo de comunicación de flujo de bytes fiable es el Protocolo de Control de Transmisión (TCP) , uno de los principales componentes básicos de Internet .

Sin embargo , un flujo de bytes fiable no es el único paradigma de servicio fiable que proporcionan los protocolos de comunicación de redes informáticas; otros protocolos (por ejemplo, SCTP ) proporcionan un flujo de mensajes fiable, es decir, los datos se dividen en unidades distintas, que se proporcionan al consumidor de los datos como objetos discretos.

Mecanismo

Los protocolos de comunicación que implementan flujos de bytes fiables, generalmente sobre una capa inferior no fiable, utilizan diversos mecanismos para proporcionar dicha fiabilidad. Los protocolos de solicitud de repetición automática (ARQ) desempeñan un papel importante para lograrla.

Todos los elementos de datos se identifican con un número de secuencia , que se utiliza tanto para asegurar que los datos se entreguen a la entidad receptora en el orden correcto como para comprobar si hay datos perdidos. El receptor envía confirmaciones de recepción para los elementos de datos recibidos correctamente; un temporizador en el emisor provocará un tiempo de espera si no se recibe una confirmación en un tiempo de ida y vuelta razonable , y los datos (presumiblemente perdidos) se retransmitirán . Para comprobar que ningún elemento de datos esté dañado, se utiliza una suma de verificación ; esta se calcula en el emisor para cada bloque de datos antes de su envío y se comprueba en el receptor. Los datos erróneos o faltantes se notifican al emisor para que pueda retransmitirlos. Cualquier elemento de datos duplicado se descarta.

Bloqueo de cabeza de línea

El bloqueo de cabecera de línea puede ocurrir en flujos de bytes confiables: si los paquetes se reordenan o se pierden y necesitan ser retransmitidos (y por lo tanto llegan fuera de orden), los datos de partes secuencialmente posteriores del flujo pueden recibirse antes que las partes secuencialmente anteriores del flujo; sin embargo, los datos posteriores normalmente no se pueden usar hasta que se hayan recibido los datos anteriores, lo que genera latencia de red . Si se encapsulan y multiplexan varios mensajes independientes de nivel superior en un único flujo de bytes confiable, entonces el bloqueo de cabecera de línea puede hacer que el procesamiento de un mensaje recibido completamente que se envió más tarde espere la entrega de un mensaje que se envió antes. [ 1 ] Esto afecta, por ejemplo, a HTTP/2 , que enmarca múltiples pares de solicitud - respuesta en un solo flujo; HTTP/3 , que tiene un diseño de enmarcado de capa de aplicación y usa datagramas en lugar de transporte de flujo, evita este problema. [ 2 ] [ 3 ] La degradación de la latencia por bloqueo de cabecera de línea depende de la tasa de pérdida de paquetes subyacente y del tiempo de ida y vuelta , y mayores pérdidas producen una peor latencia. [ 4 ] [ 5 ] Sin cambiar la abstracción del flujo, reducir la pérdida de paquetes puede reducir el daño del bloqueo de cabecera de línea; una alternativa es implementar el flujo de bytes confiable utilizando corrección de errores hacia adelante para enviar datos redundantes de modo que se pueda tolerar cierta cantidad de pérdida sin incurrir en retransmisiones. [ 1 ]

Véase también

Referencias

  1. ^ Briscoe y col. 2016 , págs. 29-30.
  2. ^ Langley y col. 2017 , págs. 184, 186.
  3. ^ Marx y otros. 2018 , págs. 22-23.
  4. Nowlan, Wolinsky y Ford 2013 , pág. 6.
  5. Heijligers 2021 , pág. 65.
  • Larry L. Peterson y Bruce S. Davie, Redes de computadoras: un enfoque de sistemas, 3.ª edición, Morgan Kaufmann Publishers, 1996, Sección 6.2.
  • Steve Steinke, Tutorial de red, Elsevier, 2000, página 163.

Bibliografía

  • Briscoe, Bob; Brunstrom, Anna; Petlund, Andreas; Hayes, David; Ros, David; Tsang, Ing-Jyh; Gjessing, Stein; Fairhurst, Gorry; Griwodz, Carsten; Welzl, Michael (2016). "Reducción de la latencia de Internet: una revisión de técnicas y sus méritos". IEEE Communications Surveys & Tutorials . 18 (3): 2149– 2196. doi : 10.1109/COMST.2014.2375213 . hdl : 2164/8018 . S2CID 206576469 . 
  • Heijligers, Jaap (2021). Tor sobre QUIC (Tesis).
  • Langley, Adam; Riddoch, Alistair; Wilk, Alyssa; Vicente, Antonio; Krasic, Charles; Zhang, Dan; Yang, Fan; Kouranov, Fedor; Swett, Ian; Iyengar, Janardhan; Bailey, Jeff; Dorfman, Jeremy; Roskind, Jim; Kulik, Joanna; Westin, Patrik; Tenneti, Raman; Shade, Robbie; Hamilton, Ryan; Vasiliev, Victor; Chang, Wan-Teh; Shi, Zhongyi (2017). "El protocolo de transporte QUIC". Actas de la Conferencia del Grupo de Interés Especial en Comunicación de Datos de la ACM . págs. 183–196 . doi : 10.1145/3098822.3098842 . ISBN  9781450346535. S2CID 2768765 . 
  • Marx, Robin; Wijnants, Maarten; Quax, Peter; Faes, Axel; Lamotte, Wim (2018). "Características de rendimiento web de HTTP/2 y comparación con HTTP/1.1" (PDF) . Sistemas y tecnologías de información web . Notas de clase sobre procesamiento de información empresarial. Vol.  322. pp. 87–114 . doi : 10.1007/978-3-319-93527-0_5 . hdl : 1942/26146 . ISBN  978-3-319-93526-3. S2CID 52009597 . Archivado (PDF) del original el 18-04-2024 . Recuperado el 23-02-2024 . 
  • Nowlan, Michael F.; Wolinsky, David; Ford, Bryan (2013). Reducción de la latencia en circuitos Tor con entrega no ordenada . Tercer taller USENIX sobre comunicaciones libres y abiertas en Internet.