La vitesse n'est pas la différence importante entre FTP et les autres.
ceejayoz
2
Je ne sais pas pourquoi cela a été voté hors sujet. Il est certainement très pertinent pour mon travail en tant qu'administrateur système professionnel - pourquoi les transferts de fichiers n'utilisaient-ils pas près de la bande passante de l'ensemble du chemin de connexion?
Dan Pritts
Vous pouvez compenser la différence de vitesse de SFTP en utilisant plusieurs connexions TCP pilotées par LFTP et le sous-système miroir en utilisant SFTP sans sacrifier la sécurité. Il peut même utiliser plusieurs threads pour un seul gros fichier.
Aaron
Réponses:
29
Si vous avez un réseau étendu rapide, vous le trouverez sftpetscp êtes à peu près à la même vitesse, ce qui est lent. Ils souffrent tous les deux de problèmes de performances dans l'opensh sous-jacent. Avec le matériel moderne, cela n'est pas dû à une surcharge de chiffrement, mais plutôt à des problèmes avec la mise en œuvre openssh - il implémente son propre mécanisme de fenêtrage interne qui tombe en panne sur les connexions rapides.
Ces problèmes deviennent plus évidents sur les connexions longue distance (latence plus élevée), mais j'ai connu une lenteur même sur les réseaux locaux.
Ceux-ci sont bien documentés et des correctifs sont disponibles pour résoudre le problème. Corriger l'une ou l'autre extrémité de la connexion peut aider; idéalement, vous patcheriez aux deux extrémités. Pour plus d'informations et les correctifs, voir High Performance SSH au Pittsburgh Supercomputer Center.
BTW, la surcharge de chiffrement peut également devenir un problème, une fois le problème de fenêtrage résolu. Les correctifs ont également des correctifs.
En attendant, vous constaterez que ftpc'est terriblement précaire; il envoie des mots de passe en texte brut.
ftpsJe pense que le protocole ftp est enveloppé dans SSL. c'est probablement plus rapide que SFTP / SCP non corrigé.
Une dernière remarque: d'après mon expérience, le client WinSCP est (au moins parfois) douloureusement lent. Je ne sais pas pourquoi, mais d'après leur FAQ, je ne suis pas la seule personne à avoir eu ce problème. Donc, si vous utilisez Windows et que cela semble lent, essayez un autre client. Même avec un serveur openssh non corrigé, vous pouvez faire beaucoup, beaucoup mieux avec un client différent. Je ne sais pas quels sont les bons clients, malheureusement.
Finalement. Quelqu'un qui sait de quoi ils parlent. Oui, FTPS est essentiellement FTP dans le SSL. SFTP / SCP sera toujours plus lent que lors de l'utilisation de FTP
Jason
Avez-vous une idée pourquoi j'obtiens 300 kb / s avec scp tout en obtenant environ 10 Mb / s (vitesse presque max) avec sftp? Cela ne semble pas être "à peu près à la même vitesse". C'est plus de 100 Mbps Ethernet.
graywolf
Meilleure supposition, votre scp est une implémentation défectueuse (par exemple WinSCP), mais pas votre sftp. Même s'ils sont dans le même wrapper GUI, ils peuvent être différents à l'intérieur.
Dan Pritts
Dan, une idée pourquoi ce correctif SSH n'est pas appliqué à l'OpenSSH principal? Il est clair que c'est 1 ~ 2 ordres de grandeur mieux (> 10x même sur un LAN 100Mbps) alors pourquoi n'est-ce pas la nouvelle norme OpenSSH? Comment pouvons-nous faire en sorte?
Gabriel Staples
D'après ce que je comprends, PSC a soumis les correctifs aux gens openbsd (qui écrivent openssh). Ils n'étaient pas intéressés. J'ai entendu de vagues déclarations selon lesquelles aucune des personnes openbsd n'avait de connexions à large bande passante et elles n'ont remarqué aucun problème, et / ou croient nécessairement qu'il y avait un vrai problème. C'était il y a plusieurs années, et c'est du ouï-dire, donc je ne peux pas garantir sa précision.
Dan Pritts
4
En général, tous les protocoles fonctionnent à peu près de la même manière. Vous êtes plus susceptible d'être limité par la vitesse de votre réseau ou disque que par le protocole.
Les versions plus anciennes d'OpenSSH (SFTP / SCP) utilisaient une taille de fenêtre fixe qui limiterait la vitesse sur les réseaux à latence élevée (par exemple transatlantique). Il existe un ensemble de correctifs pour résoudre ce problème appelé HPN (réseau haute performance) et il est inclus dans la plupart des installations modernes d'OpenSSH.
Si vous êtes confronté à une situation telle qu'une liaison LAN gigabit ou plus rapide et un processeur plus lent, SFTP / SCP peut se heurter à un goulot d'étranglement. Vous pourrez le dire car le processus ssh / scp / sftp utilisera 100% de cpu sur l'hébergement d'envoi ou de réception. Si vous utilisez une version plus récente d'OpenSSH (6.4+), vous pouvez activer une version filetée du chiffrement AES qui pourra utiliser plus d'un cœur pour gérer le chiffrement et sera moins susceptible d'être limitée par le CPU plutôt que par le disque ou la bande passante réseau.
Si vous contrôlez à la fois le côté émetteur et le côté récepteur, OpenSSH 6+ dispose également d'un mode 'NONECIPHER' en option. Celui-ci utilise le cryptage / clés standard, etc. pour se connecter à la machine distante, mais passe ensuite à une connexion non cryptée pour la copie du fichier réel. Cela supprimera cette surcharge du processeur. Il existe des protections intégrées au NONECIPHER qui vous empêchent d'obtenir un shell qui n'est pas chiffré.
En fin de compte, le protocole ne devrait pas limiter la vitesse, bien que les anciennes versions de ssh aient des problèmes avec les liaisons à latence élevée.
Bon à savoir que les correctifs par défaut sont désormais d'avoir les correctifs installés, bien qu'il semble que redhat l'ait explicitement décidé ( access.redhat.com/site/solutions/53215 ). Notez également que la latence transatlantique n'est pas vraiment beaucoup. Courants de ping actuels: umich -> stanford (californie): 89ms. umich -> cambridge (royaume-uni): 134 ms. De plus, la combinaison de latence et de bande passante n'est-elle pas à l'origine du problème? donc une latence plus faible mais des liaisons à bande passante plus élevée peuvent toujours avoir des problèmes.
Dan Pritts
3
Sur la base de la surcharge de chiffrement, je dirais que le FTP ordinaire a probablement des performances légèrement meilleures que les autres protocoles, mais c'est probablement négligeable. J'utiliserais d'abord le protocole qui fournit la sécurité dont vous avez besoin, puis je m'inquiète du débit.
Cela étant dit, vous devrez mettre en place un test pour trouver les vrais chiffres. Tout ce qui précède n'est que mon opinion. Si vous testez les performances localement, configurez un serveur sur votre réseau. Si l'utilisation finale se fera sur Internet, testez à partir d'un hôte externe.
Les frais généraux de performance sont des ordres de grandeur, pas légers. Plus proche de 10x que 2x plus lent. J'étais moi-même surpris.
Gomibushi
2
Comme toujours, Google détient les réponses, FTP v / s SFTP v / s FTPS
qui dit FTP> FTPS> SFTP
FTP semble également être plus rapide que SCP dans le test de quelqu'un d'autre ( http://www.lysesoft.com/support/forums /viewtopic.php?f=5&t=542 ) mais je vous recommande de l'essayer par vous-même pour voir.
Il suffit donc de configurer SCP et FTP sur n'importe quelle boîte aléatoire de votre réseau, puis d'exécuter un transfert de fichier typique et de voir combien de temps cela prend à la fois
pourquoi dites-vous que FTP est un protocole Internet et SCP pour le LAN?
Dan Pritts
5
Ah, je vois que vous avez obtenu cela de l'article eHow lié. eHow est faux. Les deux protocoles ont été conçus pour être utilisés sur Internet. L'article contient plusieurs autres erreurs; l'écrivain ne sait clairement pas de quoi il parle.
Dan Pritts
Maintenant que j'y pense, vous avez raison, j'aurais probablement dû vérifier.
1
Des sites comme eHow ne savent jamais de quoi ils parlent.
Réponses:
Si vous avez un réseau étendu rapide, vous le trouverez
sftpetscpêtes à peu près à la même vitesse, ce qui est lent. Ils souffrent tous les deux de problèmes de performances dans l'opensh sous-jacent. Avec le matériel moderne, cela n'est pas dû à une surcharge de chiffrement, mais plutôt à des problèmes avec la mise en œuvre openssh - il implémente son propre mécanisme de fenêtrage interne qui tombe en panne sur les connexions rapides.Ces problèmes deviennent plus évidents sur les connexions longue distance (latence plus élevée), mais j'ai connu une lenteur même sur les réseaux locaux.
Ceux-ci sont bien documentés et des correctifs sont disponibles pour résoudre le problème. Corriger l'une ou l'autre extrémité de la connexion peut aider; idéalement, vous patcheriez aux deux extrémités. Pour plus d'informations et les correctifs, voir High Performance SSH au Pittsburgh Supercomputer Center.
BTW, la surcharge de chiffrement peut également devenir un problème, une fois le problème de fenêtrage résolu. Les correctifs ont également des correctifs.
En attendant, vous constaterez que
ftpc'est terriblement précaire; il envoie des mots de passe en texte brut.ftpsJe pense que le protocole ftp est enveloppé dans SSL. c'est probablement plus rapide que SFTP / SCP non corrigé.Une dernière remarque: d'après mon expérience, le client WinSCP est (au moins parfois) douloureusement lent. Je ne sais pas pourquoi, mais d'après leur FAQ, je ne suis pas la seule personne à avoir eu ce problème. Donc, si vous utilisez Windows et que cela semble lent, essayez un autre client. Même avec un serveur openssh non corrigé, vous pouvez faire beaucoup, beaucoup mieux avec un client différent. Je ne sais pas quels sont les bons clients, malheureusement.
la source
En général, tous les protocoles fonctionnent à peu près de la même manière. Vous êtes plus susceptible d'être limité par la vitesse de votre réseau ou disque que par le protocole.
Les versions plus anciennes d'OpenSSH (SFTP / SCP) utilisaient une taille de fenêtre fixe qui limiterait la vitesse sur les réseaux à latence élevée (par exemple transatlantique). Il existe un ensemble de correctifs pour résoudre ce problème appelé HPN (réseau haute performance) et il est inclus dans la plupart des installations modernes d'OpenSSH.
Si vous êtes confronté à une situation telle qu'une liaison LAN gigabit ou plus rapide et un processeur plus lent, SFTP / SCP peut se heurter à un goulot d'étranglement. Vous pourrez le dire car le processus ssh / scp / sftp utilisera 100% de cpu sur l'hébergement d'envoi ou de réception. Si vous utilisez une version plus récente d'OpenSSH (6.4+), vous pouvez activer une version filetée du chiffrement AES qui pourra utiliser plus d'un cœur pour gérer le chiffrement et sera moins susceptible d'être limitée par le CPU plutôt que par le disque ou la bande passante réseau.
Si vous contrôlez à la fois le côté émetteur et le côté récepteur, OpenSSH 6+ dispose également d'un mode 'NONECIPHER' en option. Celui-ci utilise le cryptage / clés standard, etc. pour se connecter à la machine distante, mais passe ensuite à une connexion non cryptée pour la copie du fichier réel. Cela supprimera cette surcharge du processeur. Il existe des protections intégrées au NONECIPHER qui vous empêchent d'obtenir un shell qui n'est pas chiffré.
En fin de compte, le protocole ne devrait pas limiter la vitesse, bien que les anciennes versions de ssh aient des problèmes avec les liaisons à latence élevée.
la source
Sur la base de la surcharge de chiffrement, je dirais que le FTP ordinaire a probablement des performances légèrement meilleures que les autres protocoles, mais c'est probablement négligeable. J'utiliserais d'abord le protocole qui fournit la sécurité dont vous avez besoin, puis je m'inquiète du débit.
Cela étant dit, vous devrez mettre en place un test pour trouver les vrais chiffres. Tout ce qui précède n'est que mon opinion. Si vous testez les performances localement, configurez un serveur sur votre réseau. Si l'utilisation finale se fera sur Internet, testez à partir d'un hôte externe.
la source
Comme toujours, Google détient les réponses,
FTP v / s SFTP v / s FTPS
qui dit FTP> FTPS> SFTP
FTP semble également être plus rapide que SCP dans le test de quelqu'un d'autre ( http://www.lysesoft.com/support/forums /viewtopic.php?f=5&t=542 ) mais je vous recommande de l'essayer par vous-même pour voir.
Il suffit donc de configurer SCP et FTP sur n'importe quelle boîte aléatoire de votre réseau, puis d'exécuter un transfert de fichier typique et de voir combien de temps cela prend à la fois
la source