cbe_cpe Posté(e) le 18 janvier 2007 Partager Posté(e) le 18 janvier 2007 Bonjour, Je souaite récupérer un gros fichier chez un ami. Il veux faire ça sous linux en SSH. Moi qui suis sous windows veut plutôt qu'il copie ça sur le serveur FTP installé sur mon PC. Selon lui le débit serait plus rapide en ssh qu'en FTP. Il n'a pas réussi à m'expliquer pourquoi. J'ai donc fait quelques recherches et tout ce que j'ai trouvé c'est que ssh sécurise une connexion (echange de clé, etc) et crée un Tunnel entre les PC. Mais rien sur les performance sur le transfert de fichiers. Peut etre que le tunnel permet de limiter des échanges entre serveur et client par rapport à une connexion FTP, mais je ne vois pas trop comment. Si il y a une connexion (au sens "réseau" du terme: ouverture, échange avec ACK, cloture...), il y a forcément des échanges de données autre que celle du fichier à transférer. Est ce que ce Tunnel peut limiter ça ? On peut aussi faire le la compression avec SSH, mais c'est aussi le cas en FTP. Une histoire de process peut être ? Si vous pouvez m'éclairer sur le sujet... Merci d'avance. Lien vers le commentaire Partager sur d’autres sites More sharing options...
lorinc Posté(e) le 18 janvier 2007 Partager Posté(e) le 18 janvier 2007 parce qu'il y a un mode compression sur ssh ( -C ). Et puis ssh c'est secure, ce que n'est pas ftp... Lien vers le commentaire Partager sur d’autres sites More sharing options...
cbe_cpe Posté(e) le 18 janvier 2007 Auteur Partager Posté(e) le 18 janvier 2007 parce qu'il y a un mode compression sur ssh ( -C ). Et puis ssh c'est secure, ce que n'est pas ftp... Ok pour la compression mais le coté secure ça protège les données mais ça augmente pas le débit ? Lien vers le commentaire Partager sur d’autres sites More sharing options...
lorinc Posté(e) le 18 janvier 2007 Partager Posté(e) le 18 janvier 2007 non, le fait de cry^W chiffrer (désolé ) n'augmente pas la taille des données (un symbole en entrée donne un symbole en sortie) Lien vers le commentaire Partager sur d’autres sites More sharing options...
tuXXX Posté(e) le 18 janvier 2007 Partager Posté(e) le 18 janvier 2007 Ok pour la compression mais le coté secure ça protège les données mais ça augmente pas le débit ? Non ça chiffre juste. Sous windows t'as WinScp pour copier des fichiers en passant par ssh. C'est très windowsien-friendly. http://winscp.net http://sourceforge.net/projects/winscp/ Lien vers le commentaire Partager sur d’autres sites More sharing options...
cbe_cpe Posté(e) le 18 janvier 2007 Auteur Partager Posté(e) le 18 janvier 2007 Merci Je connaissais déja Putty, je vais voir ce qu'on peut faire avec celui-là. Bon ce qui me rassure c'est que à part une éventuelle compression ça doit pas changer grand chose entre ssh et ftp. Peut etre au niveau de l'utilisation du processeur ? Lien vers le commentaire Partager sur d’autres sites More sharing options...
Sandeman Posté(e) le 19 janvier 2007 Partager Posté(e) le 19 janvier 2007 En termes de perf mon expérience c'est Samba > FTP > SSH vala vala mais bon sur un lien 100 Mb/s on varie entre 88 et 82 Mb/s selon le protocole par contre si l'une des machines est une brouette, SSH va lourdement impacter les perfs (je dépassais pas 4,5 Mb/s sur un lien 10 Mb/s connecté à un P133) Lien vers le commentaire Partager sur d’autres sites More sharing options...
Amour Posté(e) le 19 janvier 2007 Partager Posté(e) le 19 janvier 2007 Pour avoir testé, FTP sur TLS (donc crypté) est beaucoup plus rapide que le SFTP (SSH) Donc on peut avoir de la sécurité et vitesse, via un serveur FTP correctement configuré Lien vers le commentaire Partager sur d’autres sites More sharing options...
16ar Posté(e) le 26 janvier 2007 Partager Posté(e) le 26 janvier 2007 Personnellement, je préfère aussi utiliser ssh/scp que ftp Deja ftp, je trouve que le protocole est un peu merdique... Bon je ne suis pas un pro des protocoles. Mais c'est lourdingue d'avoir 2 ports a ouvrir pour 1 seul service. Et puis moi, a l'époque, quand j'avais mon ftp, j'avais toujours 20 000 soucis de gens qui n'arrivaient pas a se connecter a cause du mode passif ou pas. Bref, tres lourd. Winscp, ca passe tout le temps, c genial. Par contre, la chose lourde coté serveur, c'est qu'il faut un accompte Unix pour pouvoir uploader ou recupérer. C'est pas forcément top, ou alors on fait une ssh prison, mais bon, j'ai pas reussi a en mettre un en place. Donc du coup, j'ai opté pour upload en ssh et recupération en https (avec identification HTTP via un htaccess + htpasswd) Ca marche bien, mais bon, l'url de recupération des fichiers n'est pas chiffrée et peut toujours indiquer à des intermédiaires de quoi il s'agit. Il faut que je vois du coté de mod_rewrite d'apache je pense, mais j'ai pas encore eu le temps. D'ailleurs, si vous avez des réserves face a mon archi, ca m'interesse, comme dit, je ne suis pas un pro des protocole et de la sécu, loin de la. Donc si vous trouvez que c'est faible par endroit, merci de me l'indiquer :) Lien vers le commentaire Partager sur d’autres sites More sharing options...
ggbce Posté(e) le 26 janvier 2007 Partager Posté(e) le 26 janvier 2007 Juste pour ajouter qu'il existe surement une différence de perfomance... mais est-elle lié au protocole lui-même, je ne crois pas. C'est plutôt aux logiciels client et serveur utilisé pour le faire. Sans comparer SSH et FTP, Uniquement entre WU-FTPD et VSFTPD il y a une énorme différence de perfomance. VSFTPD est beaucoup plus rapide (temps de réponse et débit max). Donc j'imagine que c'est le cas entre les autres solutions !!! De plus si tu parles de GROS fichiers, je ferais le choix du FTP en sens du download (et non en upload) pour une simple raison. S'il y a coupure ou erreur de communication et que le téléchargement doit être recommencé, tu peux utiliser un logiciel de gestion des téléchargements sur ton Windows comme FlashGet et recommencer où ça l'a planté. Lien vers le commentaire Partager sur d’autres sites More sharing options...
16ar Posté(e) le 26 janvier 2007 Partager Posté(e) le 26 janvier 2007 De plus si tu parles de GROS fichiers, je ferais le choix du FTP en sens du download (et non en upload) pour une simple raison. S'il y a coupure ou erreur de communication et que le téléchargement doit être recommencé, tu peux utiliser un logiciel de gestion des téléchargements sur ton Windows comme FlashGet et recommencer où ça l'a planté. wget -c https://blbla.com/blabla.fichier Ca fonctionne tres bien pour reprendre les downloads Lien vers le commentaire Partager sur d’autres sites More sharing options...
cbe_cpe Posté(e) le 26 janvier 2007 Auteur Partager Posté(e) le 26 janvier 2007 Juste pour ajouter qu'il existe surement une différence de perfomance... mais est-elle lié au protocole lui-même, je ne crois pas. C'est plutôt aux logiciels client et serveur utilisé pour le faire. C'est bien ce qu'il me semblait Merci pour vos réponse. Du coup j'ai fait autrement. Un autre ami avec serveur NAS et adresse DNS dynamique. Je récupère mon fichier en FTP quand je veux (la journée quand je ne travaille pas sur mon pc ar example). Lien vers le commentaire Partager sur d’autres sites More sharing options...
Messages recommandés
Archivé
Ce sujet est désormais archivé et ne peut plus recevoir de nouvelles réponses.