Accélérer les téléchargements SFTP sur un réseau à latence élevée?


27

J'essaie de transférer un ensemble de fichiers volumineux à l'international à l'aide de SFTP, mais je trouve que mon partenaire international ne peut pas obtenir des vitesses de téléchargement supérieures à ~ 50k malgré de très bonnes connexions de chaque côté. Nous pouvons obtenir plusieurs connexions en téléchargeant à cette vitesse (donc pas de bande passante?), Mais aucun téléchargement ne s'améliore en vitesse, ce qui est un problème car de nombreux fichiers font plusieurs Go.

Le SFTP est hébergé à l'aide du système SFTP standard «Connexion à distance» Apple OSX.

Existe-t-il un moyen d'améliorer les vitesses de téléchargement ou existe-t-il un hôte SFTP différent qui pourrait vous aider? Il n'est pas clair pour moi s'il s'agit d'un problème de configuration ou d'une limitation inhérente au protocole.

(Pour des raisons de sécurité, je dois utiliser une connexion poste à poste chiffrée de bout en bout - pas de services cloud).


Si vous avez le budget, il existe des solutions commerciales qui fonctionnent bien mieux que les systèmes de transfert de fichiers basés sur TCP comme SFTP.
Kenster

4
S'il s'agit d'un transfert unique à plusieurs Go, pourquoi ne pas essayer une alternative à Internet .
vasin1987

1
Un simple script shell pour démarrer N rsynctransferts atteindra facilement vos exigences de 1. Transfert sécurisé et 2. Maximisation de votre bande passante. Voir ici pour un exemple de démarrage de rsynctransferts N stackoverflow.com/a/38014502/52074
Trevor Boyd Smith

2
Ou utilisez simplement uftp-multicast.sourceforge.net souhait cryptera et Mac sur votre bande passante.
Trevor Boyd Smith

4
Contrairement à votre dernière phrase, le service cloud devrait être correct si vous cryptez le fichier localement, le transférez via le cloud, puis décryptez localement 8 à l'autre extrémité), ce qui signifierait toujours un cryptage de bout en bout. (Vous voudrez peut-être ajouter quelques brefs commentaires sur une réception réussie). Vous utilisez le cryptage sftp pour empêcher les attaques de quelqu'un capable de flairer tout votre trafic. Par conséquent, leur donner simplement les données chiffrées n'est pas pire que de supposer qu'ils pourraient l'obtenir de toute façon.
Hagen von Eitzen

Réponses:


29

Avec le client OpenSSHsftp (que vous semblez utiliser), vous pouvez utiliser:

  • -Rcommutateur pour augmenter la longueur de la file d'attente des demandes (la valeur par défaut est 64)
  • -Bcommutateur pour augmenter la taille de la demande de lecture / écriture (la valeur par défaut est 32 Ko)

Pour commencer, essayez de doubler les deux:

sftp -R 128 -B 65536 user@host

Cela n'a probablement pas beaucoup d'importance, lequel d'entre eux vous augmentez.

Augmenter l'un ou l'autre devrait aider à saturer votre connexion à haute latence. Avec les paramètres ci-dessus, il conservera à tout moment 8 Mo de données dans le tuyau (128 * 64K = 8M).

Notez que cela aide uniquement aux transferts de gros fichiers. Cela n'aura aucun effet lors du transfert d'un grand nombre de petits fichiers.


Pour des informations générales et une discussion sur d'autres clients SFTP (GUI), consultez la section "Délai / latence réseau" de ma réponse à Pourquoi le transfert de fichiers FileZilla SFTP est-il plafonné à 1,3 Mo / s au lieu de saturer la bande passante disponible? rsync et WinSCP sont encore plus lents .


4

Vous pouvez essayer d'activer la compression et voir si cela aide.

De man sftp:

-C Active la compression (via le drapeau -C de ssh).

Et de man ssh:

-C Demande la compression de toutes les données (y compris stdin, stdout, stderr et les données pour les connexions de domaine X11, TCP et UNIX transférées). L'algorithme de compression est le même que celui utilisé par gzip (1), et le «niveau» peut être contrôlé par l'option CompressionLevel pour la version de protocole 1. La compression est souhaitable sur les lignes de modem et autres connexions lentes, mais ne ralentira que les choses sur les réseaux rapides . La valeur par défaut peut être définie hôte par hôte dans les fichiers de configuration; voir l'option Compression.

Il semble plutôt que la connexion puisse être limitée à un certain point le long de son chemin (ou plutôt, cela me semble l'explication la plus simple pour vos 50kB / s par connexion, mais plusieurs de ces connexions étant possibles), bien que ce ne soit pas un mauvaise idée de s'assurer que les disques de chaque côté ne sont pas un facteur.

Vous pouvez également exécuter un pcap rapide pour voir s'il y a des problèmes `` évidents '' (comme un grand nombre de retransmissions) - mais à moins d'avoir une certaine confiance, vous pourrez résoudre ce problème, je verrais probablement si l'activation de la compression serait Aidez-moi.


Merci! Malheureusement, les fichiers sont pré-compressés, donc je doute que cela fasse quoi que ce soit ...: /
nick_eu

La compression n'accélère pas les choses ici même si les données ne sont pas compressées. Il s'agit d'une surcharge trop importante du temps (et du délai) du processeur, donc cela n'a plus de sens de nos jours.
Jakuje

1
Si le goulot d'étranglement est le réseau, un peu plus de CPU de chaque côté ne devrait pas ralentir @Jakuje, à moins que la boîte ne soit pas capable de compresser à 50 Ko / s, ce qui ne devrait pas être un problème.
Ben

@Ben La question indique clairement que le réseau n'est pas un goulot d'étranglement.
Jakuje

4

J'essaie de transférer un ensemble de fichiers volumineux à l'échelle internationale à l'aide de SFTP

Il n'a pas encore été mentionné comme réponse, mais lors du transfert de plusieurs fichiers sur une liaison à latence élevée, il existe une solution vraiment simple pour obtenir de meilleures performances:

Transférez plusieurs fichiers en parallèle.

Et il est une solution que vous avez même mentionné dans votre question. Utilise le.

Fondamentalement, le protocole TCP ne gère pas très bien les connexions avec un produit à large bande passante - une seule connexion ne peut pas garder suffisamment de données en mouvement à la fois. Voir https://en.wikipedia.org/wiki/TCP_tuning

Étant donné que chaque connexion est limitée par le protocole TCP, utilisez simplement plus de connexions.


1
Voici comment paralléliser les transferts SFTP: serverfault.com/questions/248105/…
niutech

3

Accélérez les transferts SFTP

En supposant que vos problèmes sont le réglage et / ou la limitation du réseau par connexion TCP, jetez un œil à sftp à l'aide du sous-système miroir lftp

Le réglage du réseau à chaque extrémité est un sujet beaucoup plus important et nécessiterait beaucoup de va-et-vient, poussant le sujet en dehors de la portée de ServerFault. Pour les connexions individuelles, la compression mentionnée par iwaseatenbyagrue peut aider dans les deux cas. Cela suppose que l'extrémité distante autorise la compression.


3

(Vous mentionnez "latence élevée" dans le titre de la question, mais pas dans le corps du texte. Avez-vous mesuré la latence réelle et quels sont les résultats?)

Il existe un correctif pour OpenSSH qui améliore explicitement le débit sur une liaison réseau à latence élevée: HPN-SSH : (c'est moi qui souligne)

SCP et l'implémentation du protocole SSH2 sous-jacent dans OpenSSH sont les performances du réseau limitées par des tampons de contrôle de flux internes définis statiquement. Ces tampons finissent souvent par agir comme un goulot d'étranglement pour le débit réseau de SCP, en particulier sur les liaisons réseau à bande passante longue et élevée. La modification du code ssh pour permettre la définition des tampons au moment de l'exécution élimine ce goulot d'étranglement. Nous avons créé un correctif qui supprimera les goulots d'étranglement dans OpenSSH et est entièrement interopérable avec d'autres serveurs et clients. De plus, les clients HPN pourront télécharger plus rapidement à partir de serveurs non HPN et les serveurs HPN pourront recevoir des téléchargements plus rapidement à partir de clients non HPN.

Essayez donc de compiler et d'utiliser HPN-SSH du côté de la réception et voyez si cela améliore votre vitesse de transfert.


Merci! Je n'ai pas réellement mesuré, je suis maintenant gêné d'admettre, mais je vais à l'autre bout du monde dans un pays avec Internet, donc je suppose que j'ai raison. :) Patch semble très utile!
nick_eu

@nick_eu J'ai vu des anecdotes selon lesquelles les scientifiques utiliseraient HPN-SSH pour transférer de grandes quantités de données scientifiques à travers l'Atlantique. Il semble que cela devrait être parfait pour votre cas d'utilisation.
ambassadeur twisteroid

0

Vous ne savez pas si c'est une option pour vous, mais avez-vous essayé de tirer ou de pousser les données vers le site international? Ainsi que ce soit à différents moments pour voir si c'est un problème de conflit pour les ressources réseau?


bonne idée, va essayer.
nick_eu

0

Nous pouvons obtenir plusieurs connexions à cette vitesse (donc pas de bande passante?)

Cela ressemble à un problème de configuration - soit délibérément (comme un moyen de vendre des services sans avoir à faire de provision supplémentaire) ou par accident (par exemple , une échelle de fenêtre cassée ou un contrôle du trafic trop zélé). Bien que vous puissiez paralléliser les transferts, vous ne nous avez rien dit sur ce qui se trouve à l'autre extrémité de la connexion ou si cela vaut la peine de développer des scripts simples pour gérer le partage / la reconstitution des fichiers.

Il est peu probable que le réglage de la taille et de la compression de la file d'attente ait un impact significatif, sauf si la cause est un logiciel très mal écrit (et openSSH ne fait pas partie de cette catégorie - il n'y a pas grand intérêt à utiliser openssh avec une file d'attente de requêtes plus longue / une taille de bloc plus grande, sauf si la latence est plus de 250 ms. Vous pouvez envisager d'essayer avec différents clients de différents emplacements pour exclure un problème avec le serveur.

Mon premier appel serait d'identifier quel fournisseur est responsable du problème, de leur demander de résoudre le problème ou de passer à un autre fournisseur.


Désolé, aurait dû être plus clair. Il n'y a pas de "fournisseur" - j'héberge sur mon propre bureau et un collègue essaie de se connecter depuis son ordinateur. Le collègue vient d'ouvrir une session ssh (pas sûr du protocole mais peut vérifier) ​​et utiliseput
nick_eu

@nick_eu, il parle des fournisseurs Internet.
Džuris

Cela ressemble à un problème de configuration . Ce n'est pas un problème de configuration. Le protocole TCP lui-même ne fonctionne pas bien sur les connexions avec un produit à retard de bande passante important. Fondamentalement, si la connexion est telle que beaucoup de données peuvent être en vol à la fois, le protocole TCP lui-même ne peut pas garder autant de données en mouvement à tout moment. C'est pourquoi les connexions TCP parallèles fonctionnent pour améliorer les taux de transfert de données.
Andrew Henle

"ne fonctionne pas bien sur les connexions avec un produit à large retard de bande passante" - veuillez lire RFC 1323 (de 1992) et 7323 (remplacé 1323 en 2014)
symcbean

@symcbean Ensuite, expliquez les OP Nous pouvons obtenir plusieurs connexions en téléchargeant à cette vitesse (donc pas de bande passante?), mais aucun téléchargement ne s'améliore en vitesse C'est un symptôme classique de TCP sur une connexion avec une latence extrême - toutes les extensions TCP peuvent faire est d'atténuer le problème un peu car ils ne peuvent pas résoudre les problèmes fondamentaux avec le protocole lui-même. Et bonne chance pour identifier le fournisseur responsable du problème, demandez-lui de résoudre le problème tout en essayant de «transférer un ensemble de fichiers volumineux à l'échelle internationale».
Andrew Henle
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.