El bloqueo de cabecera de línea ( bloqueo HOL ) en redes de computadoras es un fenómeno que limita el rendimiento y ocurre cuando una cola de paquetes es retenida por el primer paquete de la cola. Esto ocurre, por ejemplo, en conmutadores de red con búfer de entrada , entrega desordenada y solicitudes múltiples en la canalización HTTP .
Un conmutador puede estar compuesto por puertos de entrada con búfer , una estructura de conmutador y puertos de salida con búfer. Si se utilizan buffers de entrada primero en entrar, primero en salir (FIFO), solo el paquete más antiguo estará disponible para reenviar. Si el paquete más antiguo no se puede transmitir debido a que la salida de destino está ocupada, los paquetes más recientes no se pueden reenviar. La salida puede estar ocupada si hay contención de salida .
Sin el bloqueo HOL, los recién llegados podrían potencialmente ser reenviados alrededor del paquete más antiguo atascado a sus respectivos destinos. El bloqueo HOL puede producir efectos que degradan el rendimiento en sistemas con búfer de entrada.
Este fenómeno limita el rendimiento de los conmutadores. Para los buffers de entrada FIFO, un modelo simple de celdas de tamaño fijo para destinos distribuidos uniformemente, hace que el rendimiento se limite al 58,6% del total a medida que aumenta el número de enlaces. [1]
Una forma de superar esta limitación es mediante el uso de colas de salida virtuales . [2]
Sólo los interruptores con buffer de entrada pueden sufrir bloqueo HOL. Con suficiente ancho de banda interno, el almacenamiento en búfer de entrada es innecesario; todo el almacenamiento en búfer se maneja en las salidas y se evita el bloqueo HOL. Esta arquitectura sin búfer de entrada es común en conmutadores Ethernet de tamaño pequeño y mediano .
La entrega desordenada ocurre cuando los paquetes secuenciados llegan desordenados. Esto puede suceder debido a diferentes rutas tomadas por los paquetes o a que los paquetes se descarten y se reenvíen. El bloqueo HOL puede aumentar significativamente la reordenación de paquetes. [3] [4]
La transmisión confiable de mensajes a través de una red con pérdidas entre una gran cantidad de pares es un problema difícil. Si bien los algoritmos de transmisión atómica resuelven el problema del punto único de falla de los servidores centralizados, esos algoritmos introducen un problema de bloqueo de cabecera de línea. [5] El algoritmo Bimodal Multicast, un algoritmo aleatorio que utiliza un protocolo de chismes , evita el bloqueo del encabezado de línea al permitir que algunos mensajes se reciban desordenados. [6]
Una forma de bloqueo HOL en HTTP/1.1 es cuando se agota la cantidad de solicitudes paralelas permitidas en el navegador y las solicitudes posteriores deben esperar a que se completen las anteriores. HTTP/2 soluciona este problema mediante la multiplexación de solicitudes, que elimina el bloqueo de HOL en la capa de aplicación, pero HOL todavía existe en la capa de transporte (TCP). [7] [8]
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 desordenados), los datos de las partes secuencialmente posteriores del flujo pueden recibirse antes que las partes secuencialmente anteriores. del arroyo; sin embargo, los datos posteriores normalmente no se pueden utilizar hasta que se hayan recibido los datos anteriores, lo que genera latencia en la 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 completamente recibido que se envió más tarde espere la entrega de un mensaje que se envió anteriormente. [9] Esto afecta, por ejemplo, a HTTP/2 , que enmarca múltiples pares de solicitud-respuesta en una sola secuencia; HTTP/3 , que tiene un diseño de entramado de capa de aplicación y utiliza datagramas en lugar de transporte de flujo, evita este problema. [10] [11] La degradación de la latencia debido al bloqueo de cabecera de línea 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. [12] [13] Sin cambiar la abstracción del flujo, reducir la pérdida de paquetes puede reducir el daño causado por el bloqueo de cabecera de línea; una alternativa es implementar el flujo de bytes confiable utilizando la corrección de errores hacia adelante para enviar datos redundantes de modo que se pueda tolerar una cierta cantidad de pérdida sin incurrir en retransmisiones. [9]
{{cite journal}}: Mantenimiento CS1: varios nombres: lista de autores ( enlace )