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

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

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 .

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.

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.

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.

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

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?

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.