Pourquoi lorsque je transfère un fichier via SFTP, cela prend plus de temps que FTP?

Je copie manuellement un fichier sur un serveur et le même sur un serveur SFTP. Le fichier est de 140 Mo.

FTP: J’ai un taux de 11Mo / s

SFTP: J’ai un taux d’arrivées de 4,5 Mo / s

Je comprends que le fichier doit être crypté avant d’être envoyé. Est-ce le seul impact sur le transfert de fichiers? (et en réalité ce n’est pas exactement le temps de transfert, mais le temps de cryptage).

Je suis surpris de tels résultats.

    Je suis l’auteur de HPN-SSH et un commentateur m’a demandé d’intervenir. J’aimerais commencer par quelques éléments de base. Tout d’abord, il est important de garder à l’esprit que SSHv2 est un protocole multiplexé – plusieurs canaux sur une seule connexion TCP. En tant que tels, les canaux SSH ignorent essentiellement l’algorithme de contrôle de stream sous-jacent utilisé par TCP. Cela signifie que SSHv2 doit implémenter son propre algorithme de contrôle de stream. La mise en œuvre la plus courante consiste à réimplémenter les fenêtres coulissantes. Cela signifie que la fenêtre coulissante SSH se trouve au-dessus de la fenêtre de glissement TCP. Le résultat final est que la taille effective du tampon de réception est le minimum des tampons de réception des deux fenêtres coulissantes. Stock OpenSSH a une taille maximale de tampon de réception de 2 Mo, mais cela finit par se rapprocher de ~ 1,2 Mo. La plupart des systèmes d’exploitation modernes ont un tampon qui peut croître (en utilisant les tampons de réception à réglage automatique) jusqu’à une taille effective de 4 Mo. Pourquoi est-ce important? Si la taille du tampon de réception est inférieure à celle du produit BDP (Bande passante), vous ne pourrez jamais remplir complètement le tuyau, quelle que soit la vitesse de votre système.

    Ceci est compliqué par le fait que SFTP ajoute une autre couche de contrôle de stream sur les contrôles de stream TCP et SSH. SFTP utilise un concept de messages en attente. Chaque message peut être une commande, un résultat d’une commande ou un stream de données en bloc. Les messages en attente peuvent correspondre à une taille de datagramme spécifique. Donc, vous vous retrouvez avec ce que vous pourriez aussi bien penser à un autre tampon de réception. La taille de ce tampon de réception est la taille du datagramme * maximum des messages en attente (les deux pouvant être définis sur la ligne de commande). La valeur par défaut est 32k * 64 (2Mo). Ainsi, lorsque vous utilisez SFTP, vous devez vous assurer que le tampon de réception TCP, le tampon de réception SSH et le tampon de réception SFTP sont de taille suffisante (sans être trop volumineux ou avec des problèmes de mise en mémoire tampon lors de sessions interactives).

    HPN-SSH résout directement le problème du tampon SSH en disposant d’une taille de mémoire tampon maximale d’environ 16 Mo. Plus important encore, le tampon augmente de manière dynamic à la taille appropriée en interrogeant l’entrée proc pour la taille de la mémoire tampon de la connexion TCP (en perçant essentiellement un trou entre les couches 3 et 4). Cela évite les surcharges dans presque toutes les situations. Dans SFTP, nous augmentons le nombre maximal de requêtes en attente à 256. Au moins, nous devrions le faire – il semblerait que le changement ne se soit pas propagé comme prévu dans le jeu de correctifs 6.3 (bien qu’il soit en 6.2. Je le réparerai bientôt) ). Il n’y a pas de version 6.4 car 6.3 patches proprement contre 6.4 (qui est un correctif de sécurité de 1 ligne de 6.3). Vous pouvez obtenir le patch défini à partir de sourceforge.

    Je sais que cela semble étrange, mais le bon dimensionnement des tampons est le changement le plus important en termes de performances. En dépit de ce que beaucoup de gens pensent, le cryptage n’est pas la source réelle de mauvaises performances dans la plupart des cas. Vous pouvez le prouver vous-même en transférant des données vers des sources de plus en plus éloignées (en termes de RTT). Vous remarquerez que plus le RTT est long, plus le débit est faible. Cela indique clairement qu’il s’agit d’un problème de performance dépendant du RTT.

    Quoi qu’il en soit, avec ce changement, j’ai commencé à voir des améliorations allant jusqu’à 2 ordres de grandeur. Si vous comprenez le protocole TCP, vous comprendrez pourquoi cela a fait une telle différence. Il ne s’agit pas de la taille du datagramme ou du nombre de paquets ou de quelque chose du genre. C’est complet car pour utiliser efficacement le chemin réseau, vous devez disposer d’un tampon de réception égal à la quantité de données pouvant être en transit entre les deux hôtes. Cela signifie également que vous ne verrez aucune amélioration si le chemin n’est pas suffisamment rapide et suffisamment long. Si le BDP est inférieur à 1,2 Mo, HPN-SSH peut ne pas vous être utile.

    Le chiffrement AES-CTR parallélisé améliore les performances des systèmes dotés de plusieurs cœurs si vous avez besoin d’un chiffrement complet de bout en bout. En général, je suggère aux personnes (ou contrôlent à la fois le serveur et le client) d’utiliser le commutateur de chiffrement NONE (authentification chiffrée, les données en bloc sont transmises en clair) car la plupart des données ne sont pas si sensibles. Cependant, cela ne fonctionne que dans les sessions non interactives telles que SCP. Cela ne fonctionne pas dans SFTP.

    Il y a également d’autres améliorations de performances, mais rien n’est aussi important que le dimensionnement correct des tampons et le chiffrement. Lorsque j’aurai du temps libre, je développerai probablement le processus HMAC (actuellement la plus grande entrave à la performance) et je réaliserai d’autres travaux d’optimisation mineurs.

    Donc, si HPN-SSH est tellement génial, pourquoi OpenSSH ne l’a-t-il pas adopté? C’est une longue histoire et les gens qui connaissent l’équipe OpenBSD connaissent probablement déjà la réponse. Je comprends beaucoup de leurs raisons – c’est un gros patch qui nécessiterait un travail supplémentaire de leur part (et ils sont une petite équipe), ils ne se soucient pas autant des performances que de la sécurité (bien qu’il n’y ait aucune implication de sécurité pour HPN-SSH) ), etc. etc. Cependant, même si OpenSSH n’utilise pas HPN-SSH, Facebook le fait. Il en va de même pour Google, Yahoo, Apple, le plus grand centre de données de recherche, la NASA, la NOAA, le gouvernement, l’armée et la plupart des institutions financières. C’est assez bien vérifié à ce stade.

    Si quelqu’un a des questions, n’hésitez pas à demander mais je ne suis peut-être pas au courant de ce forum. Vous pouvez toujours m’envoyer un mail via l’adresse email HPN-SSH (google it).

    MISE À JOUR : Comme l’a souligné un commentateur, le problème que je décris ci-dessous a été corrigé quelque temps avant cet article. Cependant, je connaissais le projet HP-SSH et j’ai demandé à l’auteur d’intervenir. Comme ils l’expliquent dans la réponse la plus populaire (à juste titre), le cryptage n’est pas la source du problème. Yay pour l’email et les gens plus intelligents que moi!

    Wow, une question d’un an avec rien d’autre que des réponses incorrectes. Cependant, je dois admettre que le ralentissement était dû au chiffrement lorsque je me suis posé la même question. Mais posez-vous la prochaine question logique: à quelle vitesse votre ordinateur peut-il chiffrer et déchiffrer les données? Si vous pensez que ce taux est proche des 4,5 Mo / seconde signalés par l’OP (.5625 Mo ou environ la moitié de la capacité d’une disquette de 5,5 pouces!), Claquez-vous plusieurs fois, buvez du café et posez-vous la même question. .

    Il semble que ce soit un oubli dans la sélection de la taille des paquets, ou du moins ce que l’auteur de LIBSSH2 dit ,

    La nature de SFTP et de son ACK pour chaque fragment de données de petite taille qu’elle envoie, fait qu’une première implémentation SFTP naïve souffre beaucoup lors de l’envoi de données sur des réseaux à latence élevée. Si vous devez attendre quelques centaines de millisecondes pour chaque 32 Ko de données, les transferts SFTP ne seront jamais rapides. Ce type d’implémentation naïve est ce que libssh2 a offert jusqu’à et y compris libssh2 1.2.7.

    La vitesse est donc due à des tailles de paquets minuscules x réponses ack obligatoires pour chaque paquet, ce qui est clairement fou.

    Le projet SSH / SCP haute performance (HP-SSH) fournit un ensemble de correctifs OpenSSH qui améliore apparemment les tampons internes ainsi que le cryptage en parallèle. Notez, cependant, que même les versions non parallélisées ont fonctionné à des vitesses supérieures aux vitesses non chiffrées de 40 Mo / s obtenues par certains commentateurs. Le correctif implique la modification de la façon dont OpenSSH appelait les bibliothèques de chiffrement, PAS le chiffrement et il n’y a pas de différence de vitesse entre AES128 et AES256. Le cryptage prend un certain temps, mais il est marginal. Cela a peut-être eu de l’importance dans les années 90 mais (comme la vitesse de Java vs C), ça n’a plus d’importance.

    Plusieurs facteurs influent sur la vitesse du transfert SFTP:

    1. Cryptage Bien que le cryptage symésortingque soit rapide, il n’est pas si rapide de ne pas être remarqué. Si vous comparez des vitesses sur un réseau rapide (100 Mbits ou plus), le chiffrement devient une rupture pour votre processus.
    2. Calcul du hachage et vérification.
    3. Copie tampon SFTP s’exécutant au-dessus de SSH fait que chaque bloc de données est copié au moins 6 fois (3 fois de chaque côté) par rapport au simple FTP où les données peuvent être transmises à l’interface réseau sans être copiées. Et la copie de bloc prend également un peu de temps.

    Le cryptage a non seulement le processeur, mais aussi certains frais généraux du réseau.

    Il y a toutes sortes de choses qui peuvent faire cela. Une possibilité est “Traffic Shaping”. Cela se fait généralement dans les environnements de bureau pour réserver la bande passante aux activités critiques. Cela peut aussi être fait par la société d’hébergement Web ou par votre FAI pour des raisons très similaires.

    Vous pouvez également le configurer chez vous très simplement.

    Par exemple, il peut y avoir une règle réservant la bande passante minimale pour FTP, tandis que SFTP peut tomber sous une règle “tout le rest”. Ou bien, il pourrait y avoir une bande passante pour SFTP, mais quelqu’un d’autre utilise SFTP en même temps que vous.

    Alors: Où transférez-vous le fichier de et vers?

    SFTP n’est pas FTP sur SSH, c’est un protocole différent et similaire à SCP, il offre plus de fonctionnalités .

    A titre de comparaison, j’ai essayé de transférer une image disque de 299 Go ntfs à partir d’un ordinateur portable i5 exécutant le cd live Runting Ringtail Ubuntu alpha 2 vers un bureau i7 exécutant Ubuntu 12.04.1. Vitesses signalées:

    sur wifi + ligne élecsortingque: scp: 5 Mo / s (40 Mbit / sec)

    sur gigabit ethernet + netgear G5608 v3:

    scp: 44MB / sec

    sftp: 47MB / sec

    sftp -C: 13MB / sec

    Donc, sur un bon lien gigabit, sftp est légèrement plus rapide que scp, les processeurs rapides de l’ère 2010 semblent assez rapides pour crypter, mais la compression n’est pas un succès dans tous les cas.

    Sur un mauvais lien Ethernet sur gigabit, cependant, le sftp a de loin surpassé le scp. Quelque chose à propos de scp étant très bavard, voyez “scp UNBELIEVABLY slow” sur comp.security.ssh de 2008: https://groups.google.com/forum/?fromgroups=#!topic/comp.security.ssh/ldPV3msFFQw http: //fixunix.com/ssh/368694-scp-unbelievably-slow.html

    Vos résultats ont du sens. Comme FTP fonctionne sur un canal non crypté, il est plus rapide que SFTP (qui est le sous-système du protocole SSH version 2). Rappelez-vous également que SFTP est un protocole basé sur des paquets, contrairement au protocole FTP basé sur des commandes.

    Chaque paquet dans SFTP est crypté avant d’être écrit sur le socket sortant du client et ensuite décrypté lorsqu’il est reçu par le serveur. Cela conduit bien sûr à des taux de transfert lents mais à un transfert très sécurisé. L’utilisation de la compression telle que zlib avec SFTP améliore le temps de transfert, mais ne sera pas proche du FTP en texte brut. Peut-être une meilleure comparaison est de comparer SFTP avec FTPS qui utilisent tous deux le chiffrement?

    La vitesse pour SFTP dépend du chiffrement utilisé pour le chiffrement / déchiffrement, de la compression utilisée, par exemple zlib, des tailles de paquet et des tailles de mémoire tampon utilisées pour la connexion de socket.

    Oui, le cryptage ajoute une certaine charge à votre processeur, mais si votre processeur n’est pas ancien, cela ne devrait pas affecter autant que vous le dites.

    Si vous activez la compression pour SSH, SCP est en fait plus rapide que FTP malgré le chiffrement SSH (si je me souviens bien, deux fois plus rapide que FTP pour les fichiers que j’ai essayé). Je n’ai pas réellement utilisé SFTP, mais je crois qu’il utilise SCP pour le transfert de fichiers proprement dit. Alors s’il vous plaît essayez ceci et faites-nous savoir 🙂