Je plusse, on s'en rend peu compte depuis son terminal, mais si on utilise programmatiquement le protocole SSH on découvre tout de suite qu'il est déjà multiplexé : une connection SSH transporte autant de "canaux" que l'on souhaite (apparu dans le protocole v2 en 2006).
On peut être très créatif avec ça. Depuis les outils CLI on s'en rend compte par ex. en faisant ssh -L 8080:1.2.3.4:80 -X bob@server : on se retrouve bien avec en parallèle 1/ un flux vers un shell interactif, 2/ un flux TCP forwardé, 3/ le flux X11 TCP forwardé (3 "canaux" pour 1 connection).
Le multiplexage QUIC éviterai le fameux "head-of-line blocking" (en TCP si un paquet est perdu, tous les flux multiplexés au sein de la connection TCP sont concernés/retardés). Mais dans la très vaste majorité des cas SSH est utilisé avec un canal par session (typiquement shell, tunnel, ou forward-only [option -N]). Du coup je doute que ça intéresse grand monde.
[^] # Re: Partage de connexion ssh / multiplexing
Posté par zerodeux (site web personnel) . En réponse au journal SSH3 n’est pas la suite d’SSH. Évalué à 3.
Je plusse, on s'en rend peu compte depuis son terminal, mais si on utilise programmatiquement le protocole SSH on découvre tout de suite qu'il est déjà multiplexé : une connection SSH transporte autant de "canaux" que l'on souhaite (apparu dans le protocole v2 en 2006).
On peut être très créatif avec ça. Depuis les outils CLI on s'en rend compte par ex. en faisant
ssh -L 8080:1.2.3.4:80 -X bob@server: on se retrouve bien avec en parallèle 1/ un flux vers un shell interactif, 2/ un flux TCP forwardé, 3/ le flux X11 TCP forwardé (3 "canaux" pour 1 connection).Le multiplexage QUIC éviterai le fameux "head-of-line blocking" (en TCP si un paquet est perdu, tous les flux multiplexés au sein de la connection TCP sont concernés/retardés). Mais dans la très vaste majorité des cas SSH est utilisé avec un canal par session (typiquement shell, tunnel, ou forward-only [option -N]). Du coup je doute que ça intéresse grand monde.