Acelerar envios de SFTP em rede de alta latência?


27

Estou tentando transferir um conjunto de arquivos grandes internacionalmente usando SFTP, mas estou descobrindo que meu parceiro internacional não pode obter velocidades de upload acima de ~ 50k, apesar das excelentes conexões de ambos os lados. Podemos fazer o upload de várias conexões nessa velocidade (não largura de banda?), Mas nenhum upload único melhora a velocidade, o que é um problema, pois muitos arquivos têm vários GB de tamanho.

O SFTP está sendo hospedado usando o sistema SFTP padrão da Apple OSX "Login remoto".

Existe uma maneira de melhorar a velocidade de upload ou existe um host SFTP diferente que ajudaria? Não está claro para mim se isso é um problema de configuração ou uma limitação inerente ao protocolo.

(Por motivos de segurança, preciso usar uma conexão ponto a ponto criptografada de ponta a ponta - sem serviços em nuvem).


Se você tiver o orçamento, existem soluções comerciais com desempenho muito melhor que os sistemas de transferência de arquivos baseados em TCP, como o SFTP.
Kenster

4
Se for uma transferência multi-gb de tempo, por que não tentar uma alternativa à Internet .
precisa saber é o seguinte

11
Um script shell simples para iniciar N rsynctransferências facilmente alcançará seus requisitos de 1. Transferência segura e 2. Maximizando sua largura de banda. Veja aqui um exemplo de como começar N rsynctransfere stackoverflow.com/a/38014502/52074
Trevor Boyd Smith

2
Ou apenas use uftp-multicast.sourceforge.net que o desejo criptografará e Mac a sua largura de banda.
Trevor Boyd Smith

4
Ao contrário da sua última frase, o serviço em nuvem deve ser bom se você criptografar o arquivo localmente, transferi-lo pela nuvem e descriptografar localmente 8 na outra extremidade), o que ainda significaria criptografia de ponta a ponta. (Você pode adicionar um breve feedback sobre a recepção bem-sucedida). Você usa a criptografia sftp para impedir ataques de alguém capaz de detectar todo o seu tráfego. Portanto, apenas fornecer a eles os dados criptografados não é pior do que supor que eles possam obtê-los de qualquer maneira.
Hagen von Eitzen

Respostas:


29

Com o cliente OpenSSHsftp (que você parece usar), você pode usar:

  • -Ralterne para aumentar o comprimento da fila de solicitações (o padrão é 64)
  • -Balterne para aumentar o tamanho da solicitação de leitura / gravação (o padrão é 32 KB)

Para começar, tente dobrar os dois:

sftp -R 128 -B 65536 user@host

Provavelmente não importa muito, qual deles você aumenta.

Aumentar um dos dois deve ajudar a saturar sua conexão de alta latência. Com as configurações acima, ele manterá 8 MB de dados fluindo no tubo a qualquer momento (128 * 64K = 8M).

Observe que isso ajuda apenas com grandes transferências de arquivos. Não terá nenhum efeito ao transferir muitos arquivos pequenos.


Para obter mais informações e uma discussão sobre outros clientes SFTP (GUI), consulte a seção "Atraso / latência da rede" da minha resposta para Por que a transferência de arquivos SFTP do FileZilla é máxima com limite de 1.3MiB / s em vez de saturar a largura de banda disponível? rsync e WinSCP são ainda mais lentos .


4

Você pode tentar ativar a compactação e ver se isso ajuda.

De man sftp:

-C Ativa a compactação (por meio do sinalizador -C do ssh).

E de man ssh:

-C Solicita a compactação de todos os dados (incluindo stdin, stdout, stderr e dados para conexões de domínio X11, TCP e UNIX encaminhadas). O algoritmo de compactação é o mesmo usado pelo gzip (1), e o “nível” pode ser controlado pela opção CompressionLevel para a versão do protocolo 1. A compactação é desejável em linhas de modem e outras conexões lentas, mas só atrasa as coisas em redes rápidas . O valor padrão pode ser definido host a host nos arquivos de configuração; consulte a opção Compactação.

Parece que a conexão pode ter uma taxa limitada em algum momento ao longo do caminho (ou melhor, isso me parece a explicação mais simples para seus 50kB / s por conexão, mas várias conexões são possíveis), embora possa não ser uma má idéia para garantir que os discos de ambos os lados não sejam um fator.

Você também pode executar um pcap rápido para ver se há problemas "óbvios" (como um grande número de retransmissões) - mas, a menos que você tenha alguma confiança, poderá resolver isso, provavelmente verificaria se a compactação seria ativada. Socorro.


Obrigado! Infelizmente os arquivos são pré-comprimido, por isso duvido que vou fazer de tudo ...: /
nick_eu

A compactação não acelera as coisas aqui, mesmo que os dados não sejam compactados. É uma sobrecarga muito grande do tempo da CPU (e atraso), portanto não faz sentido atualmente.
Jakuje

11
Se o gargalo for a rede, um pouco mais de CPU em ambos os lados não deve desacelerar nada @Jakuje, a menos que a caixa não consiga compactar a 50kB / s, o que não deve ser um problema.
Ben

@ Ben A questão afirma claramente que a rede não é um gargalo.
Jakuje

4

Estou tentando transferir um conjunto de arquivos grandes internacionalmente usando SFTP

Ainda não foi mencionado como resposta, mas ao transferir vários arquivos por um link de alta latência, existe uma solução realmente simples para obter melhor desempenho:

Transfira vários arquivos em paralelo.

E é uma solução que você mencionou na sua pergunta. Use-o.

Basicamente, o protocolo TCP não lida com conexões com um grande produto de retardo de largura de banda muito bem - uma única conexão não pode manter dados suficientes em movimento ao mesmo tempo. Consulte https://en.wikipedia.org/wiki/TCP_tuning

Como cada conexão é limitada pelo protocolo TCP, basta usar mais conexões.


11
Aqui está como paralelizar transferências SFTP: serverfault.com/questions/248105/…
niutech

3

Acelere as transferências sftp

Supondo que seus problemas sejam de ajuste de rede e / ou limitação por conexão TCP, dê uma olhada no sftp usando o subsistema de espelho lftp

O ajuste da rede em cada extremidade é um tópico muito maior e exigiria muito tempo para frente e para trás, empurrando o tópico para fora do escopo do ServerFault. Para conexões individuais, a compactação mencionada por iwaseatenbyagrue pode ajudar de qualquer maneira. Isso pressupõe que a extremidade remota permita a compactação.


3

(Você mencionou "alta latência" no título da pergunta, mas não no texto do corpo. Você mediu a latência real e quais são os resultados?)

Há um patch para o OpenSSH que melhora explicitamente a taxa de transferência em um link de rede de alta latência: HPN-SSH : (ênfase minha)

O SCP e a implementação subjacente do protocolo SSH2 no OpenSSH têm desempenho de rede limitado por buffers de controle de fluxo interno definidos estaticamente. Esses buffers geralmente acabam atuando como um gargalo para a taxa de transferência de rede do SCP, especialmente em links de rede com largura de banda longa e alta. A modificação do código ssh para permitir que os buffers sejam definidos no tempo de execução elimina esse gargalo. Criamos um patch que removerá os gargalos no OpenSSH e é totalmente interoperável com outros servidores e clientes. Além disso, os clientes HPN poderão fazer o download mais rápido de servidores que não são da HPN, e os servidores HPN poderão receber carregamentos mais rapidamente dos clientes que não são da HPN.

Portanto, tente compilar e usar o HPN-SSH no lado do recebimento e veja se isso melhora sua velocidade de transferência.


Obrigado! Na verdade, eu ainda não medi, agora estou envergonhado de admitir, mas estou indo para o outro lado do mundo em um país com a mais ou menos a internet, então acho que estou certo. :) Patch parece muito útil!
nick_eu

@nick_eu Vi histórias de que os cientistas usariam o HPN-SSH para transferir grandes quantidades de dados científicos através do Atlântico. Parece que deve ser perfeito para o seu caso de uso.
Twisteroid ambassador

0

Não tem certeza se essa é uma opção para você, mas você tentou puxar vs enviar os dados para o site internacional? Bem como em momentos diferentes para ver se é um problema com a disputa por recursos de rede?


ótima idéia, vai tentar.
nick_eu

0

Podemos fazer o upload de várias conexões nessa velocidade (não largura de banda?)

Parece um problema de configuração - deliberadamente (como uma forma de aumentar os serviços de venda sem ter que fazer nenhuma provisão extra) ou por acidente (por exemplo, redimensionamento de janelas quebradas ou controle de tráfego excessivamente zeloso). Embora você possa paralelizar as transferências, você não nos disse nada sobre o que está do outro lado da conexão ou se vale a pena desenvolver alguns scripts simples para lidar com a fragmentação / reconstituição de arquivos.

É improvável que o ajuste do tamanho e da compactação da fila tenha um impacto significativo, a menos que a causa seja um software mal gravado (e o openSSH não se enquadra nessa categoria - não faz muito sentido usar o openssh com uma fila de solicitações mais longa / tamanho de bloco maior, a menos que a latência seja acima de 250 ms. Você pode considerar tentar com clientes diferentes de locais diferentes para descartar um problema com o servidor.

Minha primeira ligação seria identificar qual provedor é o culpado pelo problema, pedir que eles resolvessem o problema ou mudassem para outro provedor.


Desculpe, deveria ter sido mais claro. Não há "provedor" - estou hospedando em minha própria área de trabalho e um colega está tentando se conectar a partir do computador. O colega está apenas abrindo uma sessão de ssh (não tenho certeza de protocolo, mas pode verificar) e usandoput
nick_eu

@nick_eu ele está falando sobre os provedores de internet.
Džuris

Parece um problema de configuração . Não. Não é um problema de configuração. O protocolo TCP em si não funciona bem em conexões com um grande produto de atraso de largura de banda. Basicamente, se a conexão permitir que muitos dados possam estar em andamento por vez, o protocolo TCP não poderá manter esses dados em movimento a qualquer momento. É por isso que as conexões TCP paralelas funcionam para melhorar as taxas de transferência de dados.
Andrew Henle

"não funciona bem em conexões com um produto grande largura de banda-delay" - leia RFC 1323 (de 1992) e 7323 (substituído 1.323 em 2014)
symcbean

@symcbean Então explique os OP's Podemos obter o upload de várias conexões nessa velocidade (portanto, não a largura de banda?), mas nenhum upload único melhora a velocidade Esse é um sintoma clássico do TCP em uma conexão com extrema latência - tudo o que as extensões TCP podem fazer é atenuar um pouco o problema, pois eles não conseguem resolver os problemas fundamentais do próprio protocolo. E boa sorte com a identificação de qual provedor é o culpado pelo problema, peça a ele que corrija o problema ao tentar "transferir um conjunto de arquivos grandes internacionalmente".
Andrew Henle
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.