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 inevitabili problemi. Danneggerà le prestazioni o aumenterà significativamente la latenza? E che dire dell'utilizzo della memoria e dell'utilizzo della CPU? C'è qualche suggerimento o avvertimento che vorresti dare?
Risposte:
TLDR: il principale svantaggio che potresti notare quando multiplexing più canali su TCP (se lo fai correttamente) è una latenza aumentata a causa del blocco head-of-line tra i canali.
Corollario: se non ti interessa la latenza, dovresti stare bene.
D'altra parte, utilizzare una singola connessione TCP "significa meno concorrenza con altri flussi e connessioni più durature, il che a sua volta porta a un migliore utilizzo della capacità di rete disponibile" .
Se si multiplexano più canali sullo stesso flusso TCP, i canali potrebbero soffrire di blocco head-of-line :
Il blocco head-of-line (HOL) può verificarsi quando i protocolli di trasporto offrono un servizio ordinato o parziale: Se i segmenti vengono persi, i messaggi successivi devono attendere la corretta ritrasmissione nella coda del ricevitore e sono quindi ritardati.
Quando si eseguono il multiplexing di più stream su TCP, si ottiene HOL tra i canali .
Se il canale A ha riempito il buffer di invio TCP, dovrai attendere prima che tutti questi dati vengano ricevuti prima che qualsiasi nuovo dato del canale B possa essere effettivamente trasmesso al livello dell'applicazione remota.
Vedi "Multiplexing su TCP" per maggiori dettagli sui canali multiplexing su TCP e la discussione su hackernews .
Un tipico esempio di questo è SSH. SSH può multiplex più canali (si veda ControlMaster, ControlPathe ControlPersistin OpenSSH). L'uso 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 un flusso TCP multiplo): se si utilizza un interattivo sessioni e inizia a generare un trasferimento di file pesante sullo stesso canale, la 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 ha aggiunto il pipelining delle richieste, ma questo ha affrontato solo parzialmente la concorrenza delle richieste e soffre ancora del blocco head-of-line.
[...]
Il protocollo risultante è più amichevole con la rete perché è possibile utilizzare un numero inferiore di connessioni TCP rispetto a HTTP / 1.x. Ciò significa una minore concorrenza con altri flussi e connessioni di maggiore durata, che a loro volta portano a un migliore utilizzo della capacità di rete disponibile.
Tuttavia, ciò che non viene discusso è che il blocco HOL non viene risolto del tutto. HTTP / 2 su TCP soffre ancora ) del blocco HOL a livello TCP .
Questo è discusso in questo articolo LWN su QUIC:
HTTP / 2 è stato progettato per risolvere questo problema utilizzando più "stream" integrati in una singola connessione . [...] crea un nuovo problema: la perdita di un singolo pacchetto interromperà la trasmissione di tutti i flussi contemporaneamente, creando nuovi problemi di latenza. Questa variante del problema del blocco head-of-line è integrata nel TCP stesso e non può essere risolta con ulteriori modifiche a livello HTTP.
Questa è una delle caratteristiche distintive di SCTP (multistreaming), puoi avere più flussi indipendenti nella stessa associazione SCTP e ogni flusso non blocca gli altri.
Vedi SSH su SCTP - Ottimizzare un protocollo multicanale adattandolo a SCTP per l'effetto dell'uso di SCTP al fine di evitare il blocco HOL tra canali in SSH:
SCTP mantiene l'ordine dei messaggi all'interno di un singolo flusso per mitigare un effetto noto come blocco head-of-line. Se un messaggio viene perso, i messaggi successivi devono essere ritardati fino a quando quello perso viene ritrasmesso per preservare l'ordine. Poiché è necessario ritardare solo i messaggi dello stesso flusso, il numero di messaggi interessati dopo una perdita è ridotto.
[...]
Mappando i canali di SSH sui flussi di SCTP, il vantaggio del multi-streaming è reso disponibile a SSH, che è la mitigazione del blocco head-of-line .
SCTP non è necessariamente facile da distribuire (a causa della disponibilità del sistema operativo, dell'interazione della middlebox, ecc.). Una possibilità è implementarla su UDP nello spazio utenti .
Un altro esempio è il protocollo sperimentale QUIC utilizzato per il multiplexing HTTP su UDP (perché il multiplexing di più flussi su TCP in quanto HTTP / 2 soffre di blocco HOL ):
QUIC è un nuovo trasporto che riduce la latenza rispetto a quella del TCP. A prima vista, QUIC è molto simile a TCP + TLS + HTTP / 2 implementato su UDP.
[...]
Multiplexing senza blocco della linea di testa
Protocollo QUIC di Google: lo spostamento del Web da TCP a UDP presenta una buona panoramica del blocco QUIC e HOL quando si esegue il multiplexing dei canali su TCP.
Una recente presentazione afferma che HTTP su QUIC migliora la latenza ma che il miglioramento del blocco HOL è un "vantaggio minore":
0-RTT, oltre il 50% del miglioramento della latenza
[...]
Meno ritrasmissioni basate sul timeout migliorano la latenza della coda […]
Altri vantaggi minori, ad esempio il blocco del capo linea
Si noti che mentre 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.
Nota: HTTP / QUIC verrà standardizzato come HTTP / 3 .
Direi che devi leggere la Guida di ZeroMQ , i modelli che fornisce con le ragioni e gli svantaggi sono letture essenziali.
Altrimenti, non c'è alcun problema con la disconnessione del canale di rete dalla consegna dei dati dell'applicazione. Dovrai affrontare il muxing e il demuxing dei pacchetti di dati inviati (e consiglierei un'architettura basata su pacchetti qui, non lo streaming di dati in un flusso continuo) e il loro buffering su ciascuna estremità.
Altrimenti dovrebbe esserci un piccolo impatto, potresti aver bisogno di più memoria, ma solo leggermente, per bufferizzare i dati e un po 'più di CPU mentre stai gestendo più codice per bloccare e analizzare i pacchetti, ma nulla di significativo. (a meno che non si stia scrivendo qualcosa di specialista che richiede un throughput elevato e le prestazioni sono fondamentali).
Sì, ho creato un sistema di database client-server usando esattamente questo principio.
I canali multiplexati su una connessione TCP inviano ciascuno pacchetti di dati, che vengono poi suddivisi ai rispettivi destinatari all'altra estremità.
La registrazione della connessione da parte di un canale appariscente viene eseguita dal mittente della connessione TCP facendo una selezione round-robin di quale pacchetto trasmettere tra i canali che hanno dati pronti per l'invio.
Per gestire il caso in cui un canale decida 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 a un altro canale un turno. All'estremità ricevente, il riassemblaggio di blocchi in un pacchetto viene eseguito prima che il destinatario veda il pacchetto.