Acelerar os uploads de SFTP na rede de alta latência?

Question

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

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

Existe uma maneira de melhorar as velocidades de upload ou há um host SFTP diferente que ajude? Não está claro para mim se isso é um problema de configuração ou uma limitação inerente do protocolo.

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

    

Answer 1

Com o OpenSSH sftp client (que você parece usar), você pode usar:

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

Para começar, tente dobrar ambos:

sftp -R 128 -B 65536 user@host

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

O aumento também deve ajudar a saturar sua conexão de alta latência. Com as configurações acima, ele manterá 8 MB de dados fluindo no canal 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 alguns contextos e uma discussão sobre outros clientes SFTP (GUI), consulte a seção "Atraso / latência de rede" da minha resposta para Por que a transferência de arquivo SFZ do FileZilla é limitada a 1,3 Mb / s em vez de saturar a largura de banda disponível? O rsync e o WinSCP são ainda mais lentos .

    

Answer 2

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

De man sftp :

-C Enables compression (via ssh's -C flag).

E de man ssh :

-C Requests compression of all data (including stdin, stdout, stderr, and data for forwarded X11, TCP and UNIX-domain connections). The compression algorithm is the same used by gzip(1), and the “level” can be controlled by the CompressionLevel option for protocol version 1. Compression is desirable on modem lines and other slow connections, but will only slow down things on fast networks. The default value can be set on a host-by-host basis in the configuration files; see the Compression option.

Em vez disso, parece que a conexão pode ter uma taxa limitada em algum ponto ao longo de seu caminho (ou melhor, essa parece ser a explicação mais simples para seus 50kB / s por conexão, mas várias dessas conexões são possíveis), embora possa Não é uma má idéia ter certeza de que os discos de ambos os lados não são um fator.

Você também pode executar um pcap rápido para ver se há algum problema "óbvio" (como um grande número de retransmissões) - mas, a menos que você tivesse alguma confiança, seria capaz de resolver isso, provavelmente só veria se habilitar a compactação ajudaria.

    

Answer 3

Acelere as transferências do sftp

Assumindo que seus problemas são de ajuste de rede e / ou otimização por conexão TCP, dê uma olhada em sftp usando o subsistema de espelho lftp

O ajuste de rede em cada extremidade é um tópico muito maior e exigiria muitas idas e vindas, empurrando o tópico para fora do escopo do ServerFault. Para conexões individuais, a compactação mencionada por iwaseatenbyagrue pode ajudar de qualquer forma. Isso pressupõe que a extremidade remota permite a compactação.

    

Answer 4

(Você menciona "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 no OpenSSH que melhora a taxa de transferência de maneira explícita em um link de rede de alta latência: HPN-SSH : (ênfase meu)

SCP and the underlying SSH2 protocol implementation in OpenSSH is network performance limited by statically defined internal flow control buffers. These buffers often end up acting as a bottleneck for network throughput of SCP, especially on long and high bandwith network links. Modifying the ssh code to allow the buffers to be defined at run time eliminates this bottleneck. We have created a patch that will remove the bottlenecks in OpenSSH and is fully interoperable with other servers and clients. In addition HPN clients will be able to download faster from non HPN servers, and HPN servers will be able to receive uploads faster from non HPN clients.

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

    

Answer 5

I'm trying to transfer a set of large files internationally using SFTP

Ainda não foi mencionada como uma resposta, mas ao transferir vários arquivos em um link de alta latência, há 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 muito bem com conexões com um grande produto de atraso de largura de banda - uma única conexão não pode manter dados suficientes se movendo a qualquer momento. Consulte o link

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

    

Answer 6

Não tenho certeza se essa é uma opção para você, mas você já tentou puxar ou empurrar os dados para o site internacional? Assim como em diferentes momentos para ver se é um problema de contenção de recursos de rede?

    

Answer 7

We can get multiple connections uploading at this speed (so not bandwidth?)

Soa como um problema de configuração - seja deliberadamente (como uma forma de oferecer serviços sem ter que fazer qualquer provisão extra) ou por acidente (por exemplo, quebrado dimensionamento de janelas ou controle de tráfego com excesso de zelo). Enquanto você poderia paralelizar as transferências, você não nos disse nada sobre o que está no outro lado da conexão ou se vale a pena desenvolver alguns scripts simples para manipular sharding / reconstitution de arquivos.

É improvável que o tamanho da fila e a compactação tenham impacto significativo, a menos que a causa seja um software muito mal escrito (e o openSSH não pertence a essa categoria - não faz muito sentido usar o openssh com um tempo maior fila de pedidos / tamanho de bloco maior, a menos que a latência seja maior que 250 ms. Você pode considerar tentar 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 ele resolva o problema ou mude para outro provedor.