google chrome - ¿Por qué se deshabilita la canalización en los navegadores modernos?

google-chrome internet-explorer (1)

La tubería está deshabilitada por las siguientes razones:

Firefox:

El problema más grande ha sido, francamente, el bloqueo de jefes de línea y su impacto en el rendimiento y la solidez. Las tuberías ingenuas simplemente empeoran el rendimiento.

Cromo:

La opción para habilitar la canalización se ha eliminado de Chrome, ya que se conocen errores de bloqueo y problemas conocidos de bloqueo en la parte delantera de la cola. También hay una gran cantidad de servidores y middleboxes que se comportan de manera incorrecta e inconsistente cuando se habilita la canalización. Hasta que no se resuelvan, se recomienda que nadie use la canalización. Hacerlo actualmente requiere una compilación personalizada de Chromium.

En general:

Los proxies con errores aún son comunes y conducen a comportamientos extraños y erráticos que los desarrolladores web no pueden prever y diagnosticar fácilmente.
La implementación de la canalización es compleja: el tamaño del recurso que se transfiere, el RTT efectivo que se utilizará, así como el ancho de banda efectivo, tienen una incidencia directa en la mejora proporcionada por el oleoducto. Sin saber esto, los mensajes importantes pueden retrasarse detrás de los que no son importantes. ¡La noción de importante incluso evoluciona durante el diseño de la página! Por lo tanto, la canalización HTTP trae una mejora marginal en la mayoría de los casos solamente.
La canalización está sujeta al problema HOL .

HTTP / 2 ofrece una alternativa:

Con HTTP / 1.x, el navegador tiene una capacidad limitada para aprovechar los datos de prioridad superior: el protocolo no admite multiplexación y no hay manera de comunicar la prioridad de solicitud al servidor. En su lugar, debe confiar en el uso de conexiones paralelas, lo que permite un paralelismo limitado de hasta seis solicitudes por origen. Como resultado, las solicitudes se ponen en cola en el cliente hasta que una conexión esté disponible, lo que agrega una latencia de red innecesaria. En teoría, HTTP Pipelining intentó abordar parcialmente este problema, pero en la práctica no logró obtener la adopción.
HTTP / 2 resuelve estas ineficiencias: la cola de solicitudes y el bloqueo del encabezado de línea se eliminan porque el navegador puede enviar todas las solicitudes en el momento en que se descubren, y el navegador puede comunicar su preferencia de priorización de la ruta a través de las dependencias y los pesos de la ruta, lo que permite al servidor optimizar aún más la entrega de respuesta.

También se puede usar un proxy:

Puedes intentar algo que hice para acelerar Konqueror en KDE3. No estaba satisfecho con el hecho de que Konqueror no tuviera la canalización de HTTP, así que después de algunas búsquedas, instalé Polipo como un proxy HTTP / HTTPS / FTP local y configuré a Konqueror para que lo use (localhost en el puerto 8123 si recuerdo bien). Además de la canalización de HTTP, Polipo también proporcionó un almacenamiento en caché mejorado, y como era un proxy, pude configurar cada navegador para que lo usara y el almacenamiento en caché se compartiría entre los navegadores. (Esto también significa que es una buena idea deshabilitar el almacenamiento en caché independiente de cada navegador).

Salesforce utiliza el siguiente proceso:

Salesforce tiene un enfoque poderoso y probado en el campo para mitigar HOLB en la capa TCP: desacoplamos la relación entre una solicitud HTTP y una conexión TCP. Piense que su transporte está compuesto por múltiples conexiones TCP (tantas como el contexto de red necesitaría). Cualquier parte de la solicitud HTTP puede pasar por cualquier conexión TCP. Por lo tanto, si golpea el HOLB en una conexión, no solo ayuda a mitigar las solicitudes afectadas, sino que también minimiza el impacto en otras solicitudes de aplicaciones utilizando conexiones saludables. El resultado es una capacidad para disfrutar de los beneficios de la multiplexación y la canalización en la capa HTTP al tiempo que minimiza los riesgos de HOLB.

Referencias

Muchos, si no todos los navegadores modernos, no están utilizando solicitudes HTTP canalizadas. En teoría, la canalización debe acelerar las solicitudes al reducir el número de tiempos de viaje de ida y vuelta requeridos para obtener un sitio web.

De acuerdo con el estándar HTTP, todos los servidores deben manejar solicitudes canalizadas, por lo que el problema no debe ser la falta de soporte en los servidores.

He visto algunos problemas de seguridad, como un ataque DoS de capa 7 si un cliente envía tantas solicitudes canalizadas como sea posible a una URL que requiere un alto rendimiento para el servidor, ignorando cualquier respuesta que pueda recibirse.

Esa sería una razón para desactivar el soporte de canalización en el servidor (violando el estándar), pero no puedo encontrar ninguna razón para desactivarlo en los clientes.

Sin embargo, está activado de forma predeterminada en los navegadores Android y Chrome mobile.

¿Por qué Chrome, Firefox, IE, Opera y Safari no utilizan solicitudes HTTP canalizadas en su versión de escritorio (y, a veces, móvil)? ¿Cuál es su razonamiento detrás de apagarlo?