El bloqueo de cabecera de línea ( bloqueo HOL ) en redes informáticas es un fenómeno que limita el rendimiento y que se produce cuando una cola de paquetes se ve retenida por el primer paquete de la cola. Esto ocurre, por ejemplo, en conmutadores de red con búfer de entrada , entregas fuera de orden y solicitudes múltiples en la canalización HTTP .
Un conmutador puede estar compuesto de puertos de entrada con buffer , una estructura de conmutación y puertos de salida con buffer. Si se utilizan buffers de entrada FIFO ( primero en entrar, primero en salir ), solo el paquete más antiguo está disponible para reenvío. Si el paquete más antiguo no se puede transmitir debido a que su salida de destino está ocupada, entonces no se pueden reenviar las llegadas más recientes. La salida puede estar ocupada si hay contención de salida .
Sin el bloqueo HOL, los paquetes recién llegados podrían ser reenviados a sus respectivos destinos sin pasar por el paquete más antiguo bloqueado. El bloqueo HOL puede producir efectos de degradación del rendimiento en sistemas con búfer de entrada.
Este fenómeno limita el rendimiento de los conmutadores. En el caso de los buffers de entrada FIFO, un modelo simple de celdas de tamaño fijo con destinos distribuidos de manera uniforme 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]
Solo los conmutadores con almacenamiento en búfer de entrada pueden sufrir bloqueo HOL. Con un ancho de banda interno suficiente, el almacenamiento en búfer de entrada es innecesario; todo el almacenamiento en búfer se gestiona en las salidas y se evita el bloqueo HOL. Esta arquitectura sin almacenamiento en búfer de entrada es común en conmutadores Ethernet de tamaño pequeño a mediano .
La entrega fuera de orden se produce cuando los paquetes secuenciados llegan fuera de orden. Esto puede suceder debido a diferentes caminos tomados por los paquetes o porque algunos paquetes se descartan y se reenvían. El bloqueo HOL puede aumentar significativamente la reordenación de los 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 en la cabecera de la línea. [5] El algoritmo de multidifusión bimodal, un algoritmo aleatorio que utiliza un protocolo de chismes , evita el bloqueo en la cabecera de la línea al permitir que algunos mensajes se reciban fuera de orden. [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 HOL en la capa de aplicación, pero HOL aún 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 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 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ó antes. [9] 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. [10] [11] 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. [12] [13] 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. [9]
{{cite journal}}: CS1 maint: varios nombres: lista de autores ( enlace )