Comment les protocoles FTP, FTPS, SFTP et SCP se comparent-ils en termes de taux de transfert et comment puis-je les comparer par des tests ?
Si vous disposez d'un réseau étendu rapide, vous constaterez que sftp y scp sont à peu près à la même vitesse, ce qui est lent. Ils souffrent tous deux de problèmes de performance dans l'openssh sous-jacent. Avec le matériel moderne, cela n'est pas dû à la surcharge de cryptage, mais plutôt à des problèmes avec l'implémentation d'openssh - il implémente son propre mécanisme de fenêtrage interne qui s'effondre sur les connexions rapides.
Ces problèmes sont plus évidents sur les connexions longue distance (latence plus élevée), mais j'ai constaté des lenteurs même sur les réseaux locaux.
Ceux-ci sont bien documentés, et des correctifs sont disponibles pour corriger le problème. Parcheando l'une ou l'autre extrémité de la connexion peut aider ; idéalement, vous devriez patcher les deux extrémités. Pour plus d'informations et les correctifs, voir SSH haute performance au Pittsburgh Supercomputer Center.
Par ailleurs, la surcharge de cryptage peut également devenir un problème, une fois le problème du fenêtrage résolu. Les patchs ont des corrections pour cela aussi.
Entre-temps, vous constaterez que ftp est terriblement peu sûr ; il envoie les mots de passe en clair.
ftps Je pense qu'il enveloppe le protocole ftp en SSL. Il est probablement plus rapide que le SFTP/SCP non corrigé.
Une dernière remarque : d'après mon expérience, le client WinSCP est (du moins parfois) terriblement 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 scp'ing depuis Windows, et que cela semble lent, essayez un autre client. Même avec un serveur openssh non patché, vous pouvez faire beaucoup, beaucoup mieux avec un autre client. Je ne sais pas quels sont les bons clients, malheureusement, à part probablement les clients ordinaires. pscp de Putty.
Enfin. Quelqu'un qui sait de quoi il parle. Oui, FTPS est fondamentalement FTP dans le SSL. SFTP/SCP sera toujours plus lent que lorsque vous utilisez FTP.
Avez-vous une idée de la raison pour laquelle j'obtiens 300 kb/s avec scp alors que j'obtiens environ 10 Mb/s (presque la vitesse maximale) avec sftp ? Cela ne semble pas être "à peu près la même vitesse". Il s'agit d'un réseau Ethernet de 100 Mbps.
A mon avis, votre scp est une implémentation défectueuse (par exemple WinSCP), mais votre sftp ne l'est pas. Même s'ils sont dans la même interface graphique, ils peuvent être différents à l'intérieur.
En général, les performances de tous les protocoles sont à peu près les mêmes. Il est plus probable que vous soyez limité par la vitesse de votre réseau ou de votre disque que par le protocole.
Les anciennes versions d'OpenSSH (SFTP/SCP) utilisaient une taille de fenêtre fixe qui limite la vitesse sur les réseaux à forte latence (par exemple transatlantique). Il existe un patch pour corriger ce problème appelé HPN (High performance networking) et il est inclus dans la plupart des installations modernes d'OpenSSH.
Si vous disposez d'une liaison LAN gigabit ou plus rapide et d'un processeur plus lent, SFTP/SCP peut se heurter à un goulot d'étranglement. Vous pourrez le constater car le processus ssh/scp/sftp utilisera 100 % du processeur de l'hôte émetteur ou récepteur. Si vous utilisez une version plus récente d'OpenSSH (6.4+), vous pouvez activer une version threadée du chiffrement AES qui sera capable d'utiliser plus d'un cœur pour gérer le chiffrement et sera moins susceptible d'être limité par le CPU plutôt que par le disque ou la bande passante du réseau.
Si vous contrôlez à la fois le côté émission et le côté réception, OpenSSH 6+ dispose également d'un mode optionnel 'NONECIPHER'. Ce mode utilise le chiffrement normal, les clés, etc. pour se connecter à la machine distante, mais passe ensuite à une connexion non chiffrée pour la copie de fichiers proprement dite. Cela permet de supprimer la surcharge du processeur. Il y a des sauvegardes intégrées dans le NONECIPHER qui vous empêchent d'obtenir un Shell qui n'est pas crypté.
En fin de compte, le protocole ne devrait pas être la limitation de la vitesse, bien que les anciennes versions de ssh aient des problèmes avec les liaisons à forte latence.
Il est bon de savoir que les correctifs sont maintenant installés par défaut, bien qu'il semble que redhat ait explicitement décidé de ne pas le faire ( access.redhat.com/site/solutions/53215 ). Notez également que la latence transatlantique n'est pas si importante que ça. Rtts ping actuels : umich -> stanford (californie) : 89ms. umich -> cambridge (uk) : 134ms. De plus, la combinaison de la latence et de la bande passante n'est-elle pas à l'origine du problème ? Ainsi, des liens à faible latence mais à bande passante plus élevée peuvent toujours poser des problèmes.
Sur la base de la surcharge de cryptage, je dirais que le protocole FTP simple 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 offre la sécurité dont vous avez besoin, puis je me préoccuperais du débit.
Ceci é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, installez un serveur sur votre réseau. Si l'utilisation finale se fait sur Internet, testez à partir d'un hôte externe.
Comme toujours, c'est Google qui détient les réponses,
FTP v/s SFTP v/s FTPS
Qui dit FTP > FTPS > SFTP
Le FTP semble également être plus rapide que le 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 machine de votre réseau, puis d'effectuer un transfert de fichiers typique et de voir combien de temps cela prend pour les deux.
Ah, je vois que vous avez tiré cela de l'article de eHow. eHow a tort. Les deux protocoles ont été conçus pour être utilisés sur Internet. L'article comporte plusieurs autres erreurs ; l'auteur ne sait manifestement pas de quoi il/elle parle.
SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.
3 votes
La vitesse n'est pas la principale différence entre FTP et les autres.
10 votes
Je ne sais pas pourquoi ce sujet 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 la bande passante de l'ensemble du chemin de connexion ?
0 votes
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 utilisant SFTP sans sacrifier la sécurité. Il peut même utiliser plusieurs threads pour un seul gros fichier.