FTP/FTPS/SFTP/SCP - Comparaison de vitesse

Si vous disposez d'un réseau étendu rapide, vous constaterez que sftp et scp ont à peu près la même vitesse, qui est lente. Ils souffrent tous les deux de problèmes de performance dans l'implémentation sous-jacente de l'openssh. Avec du matériel moderne, ce n'est pas dû aux surcharges d'encryption, mais plutôt aux problèmes de l'implémentation de l'openssh - il implémente son propre mécanisme de fenêtrage interne qui se dégrade sur les connexions rapides.

Ces problèmes deviennent plus évidents sur des connexions longue distance (latence plus élevée), mais j'ai aussi constaté une lenteur même sur des LAN.

Ces problèmes sont bien documentés et des correctifs sont disponibles pour résoudre le problème. Appliquer un correctif à une extrémité de la connexion peut aider; idéalement, vous devriez patcher les deux extrémités. Pour plus d'informations et les correctifs, consultez High Performance SSH au Pittsburgh Supercomputer Center.

En passant, la surcharge d'encryption peut aussi devenir un problème, une fois que le problème de fenêtrage est résolu. Les correctifs proposent également des solutions pour cela.

En attendant, vous constaterez que ftp est désespérément peu sécurisé car il envoie des mots de passe en clair.

ftps enveloppe, je pense, le protocole ftp dans SSL. C'est probablement plus rapide que SFTP/SCP non corrigés.

Une dernière remarque: dans 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 transférez des fichiers avec scp depuis Windows et que cela semble lent, essayez un autre client. Même avec un serveur openssh non corrigé, vous pouvez faire bien mieux avec un autre client. Je ne sais pas quels sont les bons clients, malheureusement, à part probablement le simple pscp de Putty.

En général, tous les protocoles fonctionneront à peu près de la même manière. Vous risquez davantage d'être 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 limitait la vitesse sur des réseaux à forte latence (comme transatlantiques). Il existe un ensemble de correctifs pour résoudre ce problème appelé HPN (High Performance Networking) et il est inclus dans la plupart des installations modernes d'OpenSSH.

Si vous rencontrez une situation telle qu'une liaison LAN gigabit ou plus rapide et un CPU plus lent, alors SFTP/SCP peut rencontrer un goulot d'étranglement. Vous pourrez le voir car le processus ssh/scp/sftp utilisera 100% du CPU sur 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 pourra 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é émetteur et le côté récepteur, OpenSSH 6+ propose également un mode optionnel 'NONECIPHER'. Celui-ci utilise le chiffrement/clés habituels etc. pour se connecter à la machine distante, puis passe à une connexion non chiffrée pour la copie réelle des fichiers. Cela éliminera cette charge CPU. Des dispositifs de sécurité sont intégrés dans le NONECIPHER pour empêcher l'accès à un shell non chiffré.

En fin de compte, le protocole ne devrait pas être la limite de la vitesse, bien que les anciennes versions de ssh aient des difficultés avec les liens à forte latence.

Basé sur le surcoût de chiffrement, je dirais que le FTP simple a probablement des performances légèrement meilleures que les autres protocoles, mais c'est probablement négligeable. Je choisirais d'abord le protocole qui fournit la sécurité dont vous avez besoin, puis je m'inquiéterais du débit.

Cela dit, vous devrez mettre en place un test pour trouver les chiffres réels. 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 via internet, testez à partir d'un hôte externe.

Comme toujours, Google détient les réponses,
FTP v/s SFTP v/s FTPS
Ce 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 recommande d'essayer par vous-même pour voir.
Donc configurez simplement SCP et FTP sur n'importe quelle boîte aléatoire de votre réseau, puis lancez un transfert de fichier typique et voyez combien de temps cela prend sur les deux