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

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).

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 .

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.

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.

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.

(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.

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?

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.