Ho bisogno di più canali duplex tra due host. Esistono numerosi vantaggi per stabilire una sola connessione TCP. Ma dubito che il multiplexing causerebbe alcuni problemi inevitabili. Danneggerà le prestazioni o aumenterà significativamente la latenza? E per quanto riguarda l'utilizzo della memoria e l'utilizzo della CPU? C'è qualche suggerimento o avvertimento che vorresti dare?
TLDR: l'inconveniente maggiore che potresti notare quando multiplexing più canali su TCP (se lo fai correttamente) è un aumento della latenza a causa del blocco della linea di testa tra i canali.
Corollario: se non ti interessa la latenza dovresti stare bene.
D'altra parte utilizzando una singola connessione TCP "significa meno concorrenza con altri flussi e vita più lunga connessioni, che a loro volta portano a un migliore utilizzo di capacità di rete disponibile ".
Se si multiplex più canali sullo stesso flusso TCP, i canali potrebbero soffrire di block-of-line blocking :
Head-of-line blocking (HOL) can occur when transport protocols offer ordered or partial-ordered service: If segments get lost, subsequent messages have to wait for the successful retransmission in the receiver queue and are thus delayed.
Quando esegui il multiplexing di più stream su TCP, ottieni HOL tra i canali .
Se il canale A ha riempito il buffer di invio TCP, è necessario attendere prima che tutti questi dati vengano ricevuti prima che qualsiasi nuovo dato del canale B possa essere effettivamente trasmesso al livello dell'applicazione remoto.
Vedi "Multiplexing su TCP" per maggiori dettagli sui canali multiplexing su TCP e su discussione su hackernews .
Un tipico esempio di questo è SSH. SSH può multiplexare più canali (vedere ControlMaster , ControlPath e ControlPersist in OpenSSH). L'utilizzo di questo riduce il costo di inizializzazione di una nuova sessione SSH (latenza iniziale) ma il trasferimento pesante su un canale di solito aumenta la latenza / l'interattività degli altri (cosa che non accade se si utilizza più stream TCP): se si sta utilizzando un sistema interattivo sessioni e inizia a generare un pesante trasferimento di file sullo stesso canale, la tua sessione inizierà a diventare molto meno interattiva.
HTTP / 2 utilizza il multiplexing di richieste / risposte su TCP per correggere il blocco HOL. Questa funzione è pubblicizzata in molti articoli e articoli su HTTP / 2. Le richieste RFC HTTP / 2 :
HTTP/1.1 added request pipelining, but this only partially addressed request concurrency and still suffers from head-of-line blocking.
[...]
The resulting protocol is more friendly to the network because fewer TCP connections can be used in comparison to HTTP/1.x. This means less competition with other flows and longer-lived connections, which in turn lead to better utilization of available network capacity.
Tuttavia ciò che non viene discusso è che il blocco HOL non è stato risolto completamente. HTTP / 2 su TCP ancora soffre ) da Blocco HOL di blocco TCP .
Questo è discusso in questo articolo LWN su QUIC:
HTTP/2 was designed to address this problem using multiple "streams" built into a single connection. [...] it creates a new problem: the loss of a single packet will stall transmission of all of the streams at once, creating new latency issues. This variant on the head-of-line-blocking problem is built into TCP itself and cannot be fixed with more tweaks at the HTTP level.
Questa è una delle caratteristiche distintive di SCTP (multistreaming), puoi avere più stream indipendenti nella stessa associazione SCTP e ogni stream non blocca gli altri.
Vedi SSH su SCTP - Ottimizzazione di un multicanale Protocollo adattandolo a SCTP per l'effetto dell'utilizzo di SCTP al fine di evitare il blocco HOL cross-channel in SSH:
SCTP only preserves the order of the messages within a single stream to mitigate an effect known as head-of-line blocking. If a message is lost, the subsequent messages have to be delayed until the lost one is retransmitted to preserve the order. Since only messages of the same stream have to be delayed, the number of affected messages after a loss is reduced.
[...]
By mapping the channels of SSH onto SCTP’s streams, the benefit of multi-streaming is made available to SSH, which is the mitigation of head-of-line blocking.
SCTP non è necessariamente facile da implementare (a causa della disponibilità del sistema operativo, dell'interazione della casella centrale, ecc.). Una possibilità è di implementarlo su UDP nello spazio utente .
Un altro esempio è il protocollo sperimentale QUIC utilizzato per multiplexing HTTP su UDP (perché multiplexing di più stream su TCP come HTTP / 2 ha problemi di blocco HOL ):
QUIC is a new transport which reduces latency compared to that of TCP. On the surface, QUIC is very similar to TCP+TLS+HTTP/2 implemented on UDP.
[...]
Multiplexing without head of line blocking
Protocollo QUIC di Google: lo spostamento del web da TCP a UDP presenta una buona panoramica dei blocchi QUIC e HOL quando si multiplexano i canali su TCP.
Una recente presentazione afferma che HTTP su QUIC migliora la latenza ma il miglioramento del blocco HOL è un "vantaggio minore":
0-RTT, Over 50% of the latency improvement
[…]
Fewer timeout based retransmissions improve tail latency […]
Other, smaller benefits, e.g. head of line blocking
Si noti che mentre il QUIC è descritto come "molto simile a TCP + TLS + HTTP / 2 implementato su UDP" è in realtà un trasporto generico che può essere utilizzato indipendentemente da HTTP / 2 e potrebbe soddisfare le tue esigenze.
Direi che devi leggere la Guida ZeroMQ , i modelli che fornisce con i motivi e gli svantaggi sono essenziali lettura.
Altrimenti, non c'è alcun problema con la disconnessione del canale di rete dall'erogazione dei dati dell'applicazione. Dovrai assumere il muxing e il demuxing dei pacchetti di dati inviati (e ti consiglierei un'architettura basata su pacchetti qui, non lo streaming dei dati in un flusso continuo) e il buffering di essi su ciascuna estremità.
Diversamente, ci dovrebbe essere un minimo impatto, potresti aver bisogno di più memoria, ma solo di poco, per tamponare i dati, e un po 'più di CPU man mano che gestisci più codice per bloccare e analizzare i pacchetti, ma niente di significativo. (a meno che tu non stia scrivendo qualcosa di specialista che richiede un grande throughput e le prestazioni sono fondamentali).
Sì, ho creato un sistema di database client-server utilizzando proprio questo principio.
I canali multiplati su una connessione TCP ciascuno inviano pacchetti di dati, che vengono quindi divisi per i rispettivi destinatari all'altra estremità.
L'hogging della connessione da parte di un canale garrulo viene eseguito dal mittente della connessione TCP facendo la selezione round-robin di quale pacchetto trasmettere tra i canali che hanno dati pronti per l'invio.
Per gestire il caso di un canale che decide di inviare un pacchetto da 1 GB e bloccare tutti gli altri, il mittente può scegliere di dividere un pacchetto in blocchi e inviare solo un blocco prima di dare un altro canale a turno. Alla fine del ricevimento il riassemblaggio di blocchi in un pacchetto viene eseguito prima che il destinatario veda il pacchetto.
Leggi altre domande sui tag networking protocol tcp