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 140MB.
FTP: j'ai un taux d'arround de 11 Mo/s
SFTP: J'ai un taux de 4,5MB/s
Je comprends que le fichier doit être crypté avant d’être envoyé. Est-ce le seul impact sur le transfert de fichier? (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 intervenant ici m'a demandé de faire le point. 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 ne connaissent pas l’algorithme de contrôle de flux sous-jacent utilisé par TCP. Cela signifie que SSHv2 doit implémenter son propre algorithme de contrôle de flux. L'implémentation la plus courante consiste essentiellement à réimplémenter les fenêtres coulissantes. Cela signifie que la fenêtre coulissante SSH se trouve au-dessus de la TCP fenêtre coulissante Le résultat final est que la taille effective de la mémoire tampon de réception est au minimum de la mémoire tampon de réception des deux fenêtres coulissantes. Stock OpenSSH a une taille de mémoire tampon de réception maximale de 2 Mo mais finit par être plus proche de ~ 1,2 Mo. Les systèmes d’exploitation ont une mémoire tampon qui peut s’accroître (avec l’ajustement automatique des mémoires tampons de réception) jusqu’à une taille effective de 4 Mo. Pourquoi est-ce important? Si la taille de la mémoire tampon de réception est inférieure au produit de délai de bande passante (BDP), vous ne pourrez jamais remplir complètement le tuyau, peu importe la vitesse à laquelle vous Votre système est.
Ceci est compliqué par le fait que SFTP ajoute une autre couche de contrôle de flux aux contrôles de flux = TCP et SSH). SFTP utilise un concept de messages en attente. Chaque message peut être une commande, résultat de une commande ou un flux de données en bloc. Les messages en attente peuvent atteindre une taille de datagramme spécifique. Vous vous retrouvez ainsi 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 en attente messages (les deux peuvent être définis sur la ligne de commande). La valeur par défaut est 32k * 64 (2 Mo). Ainsi, lorsque vous utilisez SFTP, vous devez vous assurer que le TCP tampon de réception, le SSH tampon de réception et le tampon de réception SFTP ont tous une taille suffisante (sans être trop volumineux ou vous pouvez avoir des problèmes de mise en mémoire tampon excessive dans les sessions interactives).
HPN-SSH résout directement le problème de la mémoire tampon SSH en ayant une taille maximale d'environ 16 Mo. Plus important encore, la mémoire tampon croît dynamiquement à la taille appropriée en interrogeant l'entrée proc pour la taille de la mémoire tampon de la connexion TCP (en faisant un trou entre les couches 3 et 4)), ce qui évite la surcharge dans presque toutes les situations. Dans SFTP, nous élevons le nombre maximal de demandes en attente à 256. Au moins, nous devrions le faire - il semblerait que le changement ne se soit pas propagé comme prévu dans le patch 6.3 (bien que ce soit dans la version 6.2). Il n’existe pas de version 6.4 car la version 6.3 corrige proprement contre la version 6.4 (ce qui est un correctif de sécurité d’une ligne à partir de la version 6.3) .Vous pouvez obtenir le jeu de correctifs auprès de sourceforge.
Je sais que cela semble étrange, mais la taille correcte des tampons était 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 véritable source de performances médiocres dans la plupart des cas. Vous pouvez vous le prouver 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, moins le débit est élevé. Cela indique clairement qu'il s'agit d'un problème de performances dépendant de RTT.
Quoi qu'il en soit, avec ce changement, j'ai commencé à constater des améliorations allant jusqu'à 2 ordres de grandeur. Si vous comprenez TCP vous comprendrez pourquoi cela a fait une telle différence. Il ne s'agit pas de la taille du datagramme ni du nombre de paquets ou quoi que ce soit de ce genre. C'est tout parce que, pour être efficace, Si vous utilisez le chemin du 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. peut ne voir aucune amélioration que ce soit si le chemin n'est pas suffisamment rapide et long Si le BDP est inférieur à 1,2 Mo, HPN-SSH risque de ne pas vous être utile.
Le chiffrement AES-CTR parallélisé améliore les performances sur les systèmes à plusieurs cœurs si le chiffrement intégral est nécessaire. En général, je suggère aux personnes (ou à la fois le serveur et le client) d’utiliser le commutateur de chiffrement NONE (authentification chiffrée, données en bloc transmises en clair), car la plupart des données ne sont pas si sensibles. Toutefois, 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 d'aussi important que le dimensionnement correct des tampons et le chiffrement ne fonctionne pas. Quand j'aurai un peu de temps libre, je ferai probablement un pipeline du processus HMAC (actuellement le plus gros frein à la performance) et effectuerai quelques travaux d'optimisation mineurs.
Donc, si HPN-SSH est si génial, pourquoi OpenSSH ne l’a-t-il pas adopté? C'est une longue histoire et les personnes 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 forment une petite équipe), ils se soucient moins de la performance que de la sécurité (bien que HPN-SSH n'ait aucune implication en matière de sécurité. ), etc. etc. Cependant, même si OpenSSH n’utilise pas HPN-SSH, Facebook le fait. Il en va de même de Google, Yahoo, Apple, de la plupart des grands centres de données de recherche, de la NASA, de la NOAA, du gouvernement, de l'armée et de la plupart des institutions financières. C'est assez bien vérifié à ce stade.
Si vous avez des questions, n'hésitez pas, mais je ne suis peut-être pas à jour sur ce forum. Vous pouvez toujours m'envoyer un courrier électronique via l'adresse électronique HPN-SSH (google it).
[~ # ~] mise à jour [~ # ~] : Comme l'a fait remarquer un intervenant, le problème que je décris ci-dessous a été corrigé quelque temps avant ce message. Cependant, je connaissais le projet HP-SSH et j'ai demandé à l'auteur d'intervenir. Comme ils l'expliquent dans la réponse (à juste titre) la plus votée, le cryptage est pas la source du problème. Yay pour le courrier électronique et les gens plus intelligents que moi!
Wow, une question d'un an avec rien que des réponses incorrectes. Cependant, je dois admettre que j’ai supposé que le ralentissement était dû au cryptage lorsque je me suis posé la même question. Mais posez-vous la question logique suivante: à quelle vitesse votre ordinateur peut-il chiffrer et déchiffrer des données? Si vous pensez que le débit est proche des 4,5 Mo/seconde indiqués par l’OP (0,5625 Mo ou environ la moitié de la capacité d’une disquette de 5,5 "! ) taper quelques fois, boire du café et se poser à nouveau la même question.
Cela a apparemment à voir avec ce qui équivaut à un oubli dans la sélection de la taille du paquet, ou du moins c'est ce que l'auteur de LIBSSH2 dit ,
La nature de SFTP et de son ACK pour chaque petit bloc de données qu’il envoie, fait en sorte que la mise en œuvre initiale de SFTP naïf 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, il n'y aura jamais de transferts SFTP rapides. Ce type d’implémentation naïve est ce que libssh2 a proposé jusqu’à inclure libssh2 1.2.7.
Donc, la rapidité de frappe est due à des tailles de paquets minuscules x des réponses obligatoires obligatoires pour chaque paquet, ce qui est clairement fou.
Le projet hautes performances SSH/SCP (HP-SSH) fournit un ensemble de correctifs OpenSSH qui améliore apparemment les tampons internes ainsi que le chiffrement en parallèle. Notez cependant que même les versions non parallélisées fonctionnaient à des vitesses supérieures à celles de 40 Mo/s non chiffrées obtenues par certains commentateurs. Le correctif implique de changer la façon dont OpenSSH appelait les bibliothèques de chiffrement, PAS le chiffrement, et la différence de vitesse est nulle entre AES128 et AES256. Le cryptage prend certains temps, mais il est marginal. Cela avait peut-être eu de l'importance dans les années 90, mais (comme la vitesse de Java vs C)), cela n'a plus d'importance.
Plusieurs facteurs affectent la vitesse de transfert SFTP:
- Cryptage Bien que le chiffrement symétrique soit rapide, il n'est pas si rapide de passer inaperçu. Si vous comparez les vitesses sur un réseau rapide (100 Mbits/s ou plus), le cryptage devient une pause pour votre processus.
- Calcul de hachage et vérification.
- Copie tampon. SFTP s’exécutant au-dessus de SSH, chaque bloc de données est copié au moins 6 fois (3 fois de chaque côté), ce qui est plus comparable au simple FTP où les données peuvent dans le meilleur des cas être transmises à l’interface réseau sans aucune copie. Et la copie en bloc prend également un peu de temps.
Vos résultats ont du sens. Étant donné que FTP fonctionne sur un canal non chiffré, il est plus rapide que SFTP (qui est un sous-système au-dessus du protocole SSH version 2). Rappelez-vous également que SFTP est un protocole basé sur les paquets contrairement à FTP qui est basé sur des commandes.
Chaque paquet dans SFTP est crypté avant d'être écrit dans le socket sortant du client, puis décrypté lorsqu'il est reçu par le serveur. Bien sûr, cela conduit à des taux de transfert lents mais très sûrs. Utiliser une compression telle que zlib avec SFTP améliore le temps de transfert, mais il ne sera toujours pas proche de FTP en texte brut. Une meilleure comparaison consiste peut-être à comparer SFTP à FTPS, qui utilisent tous deux le cryptage?
La vitesse pour SFTP dépend du chiffrement utilisé pour le chiffrement/déchiffrement, la compression utilisée par exemple. zlib, tailles de paquet et tailles de mémoire tampon utilisées pour la connexion socket.
Le chiffrement a non seulement de la CPU, mais aussi une surcharge du réseau.
À titre de comparaison, j'ai essayé de transférer une image disque ntfs de 299 Go depuis un ordinateur portable i5 exécutant le cd live Raring Ringtail Ubuntu alpha 2 sur un ordinateur de bureau i7 exécutant Ubuntu 12.04.1. Vitesses rapportées:
sur wifi + courant porteur: scp: 5 Mo/s (40 Mbit/s)
sur ethernet gigabit + netgear G5608 v3:
scp: 44 Mo/sec
sftp: 47Mo/sec
sftp -C: 13Mo/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 chiffrer, mais la compression n’est pas gagnante dans tous les cas.
Sur un mauvais lien ethernet gigabit, cependant, j’ai eu beaucoup de problèmes avec sftp. Quelque chose à propos de scp étant très bavard, voir "scp UNBELIEVABLY slow" sur comp.security.ssh à partir de 2008: https://groups.google.com/forum/?fromgroups=#!topic/comp.security.ssh/ldPV3msFFQwhttp://fixunix.com/ssh/368694-scp-unbelievably-slow.html
Il y a toutes sortes de choses qui peuvent le faire. Une possibilité est "Traffic Shaping". Cela est généralement effectué dans les environnements de bureau pour réserver de la bande passante aux activités critiques de l'entreprise. Cela peut également être fait par la société d'hébergement Web, ou par votre fournisseur d'accès Internet, pour des raisons très similaires.
Vous pouvez également l'installer chez vous très simplement.
Par exemple, il peut exister une règle réservant une largeur de bande minimale pour FTP, tandis que SFTP peut tomber sous une règle "tout le reste". Ou bien, il pourrait y avoir une règle limitant la bande passante pour SFTP, mais quelqu'un d'autre utilise également SFTP en même temps que vous.
So: Où transférez-vous le fichier?
SFTP n’est pas FTP sur SSH, c’est un protocole différent et, semblable au SCP, il offre plus possibilités .