Un flujo de bytes confiable es un paradigma de servicio común en redes de computadoras ; se refiere a un flujo de bytes en el que los bytes que emergen del canal de comunicación en el destinatario son exactamente los mismos, y en exactamente 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 confiable es el Protocolo de Control de Transmisión , uno de los principales componentes de Internet .
Sin embargo, un flujo de bytes confiable no es el único paradigma de servicio confiable que proporcionan los protocolos de comunicación de redes informáticas; otros protocolos (por ejemplo, SCTP ) proporcionan un flujo de mensajes confiable, es decir, los datos se dividen en unidades distintas, que se proporcionan al consumidor de los datos como objetos discretos.
Los protocolos de comunicación que implementan flujos de bytes confiables, generalmente en un nivel inferior no confiable, utilizan una serie de mecanismos para proporcionar esa confiabilidad. Los protocolos de solicitud de repetición automática (ARQ) tienen un papel importante para lograr la confiabilidad.
Todos los elementos de datos se identifican con un número de secuencia , que se utiliza tanto para asegurarse de que los datos se entregan a la entidad en el otro extremo en el orden correcto, como para comprobar si hay elementos de datos perdidos. El receptor envía de vuelta acuses de recibo de los elementos de datos que se han recibido correctamente; un temporizador en el remitente provocará un tiempo de espera si no se recibe un acuse de recibo dentro de un tiempo de ida y vuelta razonable , y los datos (presumiblemente perdidos) se volverán a transmitir . Para comprobar que no hay elementos de datos dañados, se utiliza una suma de comprobación ; se calcula una en el remitente para cada bloque de datos antes de que se envíe y se comprueba en el receptor. Los datos erróneos o faltantes se informan al remitente, para que pueda retransmitirlos. Todos los elementos de datos duplicados se descartan.
El bloqueo de cabecera 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 las partes secuencialmente posteriores del flujo pueden recibirse antes que las partes secuencialmente anteriores del flujo; sin embargo, los datos posteriores normalmente no pueden usarse hasta que se hayan recibido los datos anteriores, lo que genera latencia de red . Si se encapsulan y multiplexan múltiples mensajes independientes de nivel superior en un solo flujo de bytes confiable, entonces el bloqueo de cabecera puede hacer que el procesamiento de un mensaje completamente recibido 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 utiliza datagramas en lugar de transporte de flujo, evita este problema. [2] [3] La degradación de la latencia por el bloqueo de cabecera depende de la tasa de pérdida de paquetes subyacente y del tiempo de ida y vuelta , y las pérdidas más altas producen una peor latencia. [4] [5] Sin cambiar la abstracción del flujo, la reducción de la pérdida de paquetes puede reducir el daño del bloqueo de cabecera; una alternativa es implementar el flujo de bytes confiable utilizando la corrección de errores de avance para enviar datos redundantes de modo que se pueda tolerar una cierta cantidad de pérdida sin incurrir en retransmisiones. [1]