[Linux Apps] Quicssh : booster vos connexions SSH

[Raccoon]

La version lorraine est une des meilleure.
Pour faire de l’administration serveur j’imagine qu’il n’y a aucune différence avec Putty mais dans les de transferts importants de données on a des chiffres de comparaison ? Il ne fonctionne qu’en udp ?

[Violence]

Nope pas de chiffres sous la main @Raccoon
Mais le protocole Quick semble avoir fait ses preuves.

QUIC est un protocole expérimental, créé par le moteur de recherche Google et présenté au public en 2013. Le nom signifie « Quick UDP Internet Connections » (connexions Internet UDP rapides), car il permet l’envoi rapide de paquets simples via le protocole UDP (User Datagram Protocol) sans connexion. La raison du développement de QUIC était le désir de fournir une alternative aux solutions de sécurité TCP, HTTP/2 et TLS/SSL en développant la même protection mais avec un délai de connexion et de transport réduit, et en permettant des connexions de multiplexage.

https://www.ionos.fr/digitalguide/hebergement/aspects-techniques/quic/#:~:text=QUIC est un protocole expérimental,User Datagram Protocol

[Ancien 001]

@Violence a dit dans [Linux Apps] Quicssh : booster vos connexions SSH :

@Snoubi a dit dans [Linux Apps] Quicssh : booster vos connexions SSH :

sinon ya putty non c’est du même accabi ? Merci pour le post

Euhh c’est du troll ou une vraie question?
Parce que bon…

parce que bon quoi c’est une question ya que des réponse troll j’ai l’impression

[Violence]

Sorry, mais parce que la réponse est dans l’article.

Pour ceux qui ne le savent pas, QUIC est un protocole de transport

Tout comme SSH.
Putty n’est qu’une application et non un protocole, donc elle ne peut être du même acabit.

[Ancien 001]

bah c’est une appli github non ?

[michmich]

@Snoubi on te l’a fait pas à toi.

[Aerya]

@Snoubi

La question est de savoir si un client SSH qui gère QUIC existe sur Windows.

L’échange des données sur Internet se fait via des protocoles de communication qui sont regroupés dans des groupes : TPC/IP et OSI. Chacun ont leurs avantages et inconvénients : https://www.pierre-giraud.com/http-reseau-securite-cours/modele-reseau-osi-tcp-ip/

Quand tu te connectes en SSH, de manière simple comme on le fait tous via un Terminal ou un client dédié, tu utilises TCP avec la surcouche TLS de sécurité. Même principe quand tu navigues sur Internet sur des sites httpS.

(en gros) Le modèle QUIC est plus léger que TCP+TLS, il est donc plus rapide : https://blog.chromium.org/2015/04/a-quic-update-on-googles-experimental.html
Et la rapidité, la plus faible latence, est juste indispensable de nos jours pour toutes les communications réseau. Le modèle actuel TCP+TLS, implémenté sur tous les appareils (serveurs, routeurs etc) ne peut pas évoluer lui-même, il fallait en créer un autre.

QUIC passe par UDP pour info. Et pour ceux qui veulent en savoir un peu plus je vous recommande de chercher http/3.

[Ancien 001]

Merci pour la brève explication Aerya

[michmich]

Pour les monos langage (dans mon genre )

https://www.fasterize.com/fr/protocole-http3-changements-http1-http2/

[Nymeria]

Avez vous tester ?
Je me demande a quel point c’est plus performant. J’ai du mal a comprendre comment le fait de mettre un proxy accelere le transfert. passera par ssh quoi qu’il arrive

[oudeis]

@Nymeria si j’ai bien compris, c’est au niveau du transport réseau que se font les gains et non pas au niveau des ordinateurs.

QUIC optimise le transfert des données, car les protocoles TCP+TLS sont assez lents.

Ce qui dérangait au départ, c’étatit que c’était un truc Google… Mais, maintenant, comme Quic est défini dans le RFC9000, il est implémentable par n’importe qui - sans avoir besoin de l’aval de (l’orgre Google.

[Rapace]

j’aurais une question (bête, sûrement…) ; quelqu’un qui utilise SSH sans quic peut-il tout de même communiquer avec un ordinateur distant fonctionnant sous le protocole quic ? Merci de m’éclairer, car ça me semble un peu flou cette histoire…

[oudeis]

@Rapace malheureusement je n’ai pas encore pu tester… mais en lisant les docs de “moul/quicssh” la connection quic se fait sur des ports différents de ceux de ssh (normalement 22). Donc, oui en utilisant un client ssh “normal”, ce dernier va se connecter directement au port 22 du serveur distant sans passer par proxy-quic (côté serveur).

pour utiliser le proxy quicssh, un client ssh se connecte localement sur le port du proxy-quic (côté client) et c’est ce dernier qui va se connecter au proxy-quic (côté serveur). Ensuite ce dernier va se connecter “normalement” au ssh port 22

C’est ce que j’ai compris des docs… si qqn comprend mieux ou peux expliquer plus facilement - je suis preneur !

PS: les dessins du premeir post sont clairs

[duJambon]

Désolé pour le HS, je ne peux pas résister à relever le “moule/quiche” comme nom de protocole…