J'ai besoin de plusieurs canaux duplex entre deux hôtes. Il existe un certain nombre d'avantages à établir une seule connexion TCP. Mais je doute que le multiplexage pose des problèmes inévitables. Est-ce que cela nuira aux performances ou augmentera considérablement la latence? Et qu'en est-il de l'utilisation de la mémoire et de l'utilisation du processeur? Y a-t-il une suggestion ou une mise en garde que vous aimeriez faire?
Réponses:
TLDR: L'inconvénient majeur que vous pourriez remarquer lors du multiplexage de plusieurs canaux au-dessus de TCP (si vous le faites correctement) est une latence accrue en raison du blocage en tête de ligne entre les canaux.
Corollaire: si vous ne vous souciez pas de la latence, ça devrait aller.
D'autre part, l' utilisation d'une seule connexion TCP «signifie moins de concurrence avec d'autres flux et des connexions à plus longue durée de vie, ce qui à son tour conduit à une meilleure utilisation de la capacité de réseau disponible» .
Si vous multiplexez plusieurs canaux au-dessus du même flux TCP, les canaux peuvent souffrir d'un blocage en tête de ligne :
Le blocage en tête de ligne (HOL) peut se produire lorsque les protocoles de transport offrent un service ordonné ou partiel: si des segments sont perdus, les messages suivants doivent attendre la retransmission réussie dans la file d'attente du récepteur et sont donc retardés.
Lorsque vous multiplexez plusieurs flux au-dessus de TCP, vous obtenez HOL entre les canaux .
Si le canal A a rempli le tampon d'envoi TCP, vous devrez attendre avant que toutes ces données ne soient reçues avant que toute nouvelle donnée du canal B puisse être effectivement transmise à la couche d'application distante.
Voir "Multiplexage au-dessus de TCP" pour plus de détails sur les canaux de multiplexage au-dessus de TCP et la discussion sur les hackernews .
Un exemple typique de ceci est SSH. SSH peut multiplexer plusieurs canaux (voir ControlMaster, ControlPathet ControlPersistOpenSSH). Son utilisation réduit le coût d'initialisation d'une nouvelle session SSH (latence initiale) mais un transfert lourd sur un canal augmente généralement la latence / interactivité des autres (ce qui ne se produit pas si vous utilisez plusieurs flux TCP): si vous utilisez une interface interactive sessions et commencer à déclencher un transfert de fichiers lourd sur le même canal, votre session commencera à devenir beaucoup moins interactive.
HTTP / 2 utilise le multiplexage des requêtes / réponses sur TCP afin de corriger le blocage HOL. Cette fonctionnalité est annoncée dans de nombreux articles et articles sur HTTP / 2. La RFC HTTP / 2 affirme:
HTTP / 1.1 a ajouté le pipelining des demandes, mais cela ne traite que partiellement la concurrence des demandes et souffre toujours d'un blocage en tête de ligne.
[...]
Le protocole résultant est plus convivial pour le réseau car moins de connexions TCP peuvent être utilisées par rapport à HTTP / 1.x. Cela signifie moins de concurrence avec d'autres flux et des connexions à durée de vie plus longue, ce qui à son tour conduit à une meilleure utilisation de la capacité de réseau disponible.
Cependant, ce qui n'est pas discuté, c'est que le blocage HOL n'est pas entièrement résolu. HTTP / 2 sur TCP souffre toujours ) du blocage HOL au niveau TCP .
Ceci est discuté dans cet article LWN sur QUIC:
HTTP / 2 a été conçu pour résoudre ce problème en utilisant plusieurs "flux" intégrés dans une seule connexion . [...] cela crée un nouveau problème: la perte d'un seul paquet bloquera la transmission de tous les flux à la fois, créant de nouveaux problèmes de latence. Cette variante du problème de blocage de tête de ligne est intégrée à TCP lui - même et ne peut pas être corrigée avec plus de réglages au niveau HTTP.
C'est l'une des caractéristiques distinctives de SCTP (multiflux), vous pouvez avoir plusieurs flux indépendants dans la même association SCTP et chaque flux ne bloque pas les autres.
Voir SSH sur SCTP - Optimisation d'un protocole multicanal en l'adaptant à SCTP pour connaître l'effet de l'utilisation de SCTP afin d'éviter le blocage HOL entre canaux dans SSH:
SCTP conserve uniquement l'ordre des messages dans un seul flux pour atténuer un effet appelé blocage de tête de ligne. Si un message est perdu, les messages suivants doivent être retardés jusqu'à ce que le message perdu soit retransmis pour conserver l'ordre. Étant donné que seuls les messages du même flux doivent être retardés, le nombre de messages affectés après une perte est réduit.
[...]
En mappant les canaux de SSH sur les flux de SCTP, l'avantage du multi-streaming est rendu disponible pour SSH, qui est l' atténuation du blocage en tête de ligne .
SCTP n'est pas nécessairement facile à déployer (en raison de la disponibilité du système d'exploitation, de l'interaction avec le boîtier de médiation, etc.). Une possibilité est de l'implémenter sur UDP dans l'espace utilisateur .
Un autre exemple est le protocole expérimental QUIC utilisé pour multiplexer HTTP sur UDP (car le multiplexage de plusieurs flux au-dessus de TCP comme HTTP / 2 souffre du blocage HOL ):
QUIC est un nouveau transport qui réduit la latence par rapport à celui de TCP. En surface, QUIC est très similaire à TCP + TLS + HTTP / 2 implémenté sur UDP.
[...]
Multiplexage sans blocage de tête de ligne
Protocole QUIC de Google: déplacer le Web de TCP à UDP présente un bon aperçu du blocage QUIC et HOL lors du multiplexage de canaux au-dessus de TCP.
Une présentation récente prétend que HTTP sur QUIC améliore la latence mais que l'amélioration du blocage HOL est un «avantage moindre»:
0-RTT, plus de 50% de l'amélioration de la latence
[…]
Moins de retransmissions basées sur le timeout améliorent la latence de la queue […]
Autres avantages plus petits, par exemple blocage de tête de ligne
Notez que même si QUIC est décrit comme «très similaire à TCP + TLS + HTTP / 2 implémenté sur UDP», il s'agit en fait d' un transport à usage général qui peut être utilisé indépendamment de HTTP / 2 et peut répondre à vos besoins.
Remarque: HTTP / QUIC va être normalisé en HTTP / 3 .
Je dirais que vous devez lire le guide ZeroMQ , les modèles qu'il donne avec les raisons et les inconvénients sont des lectures essentielles.
Mais sinon, il n'y a aucun problème à déconnecter le canal réseau de la livraison des données de votre application. Vous devrez prendre en charge le multiplexage et le démultiplexage des paquets de données envoyés (et je recommanderais une architecture basée sur les paquets ici, pas de streaming de données dans un flux continu) et leur mise en mémoire tampon à chaque extrémité.
Sinon, il devrait y avoir peu d'impact, vous aurez peut-être besoin de plus de mémoire - mais seulement légèrement - pour mettre en mémoire tampon les données, et un peu plus de CPU car vous manipulez plus de code pour verrouiller et analyser les paquets, mais rien de significatif. (sauf si vous écrivez quelque chose de spécialiste qui nécessite un débit important et les performances sont essentielles).
Oui, j'ai construit un système de base de données client-serveur utilisant précisément ce principe.
Les canaux multiplexés sur la connexion TCP unique envoient chacun des paquets de données, qui sont ensuite répartis aux destinataires respectifs à l'autre extrémité.
La suppression de la connexion par un canal bavard est effectuée par l'expéditeur de la connexion TCP en sélectionnant par tour de rôle le paquet à transmettre parmi les canaux dont les données sont prêtes à être envoyées.
Pour gérer le cas d'un canal décidant d'envoyer un paquet de 1 Go et de bloquer tout le monde, l'expéditeur peut choisir de diviser un paquet en morceaux et de n'envoyer qu'un seul morceau avant de donner un tour à un autre canal. À la réception, le réassemblage de morceaux en un paquet est effectué avant que le destinataire ne voie le paquet.