Necesito varios canales dúplex entre dos hosts. Hay una serie de ventajas para establecer una sola conexión TCP. Pero dudo que la multiplexación cause algunos problemas inevitables. ¿Dañará el rendimiento o aumentará significativamente la latencia? ¿Y qué hay del uso de la memoria y el uso de la CPU? ¿Hay alguna sugerencia o advertencia que le gustaría dar?
Respuestas:
TLDR: El principal inconveniente que puede notar al multiplexar múltiples canales sobre TCP (si lo hace correctamente) es una latencia aumentada debido al bloqueo de la cabecera de línea entre los canales.
Corolario: si no te importa la latencia, deberías estar bien.
Por otro lado, usar una sola conexión TCP "significa menos competencia con otros flujos y conexiones de mayor duración, lo que a su vez conduce a una mejor utilización de la capacidad de red disponible" .
Si multiplexa múltiples canales en la parte superior de la misma secuencia TCP, los canales pueden sufrir bloqueo de cabecera :
El bloqueo de cabecera de línea (HOL) puede ocurrir cuando los protocolos de transporte ofrecen un servicio ordenado o parcialmente ordenado: si los segmentos se pierden, los mensajes subsiguientes tienen que esperar la retransmisión exitosa en la cola del receptor y, por lo tanto, se retrasan.
Cuando multiplexas múltiples transmisiones sobre TCP, obtienes HOL entre los canales .
Si el canal A ha llenado el búfer de envío TCP, tendrá que esperar antes de que se reciban todos estos datos antes de que cualquier nuevo dato del canal B pueda transmitirse efectivamente a la capa de aplicación remota.
Consulte "Multiplexación en la parte superior de TCP" para obtener más detalles sobre los canales de multiplexación en la parte superior de TCP y la discusión sobre las noticias piratas informáticos .
Un ejemplo típico de esto es SSH. SSH puede multiplexar múltiples canales (ver ControlMaster, ControlPathy ControlPersisten OpenSSH). El uso de esto reduce el costo de inicializar una nueva sesión SSH (latencia inicial), pero una gran transferencia en un canal generalmente aumenta la latencia / interactividad de los otros (lo que no ocurre si usa múltiples flujos TCP): si está usando una conexión interactiva sesiones y comenzar a transferir una gran transferencia de archivos a través del mismo canal, su sesión comenzará a ser mucho menos interactiva.
HTTP / 2 utiliza la multiplexación de solicitudes / respuestas a través de TCP para corregir el bloqueo de HOL. Esta característica se anuncia en muchos artículos y documentos sobre HTTP / 2. El HTTP / 2 RFC afirma:
HTTP / 1.1 agregó la canalización de solicitudes, pero esto solo solucionó parcialmente la concurrencia de solicitudes y todavía sufre de bloqueo de cabecera.
[...]
El protocolo resultante es más amigable para la red porque se pueden usar menos conexiones TCP en comparación con HTTP / 1.x. Esto significa menos competencia con otros flujos y conexiones de mayor duración, lo que a su vez conduce a una mejor utilización de la capacidad de red disponible.
Sin embargo, lo que no se discute es que el bloqueo HOL no se resuelve por completo. HTTP / 2 sobre TCP todavía sufre ) de bloqueo HOL de nivel TCP .
Esto se discute en este artículo LWN sobre QUIC:
HTTP / 2 fue diseñado para abordar este problema utilizando múltiples "secuencias" integradas en una sola conexión . [...] crea un nuevo problema: la pérdida de un solo paquete detendrá la transmisión de todas las transmisiones a la vez, creando nuevos problemas de latencia. Esta variante del problema de bloqueo de cabecera de línea está integrada en el propio TCP y no se puede solucionar con más ajustes a nivel HTTP.
Esa es una de las características distintivas de SCTP (multitransmisión), puede tener múltiples flujos independientes en la misma asociación SCTP y cada flujo no bloquea a los demás.
Consulte SSH sobre SCTP: optimización de un protocolo multicanal adaptándolo a SCTP para obtener el efecto de usar SCTP a fin de evitar el bloqueo de HOL entre canales en SSH:
SCTP solo conserva el orden de los mensajes dentro de una sola secuencia para mitigar un efecto conocido como bloqueo de cabecera. Si se pierde un mensaje, los mensajes posteriores deben retrasarse hasta que el perdido se retransmita para preservar el pedido. Como solo se deben retrasar los mensajes de la misma secuencia, se reduce la cantidad de mensajes afectados después de una pérdida.
[...]
Al mapear los canales de SSH en las secuencias de SCTP, el beneficio de la transmisión múltiple se pone a disposición de SSH, que es la mitigación del bloqueo de cabecera .
SCTP no es necesariamente fácil de implementar (debido a la disponibilidad del sistema operativo, la interacción de middlebox, etc.). Una posibilidad es implementarlo sobre UDP en el espacio de usuario .
Otro ejemplo es el protocolo experimental QUIC utilizado para multiplexar HTTP sobre UDP (porque la multiplexación de múltiples flujos sobre TCP como HTTP / 2 sufre de bloqueo HOL ):
QUIC es un nuevo transporte que reduce la latencia en comparación con el de TCP. En la superficie, QUIC es muy similar a TCP + TLS + HTTP / 2 implementado en UDP.
[...]
Multiplexación sin bloqueo de cabeza de línea
Protocolo QUIC de Google: mover la web de TCP a UDP presenta una buena visión general del bloqueo QUIC y HOL al multiplexar canales sobre TCP.
Una presentación reciente afirma que HTTP sobre QUIC mejora la latencia pero que la mejora del bloqueo de HOL es un "beneficio menor":
0-RTT, más del 50% de la mejora de latencia
[...]
Menos retransmisiones basadas en el tiempo de espera mejoran la latencia de la cola […]
Otros beneficios más pequeños, por ejemplo, bloqueo de cabeza de línea
Tenga en cuenta que, si bien QUIC se describe como "muy similar a TCP + TLS + HTTP / 2 implementado en UDP", en realidad es un transporte de uso general que se puede utilizar independientemente de HTTP / 2 y puede satisfacer sus necesidades.
Nota: HTTP / QUIC se estandarizará como HTTP / 3 .
Yo diría que necesita leer la Guía ZeroMQ , los patrones que brinda con las razones y desventajas son lecturas esenciales.
Pero de lo contrario, no hay problema con desconectar el canal de red de la entrega de datos de su aplicación. Tendrás que encargarse de la muxing y demuxing de los paquetes de datos enviados (y recomendaría una arquitectura basada en paquetes aquí, no la transmisión de datos en un flujo continuo) y el almacenamiento en búfer de cada extremo.
De lo contrario, debería tener poco impacto, es posible que necesite más memoria, pero solo un poco, para almacenar datos en el búfer y un poco más de CPU, ya que maneja más código para bloquear y analizar paquetes, pero nada significativo. (a menos que esté escribiendo algo especializado que requiera un gran rendimiento y el rendimiento es crítico).
Sí, he construido un sistema de base de datos cliente-servidor utilizando precisamente este principio.
Los canales multiplexados en una conexión TCP envían cada uno paquetes de datos, que luego se dividen en los respectivos receptores en el otro extremo.
El enrutador de la conexión TCP realiza el acaparamiento de la conexión por medio de un canal peligroso haciendo una selección por turnos de qué paquete transmitir de entre los canales que tienen datos listos para enviar.
Para manejar el caso de un canal que decide enviar un paquete de 1GB y bloquear a todos los demás, el remitente puede elegir dividir un paquete en fragmentos y solo enviar un fragmento antes de darle un turno a otro canal. En el extremo receptor, el reensamblaje de los fragmentos en un paquete se realiza antes de que el destinatario vea el paquete.